I believe in work rituals. They create a sense of normalcy in the messy work of creating a product. One of the reasons I like Scrum is that it has lots of good rituals like Sprint meetings, the planning game, and retrospectives. One thing I do not like about Scrum is that most of the literature about it ignores or misunderstands the design process.

Over the years, I have developed my own flow which I call the Design Acceptance Process. There were several problems I wanted to solve for. I’ll try and explain them in brief.

Problem #1: No Reference Design

When an engineer has no reference design to work from they will often make up his own UI and approach. Unfortunately, engineers are usually not so good at this. Additionally, when they don’t have reference designs, they don’t have trust that the design team is part of the team/solution. To me, this is mission critical. We must provide designs before they start programming.

Problem #2: No alignment

It is pure chaos when an engineering team starts to build a product and there is disagreement around how exactly it is supposed to work. Getting alignment in the beginning is crucial to having a positive outcome. Great products are 1% vision and 99% alignment.

Problem #3: No Change Management

In every product development lifecycle, you will have new information come to light during the course of development. Decisions will need to be made. The problem is that not everyone is in the meetings where this happens. It creates new alignment problems between the people with new and old information.

Problem #4: No Design Authority

Designers are often dominated by the more “type-a” personalities, usually people in product management. I have seen product managers tell designers exactly what to design. Design departments need to OWN something. I believe it is the “build specification document”. Without something to be responsible for, the design team will always be reactive and never innovate.

Design Acceptance Process

To solve these problems, I have developed the following ingredients and rituals.

Design Specification Document

Usually, this is in the form of a Figma prototype. We detail out everything from happy path to error cases to different milestones and everything in between. We make it bullet-proof with every detail we can think of.

This document is iterative during the design phase. We rely on product managers, QA, and engineers all to help us refine the design. We are completely responsible for producing all of the details, but we collaborate with all of our business partners.

Pre-Acceptance Meetings

Once we have a design that we (in the design team) are happy with, we can begin the next step which we call Pre-Acceptance. The product manager makes a list of all of the people who will be working on the feature or project. The designer meets with each person INDIVIDUALLY and reviews the entire design spec. We ask the key questions:

1. What is missing?
2. What is wrong?
3. What is unclear?
4. What would stop you from accepting this design?

With each interview, we refine the designs even more. We add more edge cases and clarify any ambiguities.

After a full round of these meetings, we usually get to the point where we feel like everyone is ready to accept.

Acceptance Meeting

At this point, we have a group meeting with all of the participants of the project and review the designs together. We ask the final question:

Do you take this design to be to have and to hold, from this day forward, for better, for worse, for richer, for poorer, in sickness and in health, until death do us part?

Design Acceptance Question

You might think that, after all the individual meetings, the answer would be a uniform yes. Unfortunately, it never is. On average it takes THREE acceptance meetings to get finality. The first one there are usually a bunch of problems (3-5). The second meeting there is usually one last problem. And the final meeting, voila!

It feels good when each person says “I accept”. The ritual reinforces the following feelings:

• We are aligned
• We are making progress
• We feel good about the plan

I love the third acceptance meeting. It makes all the hard work leading up to it worth while. You might be wondering how we can do all of those meetings and present the same thing over and over again. My answer is that when you have responsibly for something and you take pride in your work, these details don’t feel like a chore. It feels like there is meaning in your work and you are a valuable member of the team.

Change Log

After acceptance, the engineering begins. At this point, you might think that every detail has been worked out and nothing will change. Unfortunately, life is messy and so is product development. Things change.

Without any intervention, a decision will be made in a room with a limited set of people. Unfortunately, that decision will not be propagated throughout the organization efficiently. There will always be people who say, “I didn’t approve that. I didn’t know about that. I didn’t build that way. I was blind-sided”.

This can completely derail a project.

So we invented a quick way to stay on the same page. We made a spreadsheet of all the people on a project and what changes have been made. See image below.

Every time a change is added, each person must put in the date that they re-accept the design with that change. To remind people, we have a slack integration where it @mentions them when a change occurs. Additionally, the PM and the Designer will poke anyone who falls behind. It becomes a crystal clear indication of who is aligned and who isn’t.

This one spreadsheet template has saved me thousands of hours of alignment meetings.

Summary

It’s not terribly complicated, but there is alot of hard work that goes into it. The end result is a reliable, trusted, functional design team that has meaning in their work. It also maintains trust between engineers, product managers, QA, and designers.

I wish that teams would provide the same rituals, especially for product documents like MRDs and PRDs.