Welcome to our Design Talks series dedicated to sharing the insights of thought leaders and top people engaged in design from around the world. We interview experts who work with design in different contexts, with different objectives, and through different approaches. In these series, we hope to provide intellectual and creative inspiration to all of our readers.
Designers often struggle to work with developers and vice versa. Teams on both sides could learn a tremendous amount from each other, yet layers of resistance remain. This week’s guest is Aarron Walter, VP of Design Education at InVision and we’re going to talk about designer and developer collaboration.
Aarron draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices. He founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million.
His design guidance has helped the White House, the US Department of State, and dozens of major corporations, startups, and venture capitalist firms. He is the author of the best selling book Designing for Emotion from A Book Apart. You’ll find @aarron on Twitter sharing thoughts on design and you can learn more about Aarron at aarronwalter.com.
On the Design Better Podcast hosts Aarron Walter and Eli Woolery interview design leaders and influencers who share stories of how they solve problems and their career path. Guests include David Kelley (IDEO co-founder and Stanford d.school founder), Julie Zhuo (VP of Product and Design at Facebook), and Jake Knapp (best selling author of Sprint) among others.
Hello Aarron, it’s a pleasure to have you on the Toptal Design Blog. Are developers from Mars and designers from Venus?
In my experience, designers and developers probably have more in common than they realize, but there are definitely some distinct differences in the way that we think about things. Designers love to think about design systems, and developers think about modular code that’s easy to maintain. But the way that we go about it may be slightly different.
Developers have found ways to break their work down into smaller pieces, and designers tend to think about the whole thing as the “whole cake,” and how do we eat the whole cake.
This is a point where they start to butt heads. Engineers want to be able to ship code in small steps and make something very quickly as part of the Agile methodology. Designers tend to want to take a big step forward in a holistic manner—they want to deliver a consistent experience. That can be a point of contention for these two groups.
What can designers do to bring developers over a little to our perspective? How do designers make developers understand that every little feature shipped is about the experience as well?
There’s an opportunity for both sides to bend here. Designers are sometimes trying to convince a developer that we need to wait and build the whole thing, and then get it out the door as this beautiful, complete experience.
But if the creation cycle is too long, products run the risk of being killed. People start to lose interest. They may say: “Is this actually creating value for the business? We’re spending a ton of time and energy and resources on this thing, why is it taking so long?” Designers need to think more about the cycle of business.
If Apple ships a phone—a piece of hardware that has a problem—it could potentially cost them billions of dollars, but if software is shipped and there is a problem, we can just patch it, fix it, and ship again. Approaching the process in this way allows us to connect back into the development work cycle more elegantly.
Designers could also try to bridge the gap between the two groups by getting engineers involved in the design process early on so they feel included in the early ideation phase, not just downstream. Designers may say: “We came up with this brilliant idea, go make it for us!” and that makes developers feel that they’re not part of the ideation process. They’re just the hands and someone else is the brain.
The most dysfunctional relationship between designers and developers happens when there is a distinct division of labor. The more that starts to blend and those teams work together, the better. As a result, there would be multiple perspectives and shared ownership which is really key to designers and developers working effectively together.
On Understanding Each Other’s Space Better…
What can teams do to understand each other’s space better? Should designers familiarize themselves with development and vice versa?
First, designers and developers could talk to customers more and learn about the problem space together. They could talk to three to four customers in the morning over coffee; everyone could learn very quickly and arrive at a shared understanding of what the concerns are.
Second, in terms of the work process, it’s important for designers and developers to have—maybe not fluency—but some understanding of one another’s language. I don’t mean that a designer needs to know how to code, or that developers need to master typography, but at least there is a shared understanding.
If designers could frame things in a language that developers understand—”such and such is not working and that’s bad for business”—then developers would quickly come around to understanding the problem. It’s not something that comes naturally to designers but they need to be better at communicating the value of their work quantitatively, not just qualitatively. The sales team, the marketing team, engineering, product, executives, all of those people are speaking in numbers, they’re speaking quantitatively.
That said, I do believe design brings something very valuable, that there are some things that count that cannot be counted. The customer experience, the joy, the love for the product is super-valuable, and that’s hard to quantify.
It can be quantifiable though, down the line that quality component will bring an ROI that is quantifiable.
Yes, we can reduce customer support costs with design, we can reduce churn, we can increase the speed of on-boarding. Having metrics like that to set your sights on helps design align their efforts to business goals. The more that designers can do that, the more they will be understood. The more that design is valued in the company as a competitive advantage, the more the potential for heavier investment will grow.
On the Pitfalls of Designer and Developer Collaboration…
What are some of the biggest pitfalls that designers and developers working together run into?
One of the biggest pitfalls is not having a shared language, not having shared goals, and ratios being very disproportionate. Sometimes there are cross-functional teams with one designer and 75 engineers. That sounds insane, but it’s pretty common.
The vast majority of those situations are not good. That lone designer is an expatriate. They’re a stranger in a strange land where they never quite fit into the culture… and their value system is different than the value system of all of their colleagues.
In that environment, making a case for a UX feature is extremely challenging for a designer: “We should have this animation in the product because it’s going to create a more compelling experience…” when there are 75 engineers who say: “That’s 250 more lines of code and two extra days of work. Is it really worth it?” And it’s probably not. To them, it will seem like “frosting.” But those animated micro-interactions to a UX designer really do shape the customer experience. They’re not the only thing, but they are important.
When you have those uneven ratios between designers and developers, it becomes really problematic. However, there are solutions. Companies like Slack solve this issue with “paired design.” If there is one designer to 10 engineers on one team, and the same ratio on another team, those solo designers spend about eight hours a week working together, presenting solutions to one another: “Here’s how I’m solving this problem, does this make sense to you? Is there a better way to do this?” They can help each other get unstuck and not feel like they’re on an island.
On Designers Conveying the Importance of UX…
How can designers emphasize the importance of human-centered design with developers who don’t really understand HCD? For example, how do designers convey that adding features doesn’t necessarily serve the customer, that the experience of using the product is more important than its features?
There are a couple of effective ways to do it. Most designers have probably done it in an ineffective way by telling developers directly: “Hey, adding more features doesn’t make a better experience. People say they want it, but it actually just makes the product more complicated,” and developers are likely to respond: “I don’t think you’re right, that’s an opinion. We hear this from our customers, so we should follow them.”
It’s best not to tackle it head-on, but to do it in a sideways fashion and say: “Let’s understand the problem space better together.” I’ve bought lunch for us tomorrow, and I have arranged to show you five of our customers using our product.
I have seen engineers squirm in their seats when they watch a customer actually using the product, and realize: “We made something that’s pretty difficult to use, and people get frustrated by that.” Engineers want to do great work, just like designers. Oftentimes, they simply don’t have the opportunity to see the outcome of their work.
You’ve probably heard of Jeff Gothelf preach that we should focus on “outcomes, not outputs.” That is another way we can reframe our thinking, that an output is: “we shipped five more features,” vs an outcome: “we reduced churn by 10%.”
On the Future of Designer and Developer Collaboration…
You talk to a lot of companies and see many design and developer teams working together. The tools, environments, and methodologies are changing. What does the future hold for the designer/developer relationship?
There’s brackish water developing—when saltwater and freshwater blend together—there’s a coalescence of engineering and design tools. Instead of a process that feels like a handoff where everything that’s design is here and everything that’s engineering is over there, they start to blend together.
To that extent, we’re seeing designers spending a lot of time in Jira, thinking in user stories, and starting to think with an engineering mindset as well. And vice versa, we’re seeing engineers using tools like InVision Inspect, where they see specs and the breakdown of a design system, and understanding the components of how it all fits together. Due to these tools and a blending of disciplines, a shared understanding is developing.
Further reading on the Toptal Design Blog:
Understanding the basics
Using a coding language, developers take care of the core structure of a website or app, while designers design its "look and feel" (the aesthetic and experience). Simply put, a designer "architects" and developers "construct."
The two roles are slowly merging, and it’s becoming important for designers and developers to have some understanding of one another's language. Nevertheless, although their functions may overlap, there are clear differences between the two, and it is advisable to become expert in one or the other.
A web designer is responsible for planning and creating the design and layout of a website; at times they may also code it. They must be able to make a website aesthetically pleasing, as well as functional and easy to use.
Agile refers to a set of “methods and practices based on the values and principles expressed in the Agile Manifesto.” Scrum is an agile framework for managing knowledge work. A sprint (or iteration) is the basic unit of development in Scrum.
Developed at Google with an intention to bring together teams under a shared vision with distinct goals and deliverables, a design sprint is a method used for solving problems through ideation, prototyping, and testing ideas with specifically targeted users.
A focused, five-day process, a design sprint gives teams the opportunity to quickly test ideas and gather insights on customers, answer critical business questions, prototype and validate ideas without building and launching a product. It also fosters better designer and developer collaboration.