Designer’s Guide to Working with Developers
Seamless cooperation with designers and developers is essential for getting high quality software out there, on time and on budget. In this post, I will discuss my learnings as a designer how to work with developers. I hope some developers will find this interesting too.
There’s some history
I was a developer once. In the late 80s I earned my living by writing C++ for educational software for schools. At that time, digital designers didn’t exist; we designed everything that we implemented. I actually designed my first commercial product in 1986, which means that I’m now in my fourth decade of design. (Ouch.)
Later on, I found out that I was more interested in what makes the designs easy-to-use and fit the purpose, rather than building the software itself. In the early 90s I abandoned coding completely and concentrated in the research and design of interactive software and services.
Yet because of my past, I still have a strong interest in how things work and how software is written. Software development is nowadays much more complex than what it used to be. Therefore, I have a great respect for the developers of today.
Jumping to conclusions
This is the list of my recommendations for designers how they can best work with developers:
- gain mutual respect
- avoid silos and camps
- involve developers early
- work in the same sprints
- review wireframes with developers
- use modern tools for the details
- do your part as a designer
- let them shine
I’ll describe these a bit more in detail below.
Gain mutual respect
I respect developers and I’m always working hard to earn their respect back. I think this is the starting point of good collaboration. We both do our parts, we understand where our skill sets overlap, and we share the same language. When this happens, the collaboration is smooth, the results exceed everyone’s expectations, and we enjoy while doing it.
Avoid silos and camps
The starting point for a good collaboration is that we feel that designers and developers are on the same team. We share common goals and work together to achieve them.
Sometimes I’ve seen situations where designers are “us” and developers are “them”. Designers design and hand over the specs to “them”. If any issues arise, the finger pointing starts: “your specs were not accurate” or “they implemented it wrong”. This is a situation that you want to avoid at any cost.
To avoid developer and designer camps, first adjust your own attitude. As a designer, you must acknowledge that the developer is your best friend. They are the ones that actually make your vision real. We are indeed on the same side. Second, consciously break any looming camps. Go mingle: don’t go out to lunch with other designers but hang out with the developers. Nothing breaks the silos better than everyday socializing, deep discussions, joking and banter. It’s a win-win: your work will be easier, and you get lots of new best friends.
Involve developers early, just like designers
Designers are involved in all different phases of the project, from early business design and concept creation, through detailed design to daily development support. In each of these phases, you must involve the development as well. Not just out of courtesy, but because developers have an essential role there, and you will need their help.
In early concept phases, when designers plan for the consumer or user journeys, the developers start defining the overall software architecture, required components, libraries, tools, and development environment. You want to work together: some design decisions will have an impact on the software architecture, and some architecture decisions will have a big impact on what you can design later. The better the developers understand the big picture, the better they can support your designer vision.
While the designer probably wants to work with the product owner to plan for release plan for the product of the service — of which the first one is the MVP — the developers will need to define their architectural decisions so that they can at the same time implement the MVP but plan for the consequent releases so that they can keep evolving instead of refactoring the code. By working together early on, the next releases will be much smoother.
Work in the same sprints
When you truly collaborate, the designers and the developers feel equally the ownership and the responsibility to deliver working software. This requires that you plan the design and development together. I will not here dig deeper into the challenges of integrating design and development in the agile process. There are good existing practices, and applying the dual-track agile will solve many of the issues in your daily work.
A good scrum master can take design into account when planning the sprints. Unfortunately, not many scrum masters have the experience in defining tasks for designers. Therefore, it’s important that designers are proactive in this. You need to request visibility over a couple of upcoming sprints so that you can prepare designs ahead of the time when developers start working on them. If you end up in a situation where a developer starts coding features that you haven’t designed yet, then you will end up in rushed designs, changing designs during coding, and unhappy developers and designers alike.
Review wireframes with developers
I’m mostly an interaction designer, concentrating on the logic and structure of the user interfaces that I visualize with wireframes and simple interactive prototypes. I will always need a visual designer (and possibly a motion designer) to design the detailed appearance and final dynamic behavior. Some designers can do both, but not me.
I have experienced that the best way to work with developers is to walk through the wireframe designs with them before the detailed design. This typically takes place1–2 sprints before they will be under implementation.
I think I have a relatively good grasp of what kind of designs are easy or difficult to implement, but nevertheless, the wireframe reviews with developers always bring surprises. Some designs can be trickier than I thought, and on the other hand, developers may have techniques and libraries that I haven’t known about. Quite often after these discussions, I have got loads of new inspiration for the design, fuelled by the technical possibilities that I didn’t know existed.
One observation that I have made very early in my career is that if something is difficult to implement, it is probably also difficult for the user. This is due to the fact that you then probably use tailor-made components that users are not familiar with, or the internal logic in the user interface is so complex that the user doesn’t understand it. If you use familiar components and simple interaction logic, it’s easy to implement and easy for the user.
If it’s complex to implement, it’s probably complex for the user.
Use modern tools for the details
The final quality of the user experience is in the details. The implementation must be beautiful, elegant, fast, and every detail must be in place in just the right way.
Many of the earlier walk-throughs and reviews with the developers can be done using sketches, illustrations, simple prototypes, and verbal descriptions. For the fine details, modern design tools will help you a lot and ensure that the details are conveyed exactly right. For example, with Zeplin, the developers don’t need to guess or estimate anything based on page layouts — they can just copy-paste the exact values for margins, font sizes, color codes, etc. My recommendation here is clear: find a preferred shared tool for this and use it. It will save time, eliminate unnecessary errors, and improve the quality.
Another tool that I can recommend is to build a shared Design Language System (DLS). That helps both designers and developers to avoid unnecessary repetitive work and improves the overall quality.
Note that these are still only tools. They will provide you the numbers but not the meaning. You still need to complement this with some quality face time.
Do your part as a designer
In order to gain the trust of the developers, the designers must do their part, and a bit more.
When the designs need to be ready, they need to be ready. They need to be clear and consistent. Don’t change the designs during the implementation, unless you absolutely have to, because nothing is more frustrating than throwing out code that was already finished. Be ready to make a compromise in the places that are less relevant for the final user experience.
Your designs will never be unambiguous; if they are, you write too much specs. You will learn who of the developers can fill in more gaps, and who need more specific designs.
Be available, and be ready to answer any questions and improvise the rest of the details on the go. If a developer needs help, provide it.
Do your part in the team routines. Participate in sprint planning, backlog grooming, daily stand-ups, and especially retrospectives to improve the collaboration. In the sprint demos, always let the developers present the implemented designs. They are their children just as much as yours.
At Nordkapp we work in close partnership with our clients. We provide feasible, viable and beautiful designs, but we also help our clients to develop their design capabilities and practices. If you are interested in developing yours, drop us a line.
