Why Designers & Developers Frustrate One-Another
Why isn’t it easier!?
Product Designers and Developers both share the same responsibility for creating and maintaining products. We both love to solve people’s problems, and dream of providing that perfect experience to end users. So why can working together seem so frustrating at times. And how can we fix it?
In the spirit of collaboration I teamed up with my friend Lisa Jacquiot, a talented Product Designer to co-write this article!
If your product development workflow from research, through design to development looks like an assembly line, you’re going to have a bad time
Assembly lines are great for making repeated processes really efficient. The problem is that when we’re developing new things, nothing is a repeated process. Thinking and decision making are not suited to an assembly line robot.
Doing things like a developer handoff where sketch/figma/pdf/paint files are thrown over the fence from designer to developer indicates you might just have an assembly line on your hands.
Here’s why. If your researchers pass data and insights to product managers, who pass specs to designers, who pass designs to developers, then you have a system like the game Telephone.
What’s worse is that you’re also not utilising everyone’s respective skills. Product managers, Designers, and Engineers are all expert problem solvers, but we all come with different perspectives, and think in different ways.
As soon as any one of us start to think we have all the answers, we’re likely going to miss something.
The remedy is as expected: Involve each other at the various stages of the product development process.
Not everyone needs to be a decision maker at every stage — they just need to be involved enough to offer their unique insights, and provide feedback.
Asking for feedback can be hard because it’s time consuming and our solution is obviously the best anyway, so why even bother, right? Also don’t hurt my feelings please.
But realistically feedback can save you from going down the wrong path early, and provide insights and constraints that can spark new, vastly better ideas.
When starting a new project or task, schedule a design-dev (plus anyone relevant with knowledge) meeting, and work on the high level details for what’s possible. Then as a designer, instead of just escaping into that distraction-free, creative, design-utopia, and reappearing with completed designs, organise a few ~30 minute catch ups at different stages of the process.
Explain the thought-process behind your design decisions, and ask where the difficulties in implementing them might be.
As a developer, clarify when there’s unknowns, or when a design is far harder than anticipated and why. There might be an easy design solution.
This helps reduce the discrepancy between designs and the final product and it can build knowledge, and respect for each other’s skillset.
Our tools promote pixel perfection — but in different ways
It’s not just that designers and developers have different methods of thinking, we also have different tools that don’t always play nicely together.
Think about a standard login screen. From a designers perspective this is a single view. From an engineers perspective this is a dynamic assembly of individual components.
Once coded, the screen to designers might look out of alignment, have the wrong font color, or wrong spacing. And you scream in your head — why can’t you just align the text, and make the colors match my designs. It’s so easy!
Designers think in terms of pixel distances between elements, while developers think in terms of margins and padding. That’s the way our tools work.
To the devs, they can look at the design and think: Oh god no, I need to vertically center a div (ok, it’s easy now with flexbox, but just from habit). But what happens when a bigger screen size is used? How about when it’s rotated, or half screen? And there’s an error state missing.
Let’s say as a designer, you want the page to be responsive to screen sizes. If the tool offers a responsive grid to use. It might just be setting you up to fail since it might not be possible to be coded that way. For example…
And here’s how the UserAvatar in the design above might be created using the popular UI library React.
lastName and image as input properties. It then works out the user’s initials, and displays a 100px circle with either the image, or initials in the case the user doesn’t have an image.The problem is, although the UserAvatar is inside the LoginScreen component, it doesn’t have access to the grid used by the LoginScreen.
There’s a mismatch in how our tooling makes us think.
The solution? User flows, prototypes, and (again) two-way feedback!
Design for different screen sizes and orientations: create a list of the most common screen cut-off points based on the device breakdown for your product.
And don’t leave it up to the dev to connect the dots between still screens. It takes up their time and is error-prone. Provide them with clear flows mapping and connecting the different screens. For interactions — create a quick prototype showing how a page is supposed to load, or how to navigate your app.
Make a list of different states and produce designs for each state: empty states, first time user states, error states, logged in/out, loading states, partial content.
And for best results, sprinkle more feedback throughout.
Design Systems
The “Design System” is the perfect middle ground. Right? Well…
Yes! If it’s implemented in code. The reason why design systems are great is because it breaks up a product’s interface design into fundamental components, similar to how developers already work. It constrains design components to be consistent
When this system is implemented in code, for example in a UI component library, designers and developers are talking the same language!
Designers can use the fundamental components in their designs knowing the features and constraints of doing so. And developers can use the components directly from their prebuilt UI library in the components they build.
There is a drawback of design systems however. They are a ton of work to create and maintain for both the designers and developers. Seriously, a lot!
However, if you don’t mind not having a fully custom design system, there are a number of open source design systems such as Material Design or Bumbag that have accompanying UI component libraries that promote great design practices and accessibility by default.
That’s it, go forth and build cool stuff together!
