What’s The Perfect Design Process?

Design process is messy. You might be following a structured approach, but with all the last-minute changes and overlooked details, too often it takes a life of its own. And before you know it, you are designing in a chaotic environment, full of refinements, final-final-deliverables and missed deadlines.

What’s The “Right” Design Process? #

Of course there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Personally, I tend to rely on 4 design models that seem to fit well with my design work:

• Double Diamond Process for its comprehensive and reliable methodology for solving problems. In this guide, Dan Nessler breaks down the entire Double-Diamond process into single parts, explaining how exactly it works, step-by-step, in all fine details.

• Triple Diamond Process for its more realistic approach to designer’s input across the product’s life cycle. That's a piece by Adam Gray on why bringing flexibility for the messy reality of the design process is critical to improve planning and involve design work as prototypes are being built.

• Enterprise Design Thinking Model by IBM for its focus on design maturity and scale, which really helps with large organizations. A useful model that helps argue for user research, user-centricity and rapid low-fidelity prototyping — and how to transfer ownership to design teams at scale.

• Hot Potato process, for its simplicity in bridging design and development across the entire product lifecycle. Designers and developers throw ideas and mock-ups and prototypes to each other permanently. Sometimes there are more involved design phases than dev phases, but there is no hand-off, and the entire process is driven by continuous collaboration.

These ways of thinking about design process translated into a process that works well for me, but has to be adjusted for every project that I'm working on. In a nutshell, here's how it would work.

A Process That Works For Me #

There is no such thing as enough user research. In every project, I start with involving users as early as possible. I explore all the data we have, interview customer support and service desk, check for technical debt and design issues, backlog items and dismissed ideas. I explore organizational chart to understand layers of management. I set the right expectations and seek allies.

From there, I would typically spend weeks or even months in diagrams and spreadsheets and endless docs before drawing a single pixel on the screen. I try to get developers on board, so they can start setting up the dev environment already.

I bring in stakeholders and people who have vested interest to contribute to the success of the project. Voices that need to be heard, but are often forgotten. I see my role as a person who needs to bridge the gap between business requirements and user needs through the lens of design.

Then I take a blank piece of paper and start sketching. I sketch ideas. I sketch customer journey maps. I sketch content boxes. I write down components that we will surely need in the product — the usual suspects. I set up a workshop with designers and developers to decide on names. Then developers can go ahead and prototype while designers focus on UI and interaction design.

To make sure I get both sides of the equation right, I draft customer journey maps, brainstorm ideas and prioritize them with the Kano model and Impact ÷ Effort matrix (with developers, PMs and stakeholders).

I don't want to waste time designing and building the wrong thing, so I establish design KPIs and connect them with business goals using KPI trees. I get a sign-off on those, and then interface design starts.

I develop hypotheses. Low-fidelity mock-ups. Speak to developers. Get their feedback. Refine. Throw the mock-ups to developers. Bring them into HTML and CSS. Test hypotheses in usability sessions until we get to 80% success rate for top tasks. Designers keep refining, developers keep building out.

Establish a process to continuously measure the quality of design. Track task completions rates. Track task completion times. Track error rates. Track error recovery rates. Track accessibility. Track sustainability. Track performance. In a B2B setting, we track the time customers need to complete their tasks, and try to minimize it.

Make them visible to the entire organization to show the value of design, and its impact on business KPIs. Explain that the process isn't based on hunches. It's an evidence-driven design.

Establish ownership and governance. Search team must be measured by the quality of search results for top 100 search queries over the last 2 months. People who publish content are owners of that content. It's their responsibility to keep it up-to-date, rewrite, archive or delete.

Refine, refine, refine. Keep throwing new components and user journeys to developers. Stop. Test with users to check how we are doing. Keep going and refine in the browser. Continuously and rigorously test. Launch and keep refining. Measure the KPIs and report into the next iteration of the design.

Admittedly, it is a bit messy. But it helps me stay on track when navigating a complex problem space in a way that delivers measurable results, removes bias and subjectivity from design decisions and helps deliver user-centric designs that also address business needs.

Wrapping Up #

Of course there is no “right-and-only” way to frame a design process. It’s defined by whatever works well for you and for your team. Explore options and keep them in mind when designing your design process. Whatever you choose, don’t follow it rigidly just for the sake of it, and combine bits from all models to make it right for you.

As long as it works well for you, it’s right. And that’s the only thing that matters.