How to Operationalize Design

From the many successful UX teams we’ve studied, it’s clear that to do their best work and hit deadlines, teams need structure. They need clarity on the work happening within the team, and regular feedback at each step of a project. By formalizing the feedback process, you’ll help your team operationalize their work without compromising on quality.

Giving and receiving feedback are key components of a healthy design culture, which will improve your design practice in so many ways: 

• You’ll avoid spending too much time on a design that may have significant flaws
• You’ll gain multiple perspectives on a single problem, helping the designer get closer to an effective solution faster
• Presenting work for feedback will keep your team synced on project progress, and hold everyone accountable to milestones and deadlines
• As designers get in the habit of presenting their work and giving feedback to others, they’ll learn to think more clearly about their design decisions, and become comfortable articulating their ideas
• Regular feedback processes will give junior designers the opportunity to learn from senior designers, helping your entire team level up

The first step to operationalizing feedback in your team is thinking carefully about how design is shared.

Setting the stage for feedback

By changing your space to create the right environment, you can set the stage for feedback and collaboration in your team. For distributed and remote teams, this is doubly important—establishing dedicated times and places for sharing works in progress keeps everyone connected.

In person

The walls of your design studio are a sacred space. This is where your team’s ideas can be shared, debated, retooled, and celebrated. Make it clear to your team that the studio walls are not a gallery—this is work space!

If you don’t already have one, invest in a large format printer and get the whole team connected. Print design work daily and post to your studio walls for scheduled design reviews and casual conversations.

If your walls aren’t ideal for posting work, you can buy 8-foot by 4-foot sheets of foam core and lean them against your walls. Get some nice Washi tape to post your designs in style (and easily peel off later). Leave markers and sticky notes nearby so your team and anyone in the company can easily jot down a bit of feedback and post it.

“The fidelity of the work you post can influence the feedback you get. Pixel-perfect comps may lead others to believe the work is finished, which will inhibit feedback. Work that’s a little lower fidelity or with notes scribbled on it will make it clear to all that you’re still working through ideas,” noted Richard Banfield, VP of Design Transformation at InVision and former CEO of international user experience consultancy, Fresh Tilled Soil. "Building a safe place for your team to be creative and do their best work might be the most useful thing a leader can do for culture in design focused organizations."

PRO TIP — Experience design in the right platform

Be sure to work through design ideas on the screen too. Interaction design, animation, and responsive design aren’t easily communicated on the printed page. Print brings more people into the conversation (which is important!), but ultimately you’ll need to solve for screen display.

Remote

Remote teams can also set the stage for feedback using tools like Slack, Trello, Zoom, and of course, InVision. The entire design team at InVision is distributed and uses their own product to conduct design reviews. Early ideas are explored with Freehands, later becoming Prototypes that are again shared with the team for feedback.

Freehands allow our team to map out the vision of entire user journeys and various permutations where we anticipate user friction. It’s become an essential step in helping our teams iterate and agree upon an experience. Prototypes allow us all to experience the high-fidelity version of what the journey actually feels like. Many stakeholders comment and provide input into the experience, enabling us to capture a wide diversity of opinions. 

PRO TIP - Understand the problem first 

Our product teams spend a considerable amount of time triangulating on problem discovery. In other words, we ask ourselves this multiple times: “What are the actual problems our customers are trying to solve?” A great user experience might not actually solve customer problems, so we are very focused on ensuring we have an accurate understanding of the problems before we start proposing solutions.

With so many affordable tools at hand, remote teams can easily build feedback into their design process too. After we’ve identified a few solutions, we rely on user research to validate assumptions and get qualitative feedback from customers about our approach. 

It’s important for us to find actionable insights, meaning we need to know what changes we should make to the design to improve it. Not just whether it was ‘good’ or ‘bad.’ Prototypes are the primary mechanism by which we do this. Without prototypes, we can’t validate with real customers whether their problems are actually getting solved.

