Senior Product Manager
“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:
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.
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.
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:
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.
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:
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.
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.
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.