Great design doesn’t happen in a vacuum.
Designing incredible software cannot be done alone. A strong partnership between product, design and engineering is critical for managing cohesion and consistency, avoiding technical and design debt, and above all, creating a best in class user experience.
My process
Kickoff
What are we doing and why? How will this feature add value to the user and our product? I like to answer these questions through user stories and requirements gathering. I aim to understand as much of the backend as possible, as this provides a more holistic view.
Strategy & white-boarding
If handoff is the first time a developer sees designs, that’s about 5 steps too late. Bringing together product, design, and engineering early to diagram ideas and map out technical constraints helps to break down complex requirements, establishes a better MVP, and builds designer/developer trust.
Low-fidelity sketches and mockups
I’ll walk product and engineering through early stage mockups to work through any blind spots. Here we’ll discuss detailed interactions and ensure designs are meeting technical requirements. Engineers can start estimating work.
High-fidelity designs
Now that a solid groundwork has been established, I feel comfortable disappearing into Figma for a while to work through polished designs, including all flows, use cases, and states. If there’s a design system, I’ll note which components we can pull and which components we’ll need to build.
Documentation & handoff
I’ll now present the team with final walkthroughs, usually using a prototype. This allows for any additional functionality questions to be addressed. We’ll take a tour of the file, ensuring all documentation is accounted for and understood by engineers.
Build, QA, Launch
I’ll create checkins with engineers to QA as we go, ensuring pixel perfect designs. This is much easier now because engineering context has been built over the course of the design process, rather than a single handoff at the very end.
But this takes forever, right?
Why I prefer this approach when building complex software
Reducing both technical and design debt is especially important when building complex systems. Spending a little extra time upfront on strategy helps us build reciprocal awareness, which means less design/technical debt down the road. This not only saves way more time later but also creates a more cohesive and consistent user experience.
Taking a bit more time to document things also helps everyone understand the feature better. This makes it easier for designers and developers to work together smoothly, avoiding last minute changes or the dreaded “oops, we forgot about this use case!” when you’re almost at the end of a sprint…
Adding the Design QA step in as we go keeps our sprints focused and reduces unnecessary triage tickets after the feature launches.
“Consistency is one of the main tenets of good product design. Over time, as a product is designed and developed, inconsistencies inevitably crop up. Over time this can add up and turn into design debt.”
- Austin Knight, Design Debt
I’m passionate about this subject!
Want to take a deeper dive into my philosophy around reducing debt in products? Check out this presentation I gave at a past company to persuade our teams to adopt an official QA process.