Red Light, Yellow Light, Green Light: A Design Exercise for Getting Feedback From the Team

Illustration of stop light

A Designer at thoughtbot was telling me about an upcoming project that they were about to rotate onto. Their client is coming to us with an existing application and looking to improve what they already have in place. The Designer wasn’t sure what exercises to run with the kickoff since they felt that some of the standard design sprint exercises wouldn’t necessarily be helpful. Those design sprint exercises are great when looking to create and validate something new but can sometimes not be the best choice when iterating on something that already exists.

I suggested that they run through Red Light, Yellow Light, Green Light–a design exercise that I’ve done several times with people who are coming to us with existing mockups or applications. It’s a fun way for people who don’t know how to constructively critique an existing design without bashing the team that made it by involving everyone in a considerate critique process.

Instructions for Red Light, Yellow Light, Green Light

Situation

This exercise is best used when a team isn’t satisfied with their existing application design, mockups, or marketing design and believe that they can be improved upon. It should be conducted after gathering insights from usability testing or user research.

Exercise Setup

Grab a meeting room that has enough wall space to post the flow of the application that you’re looking to give feedback to, a table for everyone to have drawing space, and enough room to walk around.

Print screenshots of the entire flow that you’re looking to critique and hang them up spaced evenly across the wall. For better readability, I tend to print web applications on 11x17 paper; for mobile apps, standard US paper sizing is best.

Illustration of flow hung up

Gather enough sharpies, post-its and red, yellow, and green dot-vote stickers for the entire team. It’s always better to have too much than not enough.

Lastly, book two hours on the calendar that the whole team can attend.

Review Why

As a team writes down a problem statement, go over research that has been collected up to this point, explain the short-term goals of the exercise and long-term goals of the project. This step is easy to skip over: after all, everyone already agrees that the design needs improvements. It’s essential that the reasons you’re running through the exercise are explicit, and as a team, that you can point back to them. Framing this early also helps prioritize the work that will inevitably come out of the exercise.

I’ll also talk about things that aren’t on the table for a change. For example, API constraints that are out of our control.

Critique

Give each person a stack of yellow post-its and dot votes stickers.

Illustration of post-its

Each color dot vote has its own meaning:

  • Red: Something that should just be removed.
  • Yellow: Something that should change.
  • Green: Something that should be added.

On each post-it, participants will add the corresponding dot vote to the feedback that they have. They’ll write why their reasons for that action to happen below the dot vote. Make sure that the feedback relates back to the problem statement and outcomes that you’re looking to have for the work.

The whole group should start providing feedback at the same time, but spread out at different pages of the printed out screens. They’ll move through the flow and add their corresponding feedback for each part. This should be done silently so that people have their own time and space to think as if you were at an art gallery.

Illustration of feedback process

I’ve generally let this carry on for as long as it needs to, but for the most part, people are done within 30 minutes. I try to keep the idea generation as open as possible at the start and let people know that we’ll cut them down afterward.

Card Sort

Once everyone has had a chance to go up and add their feedback, I let them all take a break, and the facilitator and maybe another person start organizing the feedback into similar groupings. There is always a few pieces of feedback that have the same intention, and this helps us have a stronger conversation afterward.

In total, this should take about 10 minutes.

Dot Vote

I only feel the need to do this with larger groups where there is a range of potential next steps. With smaller groups, this step isn’t always necessary as there is already a consensus on a few solid directions and we can usually talk through the next steps.

Every person goes around to each of the directions and adds a vote if they agree that the action should be taken.

Keep this short – around 10 minutes – so that people are encouraged to do it quickly and go with their gut reactions.

Conversation & Wrap Up

Once the voting is complete, I’ll take a look at what some of the most popular pieces of feedback are and start to map that to the time that we have to do the work. We’ll start to prioritize the changes: which are most important to do right away, and which probably need some more thought and validation.

Based on those discussions, we’ll figure out what the next steps are as a team. Actionable items should get added to cards in Trello, or whatever flavor project management tool you have. The team can start working on those right away. For larger concepts, I might go into some of the ideation exercises that are found in the Design Sprint or as a team we might decide that they need their own design sprint.


If you use the instructions in this exercise with your team, I would love to hear about it! Did it work for you and your team? What did you learn from it? What would you change about it next time?

I couldn’t find the original creator of this exercise–if you are, or know of, the creator, please reach out for attribution!

Lastly, if you are excited about running exercises like this to help build the right features for fulfilling projects, we’re hiring Design Team Leads in our London and San Francisco studios.