Humans love step-by-step tutorials. As the editor of a design publication myself, it’s not uncommon to see articles such as “The 10 Steps to the Perfect Developer Handoff” or “The Do’s and Don’ts of Documenting Your Designs.” They get a lot of traction with an audience of designers looking for guidance before executing some of their day-to-day tasks. Most of these guides include tactical tips on how to label design files, organize folders, or examples of best-in-class documentation that are proven to work for 10 out of 10 teams out there.
Prescriptive guides on how to hand off designs to developers are easy to follow and cross out from one’s list. But are they future-proof enough?
The truth is there are a thousand different ways of organizing files, labeling folders, or handling version control. Pointing out one right way of doing it can lead to a myopic view that every team has the same needs, or that every organization operates the same way.
The tools we use change every day. Designers are working in companies of all shapes and sizes, from multiple industries, each with its own unique organizational structure and challenges that greatly influence their workflow, tooling, and processes. Even within the same organization, timelines and team configurations can look drastically different across the many projects we work on.
Great collaboration is about principles, not tactics
After 15 years in the industry, I’ve seen many iterations of the design-dev workflow. Believe it or not, when I started in design, we used to save local files on our computers containing renderings of our designs. Files would then be thrown over the fence to developers who would have to open them and manually translate our somewhat subjective aesthetic decisions into numbers that could be utilized in their code.
Throughout those years, the way designers and devs collaborate has changed many times. Some methods worked better than others — and in many instances, a method that worked well with one project ended up being a disaster with the following one. If I were to write specific guidelines, they would have to be rewritten every few weeks — so I would rather focus on principles. Principles not only have a longer shelf life, but they also tend to make for a smoother process for design teams of all shapes and sizes.
Collaboration between a designer and a developer (Fabricio Teixeira and Vanessa Sant’Anna at the Work & Co office in Brooklyn, New York).The list that follows outlines my own personal principles as a designer who invests at least a third of his day working with developers iterating and implementing designs. While specific methods and techniques have changed considerably over the years, these principles still resist the challenge of time.
1. The developer is your user
What if we gave the same care and attention to how developers will consume our designs (and design documentation) as we do into how users will?
As designers, we always keep our users’ needs and pain points in mind when envisioning our product experience. Unless you are programming the experience yourself, the end user will never interact with our designs; they will interact with the final product, built by developers, based on our design documentation. Which means that the real users of what we are delivering at that stage of the project are the developers.
Once we incorporate that notion into our practice, every single decision about our workflow starts with developers at the center. Similarly to how we run research with end users, we can set up interview sessions with the engineering team at the start of a project to understand their preferences, journey, pain points — and come up with a working model that delivers on their needs.
- How do developers want to receive documentation? How often? Through what channels?
- How much detail is too much detail? What is the right balance between written and visual documentation?
- What is the most efficient way for that particular group of developers to consume the non-visual rules of how the system is supposed to work? How does that align with other parts of the product and other groups within the organization?
The team may want to set up a wiki for the project; maybe your documentation is actually a meeting that happens twice a week and functions more as a Q&A session. Some teams won’t start hands-on development until all use cases are documented; other teams are more flexible about defining rules through iteration and experimentation.
In the same way we adapt our design solutions to what users need, we should adapt our design workflow to accommodate the needs of our development partners.
2. The only certainty is change
Designers need to be flexible. We not only have to flex our process to accommodate different team configurations, but also adapt our workflow as the project unfolds.
With very few exceptions, we will have to adapt our documentation and workflow every time we start a new project. As we gain experience, we learn how to produce documentation in certain ways, which might work well in a particular context but not necessarily in another. There is no one way of handling design documentation and collaboration that works across every team.
The other aspect is the individual developer’s personality. We might be working with a developer that truly appreciates when a designer walks over to their desk, so they can work together — literally side by side — on tackling specific challenges. Meanwhile, another developer, who is part of the same team, might prefer to keep their headphones on to maintain their flow, and have questions be addressed through Slack messages or comments on tickets.
Not everything is in your control as a designer. The only certainty is change. But on every project, you can anticipate changes outside of a designer’s domain that in turn can impact the work: new stakeholders joining the team, abrupt changes in release dates, and unforeseen platform or technology constraints. Learning to identify the invisible collaboration mechanics within a team and to prepare yourself to rapidly adapt your workflow will not only avoid frustrations in the short term, but make you a better collaborator in the long run.
3. A design is never done
When we have completed the designs of a project, we have only done half of the work.
Especially in waterfall projects — but also in more agile set-ups — there’s this common misconception that the work of a designer is finished as soon as all screens have been designed. Having completed, tangible artifacts, such as design mockups and prototypes, can create the false illusion that the designer’s responsibilities have been fulfilled. The reality is that we should be thinking less about screens, and more about features — and features happen mostly behind the screen.
The real challenge starts when developers start poking around and asking questions about our designs, and when quality assurance analysts start thinking about use cases we couldn’t foresee. The more constraints and rules are added, the harder we have to work around those to accommodate new requirements while preserving the simplicity and clarity of the experience. That’s the moment of truth: the point where most teams can draw the line between good and great designers.
Too often I’ve seen designers willing to shift accountability — which is never great. If the final experience wasn’t implemented as we envisioned, that’s as much our responsibility as it is anyone else’s. Our role is to create experiences that are smart and easy to use, not mockups that look good to the eyes. And that means we are responsible for the final product that gets implemented by our teams.
One of legendary designer Dieter Rams’ principles of good design is that it should be long-lasting. Image credit Kirill Zhylinsky.4. Less, but better
Instead of feeling frustrated when product managers cut down product features to get to an MVP, designers could turn it into an opportunity to increase the quality of the experience within the feature set we are delivering.
Visionary German designer Dieter Rams has become one of the most recognized and influential designers of the 20th century. A firm believer in Functionalism, his rational vision of design is summarized by his famous phrase: “Less, but better.” While he was obviously referring to industrial design back then, the concept still holds true when it comes to the digital products and services we are creating in our day and age.
As a design evolves, product managers start to prioritize features, and designers see a lot of their work — their initial vision for the product and its experience — shrink to the MVP, which can be frustrating. The best designers I know are able to turn that frustration into an opportunity. They understand it’s completely fine to deliver fewer features, as long as you deliver them better and focus on the quality of the experience you’re creating.
For us designers, fewer features to be designed means:
- We can invest more time documenting everything properly: transitions, states, animations, copy.
- We can work more closely with developers to ensure we are communicating our original vision properly.
5. Passion is contagious
In certain companies, developers are not involved in early concepting, design explorations, and strategic product discussions with product managers. How can we help bridge that gap and help them understand the bigger picture of what they are building?
While developers have some understanding of the business context in which the product is being developed, they may not have all of the different perspectives we do as designers. Developers haven’t necessarily spoken to users in research sessions to learn about how they engage with our current experience. They may not have a clear understanding of how a particular feature they are developing will have an impact on people’s lives.
Designers represent the voice of users in the team. We often take for granted our natural ability to put ourselves in our users’ shoes, and forget that we can have an important role in spreading that sentiment across our teams. It might be a quick anecdote we heard from users during research; or it might be a personal story from someone whose life has completely changed because of what we are creating. Our empathy, our focus on users, and our passion — those are valuable resources we can use to inspire developers and help them understand not only how a certain feature is supposed to work but how it’s going to impact people’s lives.
Design is a team sport
The old stereotype of the “rockstar designer” is (thankfully) disappearing. As digital teams grow and projects become more complex, designers are being valued for their collaboration skills and team enablement rather than specific deliverables. Defining the principles of how we want to handle design collaboration inside our teams is the first step towards being more intentional in our practice.