{"id":12052,"date":"2017-09-18T16:32:26","date_gmt":"2017-09-18T15:32:26","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=12052"},"modified":"2020-12-06T22:47:00","modified_gmt":"2020-12-06T22:47:00","slug":"design-doesnt-stop-handoff","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/design-doesnt-stop-handoff\/","title":{"rendered":"Design Doesn\u2019t Stop at Handoff"},"content":{"rendered":"

Between 2012 and 2017, we\u2019ve seen the biggest tech companies in the world hire thousands of designers to push the value of design through their organisations. For example, IBM has gone from just 1 designer to every 72 engineers, to a ratio of 1 in 8. Intercom lead the way in terms of numbers, with 1 designer to every 5 developers in 2017<\/a>.<\/span><\/p>\n

Despite the large design push, Design to Dev Ratios<\/span> Atlassian 1:9
\nIBM 1:8
\nDropbox 1:6
\nIntercom 1:5<\/span> the fact remains that developers usually outnumber designers in most product teams. Therefore, when it comes to delivering a successful product, designers often have to adapt development tools and embrace engineering culture just as much<\/i> as engineers are embracing design in the design thinking movement.\u00a0<\/span><\/p>\n

There still exist situations where design work can get done in a silo too, resulting in deliverables such as wireframes, personas and storyboards being thrown over an invisible wall. Even though designers will sit in on developer scrums, and developers will attend design meetings and workshops, it doesn\u2019t always mean both are working together. They\u2019re just present because they\u2019re told to be there by managers. As Intercom<\/a> put it:<\/span><\/p>\n

<\/div>
<\/svg><\/div>

\u201cWhen design is seen as a satellite that orbits engineering, it usually comes crashing back to earth.\u201d<\/p><\/span><\/blockquote>\n

The reality is that a designer\u2019s job on a project doesn\u2019t stop at a specific handoff point with developers \u2013 it\u2019s most effective when design continues well after a product has shipped, as this is one of the best times to listen to real users and iterate on the design of the product. By developing our skillsets and exploring new areas, teams can develop more empathy towards one another of each other, as well as understand what it takes to deliver a product from end to end. You can\u2019t have design without development to deliver great products, so let\u2019s look at some of the problems and solutions of working together better.<\/p>\n

\"designer<\/a><\/p>\n

Design meets development<\/h2>\n
<\/div>
<\/svg><\/div>

\u201cIt doesn\u2019t matter if you\u2019re a designer or developer - neither want to ship a bad product.\u201d<\/span><\/p><\/span><\/blockquote>\n

Despite the shared overall goal, it can be a challenge to get these two disciplines to work well together. Where a designer\u2019s workflow looks at the bigger picture and focuses on creating the perfect user experience, development is often more concerned with getting shorter term tasks done efficiently, especially when working in \u2018Agile\u2019. \u00a0As James Archer, CEO of design agency Forty<\/span><\/a> puts it, the two ways of working simply don\u2019t blend together very smoothly<\/a> at first:<\/span><\/p>\n

Agile developers can get frustrated with designers for overthinking things (\u201cWhy can\u2019t they just let it go? We can get to that later.\u201d), while the designers get discouraged by the perceived low standards of Agile developers (\u201cDon\u2019t you want it to be good? Don\u2019t you want the user to be happy?\u201d).<\/em><\/span><\/p>\n

Archer goes on to outline that to get things done, designers may have to sacrifice perfectionism for some acceptance of real-world business scenarios, which aren\u2019t always ideal. In fact, both sides should start by understanding each other. To get a clearer picture of what\u2019s going on , let\u2019s first define what Agile actually is, and how it relates to design:<\/p>\n

<\/p>\n

The basics of Agile for designers<\/h1>\n

If you're working in any tech company, no matter what your role, you\u2019ve probably heard the term \u201cAgile\u201d used within your development team \u2013 it\u2019s often followed by words like \u201cScrum\u201d and \u201cSprint\u201d. It can seem a little overwhelming at first as if it\u2019s a new language with its own rules, but it\u2019s not just<\/i> for technical people. Reading these two definitions, it can actually become surprisingly clearer to anyone:<\/span><\/p>\n

Agile Defined<\/strong><\/p>\n

Agile<\/i><\/b> is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.<\/i><\/span><\/p>\n

Scrum Defined<\/b><\/span><\/p>\n

Scrum<\/i><\/b> is an <\/i>Agile framework<\/i><\/span><\/a> for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work.<\/i><\/span><\/p>\n

Basically, agile is the philosophy, and Scrum is a framework based on that philosophy, enabling us to complete complex projects. As you might realise, the principles of agile are also applicable to many other industries - not just software. Agile and Scrum can be used together for any project where there\u2019s a concrete product being produced. <\/span><\/p>\n

<\/p>\n

\"Agile<\/a>

Adapted from the Agile Manifesto<\/p><\/div>\n

<\/p>\n

According to Andrew Littlefield<\/span><\/a> of Trello, Scrum has been used by everyone including marketing agencies<\/span><\/a> and construction crews. He goes on to say that scrum can even be applied for email campaigns, as well as software. <\/span><\/p>\n

Now we\u2019ve covered how developers work in Agile, let\u2019s look at some of the challenges of bringing it together with design.<\/span><\/p>\n

<\/div>
<\/svg><\/div>

A designer\u2019s job on a project doesn\u2019t stop at a specific handoff point with developers.<\/p><\/span><\/blockquote>\n

<\/p>\n

Working together better<\/h1>\n

Agile is fantastic for producing results and well adopted by most software development teams, so it\u2019s unlikely to go away. Hoa Loranga<\/a>, VP at the Nielson Norman Group highlights this when she found that nobody (developer, designer or product manager) working in Agile environments wanted to revert back to a waterfall approach.<\/span><\/p>\n

Despite Nobody wants to revert back to the waterfall approach.<\/span> this preference for Agile, it doesn\u2019t really provide the best environment for design, so getting design and development to work together can be a challenge. As Loranga found, the compressed timescales of agile can force the abandonment of user research and thereby degrade the resulting user experience. This problem isn\u2019t even something new to design in software environments though. \u00a0<\/span><\/p>\n

Dave Malouf<\/a><\/span>, in \u2018Agile is Reducing the Value of Your Design Team\u2019<\/i>, went as far as suggesting that designers working under certified agile methods aren\u2019t designing their designs at all. Even though they\u2019re shipping, he explains how Scrum doesn\u2019t make room for the following 3 items that make design unique from engineering: empathy, creativity and vision.<\/span><\/p>\n

\u201cScrum doesn\u2019t make room for 3 items that make design unique from engineering: empathy, creativity and vision.\u201d<\/span><\/p>\n

Since Agile is so effective in delivering working code, it\u2019s unlikely to be going anywhere<\/a>. Therefore, how can we make design work better and deliver more effective user experiences within agile\u2019s incremental framework? Before going too far into methodologies and tools, one of the most overlooked areas can simply be culture - how people work and communicate across disciplines. For instance, rather than looking at people within \u2018designer\u2019 or \u2018developer\u2019 boxes, it\u2019s common nowadays for people to drift between the two.<\/p>\n

<\/div>
<\/svg><\/div>

\"Designers have to embrace engineering culture just as much as engineers are embracing design\"<\/p><\/span><\/blockquote>\n

Improving relationships<\/h2>\n

What makes and breaks a product team, according to Intercom, can often be the relationship<\/em> between design and engineers. Closing this gap is hugely beneficial, and one way to do it is by forming closely knit teams with diverse disciplines. For instance, at Spotify, small Agile teams (or squads) are set up with a mix of design and engineering talent who work very closely to design, develop, test and release features to production:<\/p>\n

\u201cA Squad is similar to a Scrum team and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production.\u201d<\/span><\/p>\n

This ensures designers and developers are always on the same page and well aware of how each other works - or as Spotify\u2019s VP of design, Rochelle King said, \u00a0it ensures design is never done in a vacuum<\/a>.<\/p>\n

Depending on the phase of the product though, the composition of the team and the role of each member can also change. Sometimes there may be 1-2 designers in a team, and in others there will be a lot more engineers (e.g. when it comes to building the product). You can read more about the phases of product development at Spotify here<\/a>.<\/p>\n

<\/p>\n

\"\"<\/a>

The phases of product teams at Spotify<\/p><\/div>\n

<\/p>\n

The T-Shaped Designer<\/h2>\n

Similar to creating more diverse teams, another approach set out by IDEO\u2019s Tim Brown is to create a team of \u2018T Shaped\u2019 designers. As previously mentioned, it\u2019s not strange for designers to explore coding tools, or developers to design today, with many people being skilled in both areas. This idea is also championed by IBM, with their Director of Design, Karel Vredenburg<\/a>, who provides a great introduction to becoming a T-Shaped<\/a>.<\/p>\n

\"The<\/a><\/p>\n

In a team of T-shaped designers, each member may have one core skill - be it visual design, research or development, but also strives to gain knowledge in other areas. For example, a design developer (or prototyper) may spend time learning more about user research, whereas a visual designer may pick up coding skills. According to Vredenburg, becoming T-Shaped in this sense creates more empathy between team members, thereby increasing the quality of collaboration.<\/p>\n

<\/div>
<\/svg><\/div>

\"Becoming T-Shaped creates more empathy between team members, increasing the quality of collaboration.\"<\/p><\/span><\/blockquote>\n

Frontend designers<\/h2>\n

Leading on from the T-Shaped designer is the important role of the \u2018Front-end designer\u2019. These people can really<\/em> drift between design and development, and hugely improve collaboration. Front-end designers are those designers who have enough of a grasp of software development to build fully functional coded prototypes, thereby bridging the different disciplines in product teams. Brad Frost, creator of Atomic Design, sums up the role<\/a> really well:<\/p>\n

\u201cSomewhere between design\u200a\u2014\u200aa world of personas, pixels, and polish\u200a\u2014\u200aand engineering\u200a\u2014\u200aa world of logic, loops, and Linux\u200a\u2014\u200alies frontend design. Frontend design involves creating the HTML, CSS, and presentational JavaScript code that makes up a user interface.\u201d<\/span><\/p>\n

<\/p>\n

\"frontend<\/a>

Image credit: Brad Frost<\/a><\/p><\/div>\n

The front end designer is a fairly emergent role, showing how product teams can evolve as people develop new skills and interests. Therefore, when it comes to working in Agile, maybe the separation between design and development isn\u2019t as clear as it first seems. As Frost puts it:<\/p>\n

\u201cEmbrace the fuzziness, encourage front-end designers to exist between worlds, and let collaboration and great work ensue.\u201d<\/span><\/p>\n

Design is never done<\/h1>\n

Overall, we\u2019ve looked at how design in the software industry can end up being carried out in isolation - mainly due to the different workflows of design and development. It\u2019s true that it\u2019s a challenge to get Agile and design to play well together, but the first step to tackling it can simply be to get the right type of people in your team. With the right mix of people and skills, it can become evident that an actual handoff point doesn't really exist, as great makers know that design is never done.<\/p>\n

\n

design is never done. pic.twitter.com\/aSa7QOyBk7<\/a><\/p>\n

— Luke Wroblewski (@LukeW) October 5, 2016<\/a><\/p><\/span><\/blockquote>\n