With the stage set for feedback, you’re ready to establish the format for each type of feedback your team will need.

Operationalizing the feedback process

Designing out in the open is just the first step. Your team will also need to get feedback on their designs, sync with teammates to make sure progress is being made, and learn from mistakes so they can improve. This is a tall order, and calls for different types of feedback processes.

Let’s take a look at a few ways to get your team the right feedback at the right time.

Design reviews

When they should happen: When you have clarity on the work, but there’s still room for feedback to reframe your perspective 

Who should be there: No more than 7 people who include a facilitator, the designer, relevant domain experts (researchers, legal, marketing, support), key stakeholders or partners (engineering, product)

How it helps: Designers get the feedback they need to refine their work and ensure they’re properly aligned to customer and business goals

Design reviews are critiques that let designers get detailed feedback from the right people, so they can ensure they’re solving for the right problems. Conduct a design review early in the project when ideas are still rough, not only so the designer can get the inputs she needs, but also to bring your partners and stakeholders into the conversation to create shared understanding and ownership. 

Here’s how to run a great design review:

1.Invite the right people the right way

Your inclination may be to invite only designers to your design reviews, but you’re missing a big opportunity if you do. Designers will have conversations primarily about craft, but the designer working on the project needs more diverse inputs.

For instance, input on factors such as: Is the right language included? Have all legal requirements been addressed? Is what’s shown technically feasible? Is the design addressing common issues seen by support? To find answers to all of these questions and a myriad of others, you’ll need to invite people outside the design team.

Once you’ve defined who needs to be included in the review, send an email and set the stage. 

Here’s what you might include in your invitation:

• Give everyone the context they’ll need to come ready to give relevant feedback. For example: “We’re refining the onboarding flow for our new customers to help improve time to first use and reduce churn. We’re only working on the first part of our onboarding flow right now, and will be refining other parts later.”
• Tell people explicitly how to participate. Designers are comfortable offering feedback, but for some this might be their first design review.
• For example: “We hope to get your reactions to the new designs and how they can best help us achieve the goals of the project.”

2.Assign a facilitator

Have someone other than the designer facilitate the design review. Designers will be inclined to explain their work, and in doing so will rob everyone of their fresh eyes. A facilitator can act as an objective guide who keeps the conversation on track and lets everyone know the project goals, timeline, and constraints. She can set expectations on the fidelity of the work so everyone knows where you are in the process. She can also take notes during the conversation, so all of the feedback is captured for the designers’ reference later.

3.Give great feedback

To give good feedback, be sure to: 

• Affirm what’s working
• Identify problems as they relate to goals
• Once problems are identified, only then should you start to explore solutions together
• Avoid giving mandates, such as “You should …” and instead give suggestions, “It might be worth considering …”
• Be candid and constructive 

Never use a design review as a big reveal of a project. If you wait until you have everything polished, you’ll be too invested to accept the feedback you’re given. Going too long without a design review increases the risk you’re headed down the wrong path and potentially wasting time.

To further dial in your design review process, check out this great guide from the Google Ventures team. 

Design standups

When they should happen: Daily for large or distributed teams, less often for small teams

Who should be there: Everyone on the design team

How it helps: Your team gets the chance to sync up on projects

Design standups are short, daily check-ins that help your team stay abreast of the work that’s being done. As the name suggests, everyone remains standing in these meetings so no one can get comfortable enough to launch into a soliloquy.

In a standup, each team member answers 3 questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments, or blockers, in your way?

While most teams choose to conduct standups in the morning—when our minds are clearest and ready to focus on creative work—you may also want to consider doing them after lunch. For remote teams, pick a time that accommodates multiple time zones.

Don’t let standups turn into impromptu design critiques. If someone needs immediate design feedback, ask that they hold the request until after the meeting—a standup should be short and focused on project progress.

Retrospectives

When they should happen: After a project is launched or a sprint is completed

