A designer, a developer and a product manager walk into a bar …

aiming to improve the collaboration with one another

Original Photo by frank cordoba

“I can list at least 3 things that I will always ask when I look at your design” – unnamed developer

This quote comes from our team retrospective on improving the collaboration between our designers and developers. It stuck with me and eventually ended up triggering the development of a new collaboration tool in our team.

We had already established a tight collaboration between our developers and designers in the design creation process. Still, a steady stream of questions would emerge in our refinement sessions when it was time to break down the design into smaller development-ready chunks. The questions would revolve around smaller, yet important, details such as the error handling when saving user settings. Some questions would solely come up thanks to our engineers’ domain knowledge around how our servers provide information.

We value such discussions between the two disciplines as they help us craft more robust design solutions that can be developed without much interruptions. However, we also thought that it is worth trying to further improve our process due to several recurring challenges:

• Often similar questions needed clarification throughout the different feature implementations we did.
• If questions couldn’t be answered in our refinement sessions it created additional work-in-progress for the design team. They needed to go back to the drawing board which also increased the hand-off time to our developers.
• Some questions would come up too late, thus interrupting the development flow until they could be answered.

Our Intent: We want to improve the efficiency in our product development process by helping designers and developers clarify critical questions early.

This is how the idea behind the “DevSigner Checklist” was born.

Going for a checklist

During our companies Hackweek — a quarterly opportunity to explore new technologies and ideas — we set out to turn our idea into a usable checklist.

Checklists are already used in various fields, such as aviation safety and hospital treatments to reduce errors and improve quality. We wanted to bring these benefits into our world to improve the overall standard of our designs. Also, we wanted to bring the “engineers-eye” even closer to our design process by letting our designers challenge the readiness of their work with the list. Our developers could use it to stimulate thoughts when creating tasks for our next development iteration. As there is little effort required in engaging with a checklist (checking the list, basically) the likeliness for adoption in our team would also be high.

Of course, it also helps that a checklist is a simple tool that we could create in a short time. At the beginning, we were a team of three: One designer, one developer and one product manager (me). Later, more people jumped on board and helped with providing valuable feedback.

Way off the happy path

To make sure that we would have all the right questions on the list, we pushed ourselves to remember all the difficult situations in the past year — we went where no one of us would want to go again. Next to being therapeutically-valuable the exercise proved effective; in a short time, our digital post-it board listed a variety of reoccurring pains. My favorite examples:

• Saving: What to do if the user leaves the screen without saving? What to do if there is a saving error?
• Different states of a page: Is there an empty, error and loading state for this page? Should we show some information earlier if we can, or show it all at once?
• Interaction with the elements on a page: How many possible states does the element have? Is there an animation for switching between states? Does the interaction with an element triggers an animation/state change somewhere else?

It were never the obvious things that needed clarification. Yet, it were still items that are vital to providing a consistent and pleasant experience to our users and also those that would allow our developers to do the implementation without interruptions.

As we are a distributed team our brainstorming sessions looked like this: A web based post-it board (we used Ideaflip) and video conferences.

A tale of pages and elements

We consolidated our post-its into two groups: Questions related to the interaction on a page and questions related to the individual elements on a page. These groups have several subgroups of thematically related questions. We chose a tree diagram that breaks down into branches to help navigate this structure.

And this is how some of the examples from above now look on the checklist:

A detailed look at the checklist; from left to right: Page related interactions / Saving / The whole checklist

In a next iteration, we will strive for making the checklist easier to digest and scan as it has grown larger than expected. To our small group of creators, it already proved helpful as we revisited work-in-progress designs and discovered missing information.

Putting the checklist into action

To us, this first “beta” version of the checklist is already valuable. Still, there is a lot of room to grow — especially in directions that we cannot anticipate yet. Therefore, we will keep using the tool in our team to validate the desired improvements in quality and efficiency. Further, we are showing the tool to as many people as possible to uncover new scenarios and improve the understandability of the list.

Our ambition level is to also use the list as a tool for onboarding new designers and developers. The list should help them understand what information is required and what questions to ask when working with a design.

A worthwhile journey

What fascinated me throughout this side project is the positive mood in our diverse little group. At no point did our discussions turn into a blame game about who has to deliver what. Turning our idea into something that can help us as a team served as a guiding and calming north star.

To some it might seem like we want the checklist to reduce the time we talk to each other. Quite the opposite is true. We simply want to spend our time talking about what’s most important — generating the right conversations, at the right time.

What are your thoughts on the checklist? Have you used similar or totally different approaches to improve collaboration in your team? Our DevSigner checklist has already grown from a loose collection of post-its into a usable tool for us. Still, there is a lot of room for improvement and we are happy about any feedback.

Thanks to Miguel and Cristian — the awesome designer and developer that worked on this as well.