Me: The relations between designers and developers seem to be so dramatic. Shakespeare would definitely write a play on their collaboration problem if there were product teams in his time.
Maksym: The problem is overhyped. There is no such issue that cannot be fixed by communication.
Me: Designers and developers don't understand each other. Millions of search results on the keyword “designer-developer collaboration” prove that.
Maksym: 7 years of experience in design prove that if you have both designers and developers in your team, you’ve already solved your greatest design collaboration problem.
That’s me vainly trying to get to the collaborative secrets of Eleken’s design director Maksym.
Maksym has been working with dozens of development teams — small and big, vetted and novice, development-driven and user-centric teams. Maksym learned to handle them all, and now he sees no problem in designer-developer collaboration.
Yet I managed to get to the memories when Maksym was a junior designer, Eleken’s workflows were unestablished, and designers-developers collaboration problems existed together with the ways to address them.
Take a seat there and listen up.
Concurrent designer and developer collaboration
Design and development processes line up naturally one after another because engineers can proceed with the development only when they have mockups ready. But in this sequential case, we get a moment of friction when designers pass a baton to developers:
- Designers may overlook engineers’ requirements;
- Coders may get the wrong idea of design they need to implement;
- The team would need to go through everything again;
- Deadlines would be on fire;
- The project would sink into chaos.
Designer-developer collaboration glitch in slow-mo:
Such dramatic cases rarely happen, but even a tiny hitch in production means a financial and reputational risk for big fancy software-as-a-service (SaaS) companies. To remove the point of friction, big product companies need UX designers working with developers simultaneously.
Amazon uses the two-pizza rule (if you need more than two pizzas to feed a team, then the team is too big). For Hubspot, a small team looks like one and a half pizzas: one Tech Lead, two developers, one designer, and one Product Manager.
Maksym explains why simultaneous design and development are considered to be the most effective kind of team management:
“Right now I’m working on a project where mockups get implemented as soon as they are approved. A big advantage of this working model is that I get an extra round of edits from engineers when they start implementing my designs. Thus, the risk of missing anything reduces dramatically.”
Concurrent design-development collaboration may work for big fancy product teams. But small startups have different resources and different priorities.
Startups need to build their product from scratch or redesign their minimum viable product (MVP). At the same time, they need to survive with limited resources and avoid fundamental errors that will later screw up the whole business. Flawless designer-developer collaboration is not on the list of priorities as you see.
So SaaS startups rarely shake a 1-2 year development process together with the UI/UX design that otherwise could have been done in 2-3 months. They usually choose between the two options:
- Decide on how their app is going to look and feel without designers
- Organize design and coding sequentially (highly recommended)
No designer-developer collaboration — no problem?
It happens that newborn startups abandon the proven practice of including UI/UX designers in the product teams they build. It might be due to limited time and budget, but more likely it’s because they underestimate the role of user experience design.
Because yes, having no designer on the team will help to keep the project within a tight budget. But having no designer increases the risk of making fundamental errors that will later screw up the whole business:
- The design gets overcomplicated. You know the app is not touched by a designer’s hand the moment you see it. The interface looks like a spacecraft control room (and works just as easily).
- Consistency suffers. Developers work iteratively. They may start small, and then suddenly pivot to something else because “what a cool idea, let’s add this feature too”, but “now we lack that button” and “why don’t we put it in the upper left corner?”
- Mistakes get visible only in the end. It takes tons of time to code an app, and you’ll see the big picture in months, if not years. If you suddenly notice that a big picture looks like a Frankenstein’s monster, it would be too late to redo everything. Product design, in contrast, allows you to quickly and easily ideate and iterate on your app before you've invested in the actual coding process.
Sequential designer and developer collaboration
Eleken specializes in designing for SaaS startups, so a sequential working model is something we are very used to. For several months, we work on a clients’ design moving step by step, in close designer collaborations with a Product Manager or CEO. Only after a couple of months, when all the mockups are ready and approved they land on the developers’ desk.
Maksym explains how it works on the example of TextMagic, the company that hired us to design them some new functionality:
“We worked on one screen at a time, in color at once, since the app already had its own design system. Each screen we approved with a Product Manager and iterated it until he was happy with the result. We didn’t maintain continuous communication with TextMagic’s devs but contacted them occasionally to ask, say, wouldn’t this idea be too hard to implement?”
Sequential collaboration is not as sophisticated as concurrent design and development — the moment when designers pass mockups to developers is full of uncertainty and risks. But this cooperation model still works fine if you know how to apply it.
The short recipe from Eleken looks like this:
It can be decoded as “communicate with a Product Manager (all the time) and developers (when needed). If you want to go into greater detail, here we have five risks of sequential collaboration and the principles of collaboration that reduce the risks:
Designers can miss some details
Designers can’t foresee everything. For instance, at the implementation phase, a way-too-long title appears, and you have to decide whether you show it in full or cut with three dots. Such corner cases get fixed easily when you have designers and developers working together, but can frustrate a tech team that has to sort things out by itself.
Generally, our clients deal with little design gaps by themselves. When they feel they need help, they can check back with us asking for design support. Thus, we’ll fill all the gaps that have arisen and control the design implementation.
Developers can misunderstand the design
This scenario is theoretically possible because mockups usually look like a pile of screens that all look the same.
But UI/UX designers are people who know how to make things intuitive and accessible. To make a pile of mockups easier to grasp, our designers arrange different user flows into different pages in Figma. Inside Figma’s pages, all flows are logically organized, and all screens are labeled.
To facilitate the understanding and the further developers’ work on our designs, we usually supplement them with UI kits. UI kit is a seed of a future design system — it summarizes some UX tips for developers and all standard UI components (such as buttons, inputs, navigations), font, and typography.
With a UI kit, developers can see, for instance, all the buttons in one glance. It allows developers to compose buttons in advance, in all colors, sizes, and forms needed. Later, when they will work on pages, they’ll be able to insert all the UI components in a couple of clicks.
How to Get Along with Designers and Work Well Together
Find out how designers see a perfect product manager — and how to become the one
Get the free eBook
Mockups may turn out to be too complex to implement
For this scenario, it’s supposed that designers do something complicated in a vacuum, never show it to anyone, then say “ta-da” and a tech team suddenly realizes it’s impossible to get this thing into practice on schedule.
Designers don’t usually aim to create something tricky — quite the opposite. If our designers find out their idea can be too complicated, they reach out to developers to figure out if they are okay with this or that element.
Designers may not understand how the code works
In this case, a potentially complicated design element may go unnoticed by a designer.
Just in case something like this happens, we approve our mockups with somebody from a client’s side step by step. If we miss anything, a Product Manager would point at it so we can offer a better option.
The designer’s ego may hinder the collaboration
That’s the situation when the statement “designers don’t aim at creating something tricky” misfires. If designers strive for perfection and fail to see the bigger picture, they may ignore the requirements of schedule, budget, and common sense.
Maksym says he stamps out design-centrism in Eleken:
“A startup is rarely a story of maximalism. More often, it’s a story of giving up small things for the sake of greater success. So I train our designers to think a tad bigger. Not to the scale of a screen or a user flow, but to the scale of the whole business.”
How do you collaborate with designers?
Concurrent design and development are optimal in terms of collaboration. It means both designers and engineers are involved in the design process and the risks of misunderstanding are minimized. That's why established companies often choose this working model.
Startups limited in time and budget, however, prefer the design to be done first and coding later. This working model creates a point of friction when the UI/UX team passes mockups to the Tech team. But the friction can be eliminated, given that the Product Manager acts as a middleman.
The only problem of designer-developer collaboration that can't be fixed is when developers make a startup and forget to hire a UI/UX designer. Please, don't do that if you wish your business a long and happy life.