Who should be there: Everyone who worked on the project

How it helps: Your team will internalize lessons from each project

Every project is a learning opportunity, but if you don’t pause to take stock, valuable lessons will slip away. When you’ve launched a project or completed a sprint, it’s a great time to reflect on what went well, what was confusing, and what didn’t go so well.

Matt Spiel, former Director of Design at Treehouse, conducts retrospective meetings regularly. He sends a pre-retrospective survey to the team before the meeting to capture each person’s perspective individually. This helps to eliminate the bandwagon effect, which happens when the views of the group conform to those of a few vocal people.

“Retrospectives are a valuable tool to use because they help teams identify strengths and weaknesses,” Matt said. “They help provide the designers at Treehouse an opportunity to give feedback on our processes in order to grow and improve."

Matt asks his team to rate their performance both as a group and as individuals on a scale from 1 to 5, where 5 is the highest. Ratings tend to cluster in a similar spot, but occasionally there are outliers. Team members who’ve given starkly different ratings are asked to share their views in the meeting to promote transparency and honesty.

Discussion in Treehouse’s retrospective meetings is centered around 3 questions common to most Agile retrospectives:

1. What worked well for us?
2. What didn’t work well for us?
3. What can we do to improve our process?

These questions are sometimes referred to as Start, Stop, Keep—what should we start doing, stop doing, and keep doing?

Honest conversation about each of these questions becomes easier with the cultivation of trust and plenty of practice running retrospective meetings.

Postmortems

When they should happen: After a project has gone poorly

Who should be there: Everyone who worked on the project and an impartial facilitator

How it helps: Your team will learn from their mistakes and find a way forward

Not all projects go well. Some go horribly wrong, requiring all teams involved in the project to come together to consider and learn from the mistakes they made.

Though projects rarely go awry at Etsy, they’ve established a strong process to guide them through those that do. Their process follows many of the recommendations set forth in the Agile methodology.

Here’s how to run a postmortem:

Before the meeting: Send an email asking the team to identify key points in the project timeline. This will be used to construct a master timeline of events, which will be discussed in the meeting. By focusing on events, you’ll avoid negative finger pointing, which can derail the process.

Moderator: Choose a moderator who wasn’t on the project and can be impartial. This person should be guiding the conversation from the whiteboard, taking notes for all to see.

Ground rules: The moderator should first point out that this is not a blame session, but an opportunity to learn. It’s a conversation about the shortcomings of the team’s process, not the people involved.

Facts: People recall events differently. The moderator can help the team agree upon what actually happened so lessons can be extracted. Establishing a timeline of events can help pinpoint where things went wrong.

Lessons and actions: As key lessons are identified, they should be written on the whiteboard for all to see. The actions required to mitigate the problems stemming from the failed project also need to be identified, assigned an owner, and provided a clear deadline.

After the meeting: The lessons learned from the postmortem should be emailed to the entire team, along with the action items that are to be completed.

Postmortems can seem rough, but they’re far superior to repeating the same mistakes. They’re a powerful opportunity for your team to learn and improve your processes.

Once your team’s operations are sound, you need to start thinking beyond your borders. How will you interact with other teams in the company? This challenge is less about operations, and more about just getting to know people.

Key takeaways

• Build a culture of feedback to help your team grow
• Get your team in the habit of posting their work for all to see. Feedback comes more naturally when you create the right environment.
• If your team is remote, set the stage for feedback using tools like Slack, Trello, Zoom, and InVision
• Conduct regular design reviews to give designers detailed feedback framed by the project goals
• Conduct design standups regularly to help your team stay abreast of the work that’s being done
• At the end of each project, hold a retrospective meeting to collect the lessons learned and continuously improve your team processes
• When projects go poorly, run a postmortem meeting to learn from your mistakes without finger pointing

Finding this interesting? If so, check out InVision’s DesignOps Handbook, packed with insights on operationalizing across workflows, hiring, team alignment, and more.