Craft design statements in handoffs
It’s the end of 2018. 🎉🎉🎉
Congrats if you and your team accomplished your design sprints throughout the year. Plenty of your design ideas made to the product. Some of them are in the queue for development. It feels good to take a retro moment and review what you have learned and contributed.
How do you usually construct your design handoffs to collaborate with the development team? What are the most effective practices you want to keep in the new year? What are the ineffective ones you want to discontinue?
Delivering a design story is like crafting a fiction. Many parameters come into play. Research docs, wireframes, designs, and specs are meaningless pieces if they are not bound together to tell a story.
The challenge is, among all kinds of design deliverables, is there a magic cheatsheet that drives successful dev and design collaborations?
Devs skip your research docs 📝
User research docs reveal crucial insights about a product, as well as its users. However, insights don’t go into the code base directly. To meet tight deadlines, devs may skip the research docs you attached and only pick up your design assets instead.
When design interns came to me and asked about what design deliverables we should provide in the development tickets, I speculated that a handoff cheatsheet is a customized formula. It differs from product to product. To validate the consumption, we experimented in a few design sprints to learn about organizing assets and writing statements for our design deliverables.
In our team, when designs are complete, we host design demo sessions to handoff final designs with the development team. To us, a demo session is a heads-up. It leaves rooms for developers to estimate the efforts of implementing new features. Static screens with specs are accepted broadly because they document all states and instances of the product. Animations and motion effects that communicate transitional states are less critical for development, even though they are fancy and fun to look at.
At times, devs come to us to learn about the UX thinking behind the arrangement of elements on screens. In the past, I was asked why an “X” icon was shown when a “Cancel” option was provided on the same dialog.
These questions are gold.
Development efforts should be channeled into lifting designs that solve real problems. For that question, I shared user testing results in which I tested to see how users cancel requests in different flows. An “X” is perceived faster than a “cancel” button to call for the same action. It’s useful to present both options when we want users to read and dismiss information quickly. After sharing my learnings, we agreed that the “X” can be built as a persistent UX pattern for other use cases alike.
Yet sometimes, research docs can overcomplicate the handoff process. 🤣
Previously, I was trapped by designing mute and unmute button states for a video conferencing app. Since muting and unmuting audio is extremely common during video calls, the mute state should be as intuitive as possible. In my early explorations, I designed the mute button to be either left or right crossed-out.
I looked into other conferencing products and I couldn’t find an option that was more outstanding and universally accepted. After a plethora of clicking tests, user interviews and internal discussions with our audio engineers, we couldn’t come to a conclusion. Eventually, I had to pick the variation that was more consistent with our design system. If I included all the studies I did for an icon in the development tickets, it would make the ground muddy again.
In design schools, we are trained to deliver a competent design process that includes everything. We sweat in critiques when every detail of our design can be questioned. Yet at work, we are trusted to own design decisions and truncate our presentations if needed. To reduce the cost of communication, less can mean more.
Craft design statements in handoffs 🎨
To communicate in fewer words, you need a design statement that validates your design idea and makes sense of your designs to other teammates.
A strong design statement delivers the crucial information of your design attempt. It is an actionable sentence that leads to your user flows, user stories, and mockups. It is divergent and convergent to allow the flexibility in cross-functional discussions.
A product manager may use jargons and metrics in the write-ups. You shouldn’t. 😑
Alternatively, your design statement should be easy-to-read for a wide range of audience to understand your intent. A business development manager can check if your design attempts have transformed business requirements accurately. A developer can understand the situation in which users encounter a problem and why and how it is solved. A QA person can structure the testing paths via the solution you pictured. Your statement should seize all the key initiatives for different people before they dive into your designs.
But how? Here’s a handy template that Design Libs created for drafting design statements. I’ve been using it frequently to check if my writings consist of the fundamental pieces I want to communicate.
From their templates, you can massage the statements based on the features you are assigned to.
A job story and a user story is similar. Choose either one if you want to elaborate needs and motives from a user’s perspective. Let’s say you are designing a signup flow for Lyft, your statement would be:
For features that are introduced to address known issues, you can use a key insight or a problem statement. They target your design proposal for specific problems. Let’s say you are designing a shopping experience for Amazon during holiday seasons; your statement should drill down users’ pain points, summarize the problem, and project the impact your designs would make.
What about MVP features that sit in the sprint backlog?
They might be users’ requests from customer supports’ tickets or ideas collected from Hackathon projects. These features reveal potentials of what your product could do/have. Stories are needed to bring people on board so that they can be planned into roadmaps.
In this scenario, a how-might-we statement or a point-of-view statement will be suitable. These statements are to open up room for brainstorms and discussions. Let’s say you want to improve the email inbox experience for mobile users; your statement would be more of an inquiry.
Summary notes 💬
Write a story. Craft a narrative. Designers not only speak on behalf of users but also speak to the people who bring ideas to the ground.
Learning to write design statements will strengthen your skills to communicate cross-functionally. The impacts you make will go beyond the product you design and reach out to anyone who reads and resonates with your stories.
We have NPS and all kinds of surveys to measure the happiness of our users because we transform their feedback into better products. But we haven’t assessed our colleagues’ thoughts on the design handoffs. If user stories are stories, why design handoffs are not?
If you like this post, kindly share a clap 👏 or some thoughts 💬 with me! I write stories for designers and others who want to learn about product design. Thanks for reading!
