The Powerful Ritual of Daily Design Review

by Jared M. Spool

Even though I expected it, I was stunned when I turned the corner and saw it. Along one wall of the 20-foot-long corridor we’d just entered, there were rows and rows of crudely attached screenshots.

Each screenshot was a screen from the project’s large enterprise application. Each row was a sequence of screens the user would experience.

Screens were taped on top of other screens. Every time a screen was updated, the developer would tape it on top of the previous version. Some screens had been updated 10 or 20 times, and the paper stack fluttered as people walked by.

The corridor was visually stunning. It was a living description of what it was like to use the large, complex application.

The daily design review meeting.

The screenshot corridor was a by-product of a daily design review meeting. One-by-one, as the meeting convened, the project’s front-end developers would approach the wall. They’d scan it to find the pile of older versions of the screen they’d been working on.

Once they find it, they’d tape up today’s version right on top. Then they’d look around to review what the other front-end developers had just added to the wall.

There were a hundred developers on this project, spread across ten scrum teams. Six of those teams were working on user-facing code. It was the front-end developers from those teams that came to this voluntary meeting each day.

Running the meeting was the only designer assigned to the project. “Ok, who wants to start?” the designer said.

One of the developers said, “I’ll go,” and walked over to describe their screen. Taking turns, the developers would stand by their new screens, describing the work they’d done since the last meeting.

They’d describe the interactions they added, and how those served the user stories they’d been working on. They’d describe the challenges they’d encountered and would ask the assembled group for advice on particular questions that had come up.

The developers start learning design skills.

The ritual of this design review meeting repeated each day. The designer would round up the designers from their work pods and start the 20-30 minute review.

At first, it was clear these front-end developers lacked any practical design expertise. Their screens were chaotic and function-driven. They didn’t really think about their users.

“On those first screens, it looked like the developers had just barfed the database schema onto the screen,” the designer told me. Related fields weren’t grouped together. There was little sense of a grid or alignment. All the problems you’d expect to see from developers who were never trained in user interface design.

Each day, after a developer would present their latest iteration, the designer would run a small critique session. What was working well about the screen? How might they improve it?

This was why the developers came to the meeting. They were craving constructive feedback and they got it in spades. The developers said they learned as much by looking at their peer’s designs as they did collecting feedback from their own.

The discussion taught them vocabulary and principles of design. What happens if we put the “done” buttons in the same bottom-right corner on every screen? What if we always placed labels to the left of each field? What if data fields were grouped by their relationship, instead of presenting the order they were listed in the database schema?

Over time, each developer started improving. Their screens were demonstrating the basic principles of UI design. Their critiques became more nuanced. These developers were learning design skills.

The hallway became a project-wide resource.

The screenshot corridor was a busy thoroughfare. It connected the lobby with a popular meeting area.

Along with the 100 developers and 1 designer, the project had 12 technical leads, 10 business analysts, 6 product managers, and 2 product owners. These folks often transversed the corridor. They saw the updates every day.

It was quite common for other meetings to end up in the corridor, looking at the screens on the wall. They became a resource to answer questions or discuss issues. Having something to point at become important.

On the opposite wall, other important project information began appearing. The system’s architecture diagrams showed up first. Then several long user journey maps, showing the sequence of complex interactions. These became important reference tools for everyone.

The hallway wasn’t just a place people passed through to get to their meetings. It was a corridor of education. It was instrumental in delivering a great application.

The educational value of daily rituals.

It was amazing to see the power that a daily routine could have. A daily 20 to 30 minute voluntary meeting, held in a public hallway, was changing the quality of UI designs throughout the project.

Everyone could see the progress they were making. They could see how their own screens were improving. They could see the smart ideas their co-workers were coming up with.

Nobody asked for permission to do this. The team’s one designer just decided to make it happen. They put those first screens on the wall and the ritual began.

Often, this is how we see teams improve their design capability. They don’t do it through grand declarations of some new acronym-named design process. Teams improve their capability through small baby steps. Even if it is for only a few minutes, implementing small daily rituals that put design at the top of everyone’s agenda is a step in the right direction.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Published here on August 15, 2019.