Four Approaches to Share and Reflect on Our Work
“Emily is going to demo her design to the entire team next week.”
“Hey, Satish wants us to critique his latest design work.”
“We’ve scheduled a meeting to review Marsha’s design.”
“Dean’s doing a design walkthrough at 2.”
We throw around these phrases all the time. Do they mean the same thing? Or are there differences? Let’s explore and take them apart.
Terms for Us and Jargon for Them
Here are two conversations for us to compare:
“Hey, what happened?” “Oh, I broke my wrist.”
“Doctor, what’s today’s surgery?” “We need to pin up the left scaphoid.”
Both are talking about the same problem. The difference is the amount of jargon for precision.
If you tell your best friend that you broke your scaphoid bone, you’ll probably just receive a blank stare in return. Most people don’t know that’s one of the eight bones that compose each wrist.
But you’d want your surgical team to be quite aware that it’s the scaphoid and not the capitate or the trapezoid. These words are medical jargon, and they are there to be precise. That precision helps the surgical team get the outcome they desire.
Someone who doesn’t know much about design (also known as a layperson) doesn’t need to know there’s a difference between a review, a critique, a walkthrough, or a demo. They shouldn’t have to know.
Yet, these terms should mean different things to design professionals. When we’re trying to communicate how we share and reflect on our designs, there are different approaches to do it. Each approach produces different outcomes.
Four Approaches to Share and Reflect on Our Work
What could make each approach different? Each one could answer a different type of question:
Design Walkthrough—How does the design match up with the business problems we’re working to solve?
Design Review–Is this design ready for moving forward or are their still issues to resolve?
Design Demo–What is the user’s experience when using this design?
Design Critique–What can we learn from this design we’ve created?
Sure, as designers, we could use these terms interchangeably, but that doesn’t help us. Establishing a consistent usage helps us understand what we’re intending, just like the surgery team wants to know if they’re pinning up the lunate bone or a triquetrum bone. (Who knew wrists were so complicated?)
Matching Up Our Intent—The Design Walkthrough
Probably the most common way we see designers share their work is with a walkthrough. The walkthrough is a simple “here’s what I did and why I did it” discussion about the design.
Walkthroughs can have a wide variety of audience members. It could be other designers on the team, stakeholders, or even customers/end users. These folks want to see the approaches the designer took to solve the important problems.
The walkthrough structure is usually quite simple. The designer shows each design element, such as a screen or a page. They point out the interesting bits and explain the rationale behind their decisions.
Audience interaction is often limited to clarifying questions and pointing out potential issues, though we’ve all seen these devolve into attempts at design by committee. (It can take a strong facilitator to prevent this from happening.)
A good design addresses a specific set of problems. If a team describes and gets agreement on those problems before they do a walkthrough, the walkthrough session will be smoother. When you clearly identify the problems, you help the discussion stay focused on whether this design is providing effective solutions.
Moving Our Design Forward–The Design Review
There are various points in a design process where we have to say, “Yes, we’re ready to move forward.” That’s where a design review would come in.
What moving forward means will depend on the process. Maybe it’s reviewing a concept prototype to decide if it’s worth refining it further. Or maybe it’s reviewing the final layout to turn over to the developer, who will turn the design into production code. In almost any flavor of the process, there are checkpoints to ask if we’re ready to move on.
When the goal is to determine if our design is ready, then we conduct a review to go over each issue that could keep it from moving forward. Once every issue has been addressed (either fixed or pushed aside), then our design can proceed on its journey.
Our focus during the review is on the design’s issue list, not the design itself. To generate that list in advance, the team could do one or more design walkthroughs. Walkthroughs would give them a chance to prepare a response to each issue before the review starts, which will make the review session more efficient.
There you have it: use walkthroughs to generate the issue list and reviews to decide which ones still need resolutions. These are two ways to communicate a design, each with a different purpose, structure, and outcome.
Sharing the Experience–The Design Demonstration
Sometimes, it’s easier for someone to understand the design by seeing it from the perspective of using it. That’s when a demo becomes the right way to share how the design works.
What makes a demo different from a walkthrough is the noticeable absence of any discussion about the problems the design is trying to solve. In the demo, the demonstrator (who doesn’t have to be the designer), narrates their experience as they use the design.
Whereas a list of problems drives the walkthrough, a scenario drives a good demonstration. “Let’s say a patient, who is experiencing extreme wrist pain, walks into the Emergency Room’s triage station. We need to get them checked into the tracking system.” Now, the demonstrator proceeds to show what the triage nurse’s experience would be, one interaction at a time.
Demonstrations can be useful, like a walkthrough, for generating a list of issues for an upcoming review. However, it can be harder to do well. Demonstrations don’t lend themselves to interruptions because it breaks the “suspension of disbelief” that puts the audience member into the experience.
If the goal is to generate a list of issues, it might be good to put a demonstration back-to-back with a walkthrough. The demo can show the experience, then a subsequent walkthrough can deconstruct it, allowing for more along-the-way discussion.
Reflecting on the Design–The Design Critique
Every design is an opportunity for the designer to learn something. Maybe they learn about new techniques. Maybe they learn something about the users and their needs. Or maybe they learn how other parts of the design work.
The critique is a fantastic opportunity for the design team to turn inward and take apart a design, learning what makes it tick. Everyone in a well-run critique walks away with a new perspective on design and how to better meet users’ needs. It’s a great way for us to improve on our craft.
Unlike demos and walkthroughs, the intended audience is the design team. Others can join in (and the team should encourage this). But a critique wants to dive into the details of how the design came about, so it’ll get geeky. (They should be warned.) After all, if a developer or product manager is curious about how the design came together, getting an immersive education on the thinking behind it will give them better insight into the process, making it less mysterious.
Critiques are different from reviews because the team isn’t honing in on the issues. Whereas a review likely only focuses on things that need fixing, a great critique session might only focus on things that worked well. After all, how did the developer get it right? What was their thinking? What was their process? What would they do to make it even better?
Of the four techniques, critiques are the ones we do the least. Yet, they are probably the most valuable, as they not only help us understand how to make this design better, but all the designs that will come after.
Variations on a Theme
For each of the four techniques, variations can modify what they accomplish. For example, one team we recently worked with took a walkthrough and modified it to compare the user stories they’d created to the prototype they’d implemented.
As one designer walked through a piece of the prototype’s flow, another designer pasted screenshots on the wall. The business analysts who created the user stories pasted the relevant stories underneath each screenshot. Then, the team could clearly see which parts of the flows were missing comparable stories and if there were stories that didn’t deal with the prototype. It was the first time the two groups had a chance to ensure their work was synchronized.
There are many ways to do each of these techniques. It’s up to the team to pick the method and variation that best suits their needs at the moment.
The Attributes Behind the Techniques
If we look closely, we can see some patterns in these techniques. Reviews and critique are both about reflecting on the design, while walkthroughs and demos are for sharing the design with others. Reviews differ from critique because reviews focus on the future of the design. Critiques focus on how the design got to where it is today.
Similarly, walkthroughs focus on sharing why the designers chose a specific solution, while demos focus on sharing how the design feels to use. Both walkthroughs and demos are about bringing a shared understanding of the design to a larger audience than only the design team. Critiques and reviews are specifically for the design team, helping them get a deeper understanding.
A team can ask basic questions about what they need. Do they have a shared understanding with a larger audience? Do they need a deeper understanding amongst themselves? Answering these questions can help them pick the right technique to use at that moment.
To the layperson, the terms might not seem that different. But to the designer, they precisely describe a technique that will help move the project forward.
How to Win Stakeholders & Influence Decisions program
Gain the power skills you need to grow your influence on critical product decisions.
Get mentored and coached by Jared Spool in a 16-week program.
Learn more about our How to Win Stakeholders & Influence Decisions program today!