Between 2012 and 2017, we’ve 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.
Despite the large design push, Design to Dev Ratios Atlassian 1:9
Intercom 1:5 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 as engineers are embracing design in the design thinking movement.
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’t always mean both are working together. They’re just present because they’re told to be there by managers. As Intercom put it:
“When design is seen as a satellite that orbits engineering, it usually comes crashing back to earth.”
The reality is that a designer’s job on a project doesn’t stop at a specific handoff point with developers – it’s 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’t have design without development to deliver great products, so let’s look at some of the problems and solutions of working together better.
Design meets development
“It doesn’t matter if you’re a designer or developer – neither want to ship a bad product.”
Despite the shared overall goal, it can be a challenge to get these two disciplines to work well together. Where a designer’s 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 ‘Agile’. As James Archer, CEO of design agency Forty puts it, the two ways of working simply don’t blend together very smoothly at first:
Agile developers can get frustrated with designers for overthinking things (“Why can’t they just let it go? We can get to that later.”), while the designers get discouraged by the perceived low standards of Agile developers (“Don’t you want it to be good? Don’t you want the user to be happy?”).
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’t always ideal. In fact, both sides should start by understanding each other. To get a clearer picture of what’s going on , let’s first define what Agile actually is, and how it relates to design:
The basics of Agile for designers
If you’re working in any tech company, no matter what your role, you’ve probably heard the term “Agile” used within your development team – it’s often followed by words like “Scrum” and “Sprint”. It can seem a little overwhelming at first as if it’s a new language with its own rules, but it’s not just for technical people. Reading these two definitions, it can actually become surprisingly clearer to anyone:
Agile is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.
Scrum is an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work.
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’s a concrete product being produced.
According to Andrew Littlefield of Trello, Scrum has been used by everyone including marketing agencies and construction crews. He goes on to say that scrum can even be applied for email campaigns, as well as software.
Now we’ve covered how developers work in Agile, let’s look at some of the challenges of bringing it together with design.
A designer’s job on a project doesn’t stop at a specific handoff point with developers.
Working together better
Agile is fantastic for producing results and well adopted by most software development teams, so it’s unlikely to go away. Hoa Loranga, 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.
Despite Nobody wants to revert back to the waterfall approach. this preference for Agile, it doesn’t 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’t even something new to design in software environments though.
Dave Malouf, in ‘Agile is Reducing the Value of Your Design Team’, went as far as suggesting that designers working under certified agile methods aren’t designing their designs at all. Even though they’re shipping, he explains how Scrum doesn’t make room for the following 3 items that make design unique from engineering: empathy, creativity and vision.
“Scrum doesn’t make room for 3 items that make design unique from engineering: empathy, creativity and vision.”
Since Agile is so effective in delivering working code, it’s unlikely to be going anywhere. Therefore, how can we make design work better and deliver more effective user experiences within agile’s 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 ‘designer’ or ‘developer’ boxes, it’s common nowadays for people to drift between the two.
“Designers have to embrace engineering culture just as much as engineers are embracing design”
What makes and breaks a product team, according to Intercom, can often be the relationship 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:
“A 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.”
This ensures designers and developers are always on the same page and well aware of how each other works – or as Spotify’s VP of design, Rochelle King said, it ensures design is never done in a vacuum.
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.
The T-Shaped Designer
Similar to creating more diverse teams, another approach set out by IDEO’s Tim Brown is to create a team of ‘T Shaped’ designers. As previously mentioned, it’s 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, who provides a great introduction to becoming a T-Shaped.
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.
“Becoming T-Shaped creates more empathy between team members, increasing the quality of collaboration.”
Leading on from the T-Shaped designer is the important role of the ‘Front-end designer’. These people can really 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 really well:
“Embrace the fuzziness, encourage front-end designers to exist between worlds, and let collaboration and great work ensue.”
Design is never done
Overall, we’ve 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’s true that it’s 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.
design is never done. pic.twitter.com/aSa7QOyBk7
— Luke Wroblewski (@LukeW) October 5, 2016
Once those people are in place, the different tools and methodologies available can be used to help improve collaboration more effectively – things like Design Thinking, Agile UX, GV Design Sprints, Lean UX, and more jargon-filled methodologies. All of these can blend skills and disciplines available in different ways, and this is what we’ll explore in my sequel post, The Basics of Design Sprints and Other Jargon ????.