InVision presents

Principles of Product Design


by Aarron Walter

Successful design-driven companies building the best products with the strongest design teams have practices in common. These extensively researched core best practices will help your team design better, faster, and more collaboratively. Combined with the power of design thinking, these product design principles will accelerate your team’s design practice.


Go to Chapter
Guess less
Stop wasting time

The software industry celebrates stories of lightning-strike success so much, you’d think hunches and risky bets could create unicorns. The best product design teams understand the reality—customer research forms the bedrock of successful products and companies.

Go to Chapter
Go to Chapter
Story first
Find your North Star

Humans have used stories to foster collective understanding since the beginning. The most powerful designs start with a story—the why—and where your designs fit into people’s lives. Using product stories, journey maps, storyboards, and user personas, teams can build empathy and understanding before designing.

Go to Chapter
Go to Chapter
Pencils before pixels
Think divergently

Every design begins somewhere, in imperfection. Sketching brings together designers and key stakeholders so they can collaboratively find the best solutions without getting lost in design details.

Go to Chapter
Go to Chapter
Show and tell
Create a culture of feedback

When it comes to feedback, there’s little room for polite reserve within a design team. Use design reviews, retrospectives, design standups, and careful space planning to facilitate a culture of feedback within your team—your designs and designers will benefit.

Go to Chapter
Go to Chapter
Fast feedback
Product prototyping—accelerated

Building great products requires an iterative process. The more your team tests their designs through prototyping, the faster you’ll discover needed course corrections or new possibilities. Through building blocks like pattern libraries and user feedback, teams can always design with fresh eyes.

Go to Chapter
Go to Chapter
Lateral design
We're better together

Your org chart can greatly influence the design process at your company. Bridge gaps between design, engineering, research, product, and others with cross-functional teams, sprints, working groups, and other structural changes that enable better lateral design.

Go to Chapter
Go to Chapter
Break the black box
Product design is people

As your company and design org mature and scale, it gets harder to maintain the visibility and transparency crucial for great product design. You’ll need to take on streamlining communication, surfacing design within the company, and more big-picture challenges beyond your desk.

Go to Chapter
02

Story first

Find your North Star

Listen to Chapter

Story is a profoundly important device to unite design teams around a shared product vision. This powerful communication tool helps us retain information and empathize with others. As companies scale and teams sprint through product iterations, it’s easy to lose sight of how your product should fit into the lives of your customers. The best way to keep everyone pointed in the right direction is with a clear, compelling story—a story that will unite and guide teams towards success.

Product roadmaps guide team milestones, but they only show us what to build and when. They don’t show us why we’re building a product. Stories, however, are great at explaining why.

In Start with Why, author Simon Sinek proclaims, “People don’t buy what you do; they buy why you do it. And what you do simply proves what you believe.” Similarly, the best product teams don’t merely follow a process; they march toward a shared destination—a vision of the future presented as a story that answers, “Why are we building this?”

We’ve been using stories to answer big questions for thousands of years. Long before humans could write, we used stories to share our most important messages. Through story, Aborigines passed down their origin through thousands of generations, and ancient cave painters depicted the movements of the constellations and the magic of the spirit world. Story is a tried-and-true methodology for collective understanding.

We’ve been encoding information in stories for so long, our minds have evolved into story super-processors, easily plucking out important messages for long-term recall and helping us empathize with others. Jennifer Aaker, Professor of Marketing at the Stanford Graduate School of Business, has found “people remember information when it’s weaved into narratives up to 22 times more than facts alone.” Findings from a study published in the journal Science suggest that literary fiction “uniquely engages the psychological processes needed to gain access to characters’ subjective experiences.” In other words, we can more keenly empathize with others when we learn about them through story.

Like thousands of stories told through the ages, product stories connect people and ideas. There are many ways to tell a product story, but they all start with a little planning.

Planning a product story

Product stories find their origins in research, not genius. Customer interviews will expose important moments of frustration, aspiration, and triumph—all of which are potential plot points in your story. Pixar uses a simple narrative structure to capture the essence of a story.

Pixar’s narrative shorthand makes it easy to flesh out a plot for a product story, and makes plain why your product is important to build. For example, let’s plug Airbnb’s product into this framework:

Once upon a time there was an artistic couple in Asheville, NC living in a charming home with a guest cottage out back. Every day they left each other and their lovely home to earn the money to help them pay their mortgage. One day they discovered a way to earn extra money by renting their guest cottage. Because of that, they were able to pay off their mortgage more quickly and save a bit extra for retirement. Because of that, they spent less time working and more time together. Until finally they were able to retire and live the life they’d dreamed of.

Unlike design comps and prototypes, product stories aren’t concerned with the UI of the product—just the people who will use it and in what context. A product story is very high level, answering a simple question: how will this product fit into the lives of others?

To answer this question, we can follow these principles

  • A good product story demonstrates how a cast of characters—your customers—behaves in specific settings.
  • An effective product story shows how your product creates value in your customers’ lives.
  • An achievable product story takes place in the near future—freeing your team from the technical constraints of today. Show people the future that can be created if everyone works together.
  • A product story is a visual explanation. It should be shared as a storyboard, a map, a comic, a series of illustrations, or a video.

Humans are visual thinkers. We often need to see something before we can comprehend it. Visuals will turn the abstract ideas of a product concept into a North Star that can guide teams to deliver on that vision.

One thing to keep in mind is that a product story shouldn’t be overly prescriptive about how to realize that future. Every team involved—designers, developers, marketers, ops—will have to use their own domain expertise and judgment to deliver on their end of the work. The product story should inspire and inform but never dictate.

Creating the product story

Product stories can take many forms: journey maps, storyboards, videos, even comics. Like any story, there’s an element of entertainment required to generate excitement among your teams and stakeholders.

Crafting user journey maps

In The User’s Journey, Donna Lichaw points out stories tend to follow a common structure. We’re introduced to the characters, their goals, and the setting for the story in the exposition. Conflict ensues, rising to a climactic event, then the characters find a resolution to their problems. Pixar’s narrative structure seen earlier follows a very similar story arc.

Following this story structure we can create a user journey map—an exploration of the myriad ways in which users interact with your product or service over time and across different channels.

A user journey map can be done in many ways, but simple sketches like those presented in The User’s Journey are particularly powerful as they’re fast and more fun than formal documents.

Quick tips to build your user journey map

  • Identify the main character’s goals and the problems they face.
  • Be specific where possible. Quotes from customers and specific findings from research will give your user journey map details that will bring it to life.
  • Point out the hurdles the user must overcome to get to the resolution they desire.
  • Include the devices and channels of communication involved in the user’s journey.
  • Speech bubbles let you expose the customer’s thoughts and words along the way.
  • Use a whiteboard or big paper on a wall to work as a team.
  • Your user journey map will reach more people if it’s informative and fun.

Storyboarding for product design

Storyboards—a collection of illustrated panels with short descriptions depicting key points in a story—are a tool often used by animation and film studios to work through narrative concepts. They were first developed at Walt Disney Studios during the production of Three Little Pigs in 1933.

However, storyboards have found their way into the product design process. According to Nate Blecharczyk, co-founder and CTO at Airbnb, the act of creating a storyboard was a “galvanizing event for the company.” Brian Chesky, CEO of Airbnb, was inspired by how Disney Studios made a huge leap from short animations to their first full-length film, Snow White and the Seven Dwarves, using storyboarding to shape the narrative.

Airbnb’s quick initial success portended a large opportunity for growth, but Chesky struggled to see where they might best invest the company’s resources. Taking a cue from Disney, he worked with the design team to produce a storyboard showing the story of their 2 types of customers: guests and a hosts.

As Brian Chesky explains, “When you have to storyboard something, the more realistic it is, the more decisions you have to make.” The act of drawing the frames of their storyboards forced the Airbnb team to consider the way their customers feel in each step of the process of renting or hosting.

Visualizing the experience puts you and your team there in the scene, building empathy with users as you strategize the design solutions. Airbnb’s storyboard helped everyone in their rapidly growing company rally around a common cause to design the products that will best serve their customers.

Though Airbnb’s storyboards are very high-fidelity, you don’t need to hire Pixar-quality illustrators to produce your company’s story.

Quick tips to build your product design storyboard

  • Post sticky notes in a grid on a conference room wall and sketch out each scene with Sharpies. Stick figures will suffice, but if you want to refine your drawing skills a bit check out See What I Mean, Kevin Cheng’s guide to drawing product stories. The act of thinking through the characters and the context of how your product will be used is the most important part of this process.
  • Create photo storyboards using your phone. Get a few people together to act out the product experience, and snap photos of each step. Having a cheap wireless printer on hand will make it easy to produce a high-fidelity storyboard in just a couple of hours. Drop your photos into Keynote or PowerPoint to create a quick presentation that can be shared in meetings or emails.
  • Online tools like Boards let you piece together a storyboard quickly and share with colleagues.

Video product stories

When the stakes are high and the timeline to completion is long, consider producing your product story as a video, which will help the people making a product connect with the customer experience.

Video transports us to new places and makes us feel like we’re part of the story. Video’s immersive qualities also make it good at forming long-term memories—yet another important advantage when mobilizing large teams toward a common cause.

Video is also easy to share. Once you upload your video to a service like Vimeo, your product vision will have a URL that can be dropped in an email or a Slack channel for all to view and reference.

One disadvantage to producing video product stories is the required time commitment: you’ll need to write a script, gather some people to serve as your actors, and maybe rent some basic video equipment.

While preparing for a major app redesign, the UX team I led at MailChimp produced a vision video to guide the company on what was to be a 4-month project. The research team noticed, after a number of customer visits, that people were doing work differently. Internet connections on phones and tablets let people work anywhere and all the time, ducking in and out of small tasks. This created a sense of found time quickly filled up with more to-dos. As people became overwhelmed with their work, they needed to hand things off to others. Seeing these behavioral patterns, we realized we needed to rethink how MailChimp handled collaboration across many devices.

The project required the collaboration of many teams. We wrote a short script and worked with our in-house videographer to produce a brief vision video in about 10 days.

Faced with a major redesign of their platform, MailChimp created this vision video to guide all teams.

The production was inexpensive and relatively fast, but the outcome was of high enough fidelity to guide designers, developers, marketers, and other stakeholders around the company as they worked to realize the vision set forth.

Quick tips to build your video

  • Determine if the scope of the project warrants a video. New products, long projects, and cross-channel experiences are well served by video product stories.
  • Plan ahead—video shoots can take a bit more time.
  • Avoid specifics like a detailed UI—focus on how the product needs to fit into the lives of your customers, not how the product looks.
  • Keep things simple. Enlist colleagues and friends to act out the parts. Use a DSLR camera to shoot and simple editing software like iMovie to produce your video.
  • Skip the dialogue to speed up video production. Use speech bubble overlays instead.

Product story offshoots

Stories are always better with well developed characters. User personas and job stories can help you transform findings about customers into clear portraits of the people you’re designing for and their behavioral motivations.

User personas

User Personas are archetypal representations of key customer segments. They give a name and a face to otherwise abstract customer data, inspiring empathy and informing design.

Personas can take many forms, from documents to posters, but they’re most effective when visible. The MailChimp UX team created a series of persona posters to guide their product. While pulling a shot from the espresso machine or lunching in the common space, the persona posters reminded everyone in the company of the people using their product.

Quick tips for creating user personas

  • Line up interviews with customers in each key segment.
  • Analyze the findings from your interviews to determine common traits and goals within each customer segment.
  • Create a profile representative of the largest common groupings.
  • Refresh often, as personas are merely a snapshot in time and not built to last.

Job stories

Job stories come from the Jobs to Be Done framework developed by Clay Christensen, Harvard Business School professor and author of the influential book The Innovator’s Dilemma. Core to Christensen’s Jobs to Be Done theory is that we don’t buy products, we hire them to do a job. By discerning the job a product is hired to do, we can better understand the motivations of customers.

Job stories are based on customer interviews that employ a very specific technique that takes the customer back to the moment of purchase to expose the situations and motivations that lead to their decision.

Job stories and user personas are very different. Personas represent specific segments of customers that have a shared set of characteristics, skills, and perspectives. Job stories are only concerned with a customer’s motivations within a specific context.

A job story follows a simple structure:

Breaking down the job story

Each section of the job story reveals a specific piece of information:

  • Situation: When ___________
  • Motivation: I want to ___________
  • Expected outcome: so I can ___________.

For instance:

When I commute to and from work for hours each day in my car I want to do something productive and stimulating so I can feel like I’m not wasting time and actually make my commute productive.

A job story like this provides rich insight into the problem to be solved: this commuting time is ripe for the right product or service to make wasted time instead feel like a newfound opportunity.

Quick tips to create your job story

  • Interview customers following the Jobs To Be Done interview process
  • Identify the situation, motivations, and  desired outcomes related to the customer’s purchase
  • Create a job story for each customer interview
  • Compare job stories for each interview to find patterns

Fitting into the lives of others

The storytelling mechanism you choose is less important than the story you tell. The act of creating a product story before you begin the design process not only helps you mobilize your teams, it also forces you to clarify your intentions for your product. You’ll step out of the maker’s mindset and consider how your product will fit into the lives of others.

Peering through the microscope at the details and execution of a project is important, but only after we’ve gotten the perspective from the Earth to our North Star, getting a glimpse at the future we can create. Story First is a simple principle to help you and your whole company work together on big ideas.

03

Pencils before pixels

Think divergently

Listen to Chapter

The work of the modern designer lives in the abstract world of the computer, where every move we make is precise and effortless. Precision has its place, but not in the early stages of the creative process, when our ideas are still nebulous. There’s danger when creative exploration starts with perfection.

Perfection can create the illusion of certainty, something architect Frank Gehry avoids as he begins a project. It’s discovery he craves. Craig Webb, Design Partner at Gehry Partners, has heard Gehry say many times, “If I knew where I was going, I wouldn’t go there.” To Gehry, peak creativity lies in the unknown.

His process begins with rough concepts. He and his team sketch, make models, then reflect. If the outcome isn’t right, they throw it out to begin again. Crude outputs early on make the work less precious and completely malleable.

The hundreds of models and sketches that cover the walls and surfaces of Frank Gehry’s studio are the artifacts of a creative process that starts wide, where there’s space for discovery of the best ideas before committing to a single direction.

Though Gehry’s work is unique, his process is not. Many creative thinkers start wide and narrow down. Unfortunately, many software design teams take a different approach—they start narrow and refine too soon.

Steve Jobs once famously likened the computer to a bicycle for the human mind. Computers help us make short work of complicated tasks and connect us to vast amounts of data—superpowers indeed, but when misapplied they can hinder the creative process.

Computers let us jump straight to pixels—a space of precision where everything aligns to a grid, vividly colored and fully formed. Precise outputs are precious and hard to abandon. This narrows creative exploration to just a few ideas well rendered.

To find the best design solutions, we should follow Frank Gehry’s lead: crudely render many ideas to find the solution worthy of a more precise investigation.

We can make more space in our creative process for critical thinking and better design by putting pencils before pixels.

The power of a pencil

The pencil is a humble tool that’s sparked millions of great ideas. It’s the inverse of a computer; it’s simple and limited in functionality, but its limitations make it effective.

Pencils are important to the creative process because:

  1. Pencils are inclusive. They’re not just for designers—anyone can use a pencil to express their ideas clearly. The pencil is the great equalizer.
  2. Pencils are low-fi. Quick sketches give no impression of a complete thought, signaling to all that it’s okay to offer feedback.
  3. Pencils aren’t fiddly. Instead of getting lost in software settings or style, you’ll focus on your ideas.
  4. Pencils are fast. You can explore vastly different solutions to the same problem in minutes, and you won’t feel bad throwing your sketches out because you invested so little time.

There’s a magic that happens when we put our ideas on paper. Dave Gray, Founder of XPLANE and co-author of Gamestorming, describes sketching as “a conversation with yourself.” Gabriela Goldschmidt, professor emeritus at Technion Israel Institute of Technology, made similar observations in a study of the sketching practices of architects published in the Creativity Research Journal. She discovered that although sketches start from ideas already within the mind, they can mutate into the unexpected—forming new ideas. Sketching is a thinking activity!

Many product designers already know this intuitively. Stanley Wood, Design Director at Spotify, told us, “Many of our designers sketch, but just so they can think through various ideas. Most of the time they don’t show them to anyone.”

And sketching, of course, is also a powerful communication device. The design team at Slack shares sketches with colleagues to invite conversation about concepts without getting distracted by style.

The MailChimp design team discovered that sketching is an important bridge to engineering colleagues. Todd Dominey, MailChimp’s Director of Design, noticed that “Pixels freak people out!” When engineers see a high fidelity design comp, they get the impression that the important decisions have been made without them, and now they’re expected to simply execute the design. But when a sketch is presented, it’s clear that the creative process is still wide open for their participation.

No art degree required

Depending on your background, the term “sketch” might conjure images of an artist in a Parisian cafe, leisurely capturing a scene with loose lines and precise shading. But you don’t need a beret or an art degree to sketch a quick UI or communicate an idea for a product (a cappuccino won’t hurt, though). If you can scribble some text and draw boxes, you’ve got all the skills you need to sketch.

Sketching is something anyone can do—it’s not the sacred territory of designers. Inviting others to participate in the design process will help you produce a more diverse set of design solutions. Engineers, product managers, executives, lawyers—anyone with a stake in your product—can help you turn abstract ideas into concrete solutions by sketching.

Sketching ideas together

A simple activity with tight constraints can be the catalyst you need to get your team comfortable. Todd Zaki Warfel, Senior Director of Design at Workday, created a team sketching activity called 6-8-5: you and your colleagues will generate 6 to 8 design solutions per person in just 5 minutes. No one will have enough time to get lost in fancy renderings, and that’s important. After all, the idea is to focus on ideas and ditch misgivings that “I can’t draw!” In this exercise, everyone’s sketches will be messy!

Here’s how it works

    1. Get your team together—designers, engineers, product managers, and experts with important domain knowledge. Limit the group to 8 or less to keep the discussion productive.
    2. Give each person a sheet of A5 or 8.5” x 11” paper. The paper will be folded 3 times to create 6 boxes (for 6 sketches). If you want to generate more ideas, fold the paper into quarters and give everyone 2 sheets.
  1. Frame the problem for everyone, and clearly state the desired outcomes of this project. “We want to help customers become active in this app more quickly. How might we achieve that?”
  2. Set a timer for 5 minutes, and instruct everyone to sketch solutions individually (and silently, to help everyone focus).
  3. When the timer goes off, it’s time for each team member to present his or her ideas. Conversation about each idea is important here. Critical feedback will help you see what ideas are best. Every team member should be given the opportunity to share sketches.

If time permits, you can do additional rounds to go deeper into each idea. Working together to solve problems gives everyone shared ownership in the product vision and generates great results because so many diverse perspectives are present.

You might be wondering why everyone’s sketching separately in this exercise instead of together on a whiteboard. According to repeated studies on group brainstorming work, we produce fewer ideas and of lesser quality when we work in groups. Keith Sawyer, a psychologist at Washington University, has summarized the science: “Decades of research have consistently shown that brainstorming groups think of far fewer ideas than the same number of people who work alone and later pool their ideas.”

Remember, early in the creative process we’re best served by covering as much territory as we can instead of going deep on 1 or 2 ideas.

The right tools at the right time

The tools you use to sketch can influence how fast and far your creative explorations proceed. With fine line pens and mechanical pencils, you’ll be prone to create detailed sketches, which are slower. To avoid slipping into detail early on, Jason Fried, co-founder of Basecamp, uses fat markers for sketching on large format graph paper. With fat markers, it’s pretty hard to draw a detailed UI. Instead, you have to focus on the workflow and how people will use your product.

Dave Gray, founder of XPLANE, speaks with Jason Fried of Basecamp about how he explores ideas through sketching.

As ideas are refined, a medium Sharpie or—my favorite—a Staedtler Triplus Fineliner can help you explore your ideas with more precision. Loose paper works best for sketches, as they can be shared, posted on the walls, or mercifully recycled rather than lingering for posterity in your sketchbook. Designers who sketch UI concepts in detail find Copic gray markers add depth and clarity to sketches.

Sketching with remote teams

Team sketching is an important part of the creative process at Lullabot, a creative agency that serves clients like SpaceX, The Grammys, GE, and Martha Stewart. Each new project they take on starts with a sketching session, but not of the sort described above—this design team is entirely remote.

Creative Director Jared Ponchot has devised a simple and inexpensive way to sketch as a team despite the distance that separates them. He bought each designer a simple USB document camera, the IPEVO. At just $60 each, Jared even buys the cameras for engineers, clients, and other key collaborators in the company so they can participate in early sketching sessions.

Like many remote teams, Lullabot runs their meetings via Google Hangouts. In their meetings, they share sketches by simply switching the camera source to the IPEVO. Each team member can walk others through their ideas, or sketch live to explain a new concept.

Ponchot’s solution is simple and effective. It keeps his team focused on a breadth of design solutions early in a project instead of jumping straight to pixels, where they would get lost in execution.

Related: Freehand–a fast, flexible new way to collaborate in real time

Ideas before execution

Sketching before we jump to the computer has many benefits, the greatest of which is that sketching keeps us laser-focused on ideas instead of the charms of design execution. Design is often described as the act of solving problems for others. We cannot live up to that mandate if polish eclipses exploration in our creative process.

Putting pencils before pixels can help you bring others into the design process and win you allies. Gaining the broad perspectives of your colleagues early on will also help your team produce better design solutions.

Here’s your to-do list to put pencils before pixels into practice

  • Generate dozens of ideas on paper before designing on the computer; sketching is a thought process that will help you discover the unexpected.
  • Get engineers, product managers, and other key stakeholders to sketch with your team in the early phases of a project. This will clarify the project for all, and create a sense of shared ownership.
  • If your team or clients are remote, use USB cams to share sketches and ideate as a team.
  • Constraints like fat markers or time limits on sketching can help you avoid getting lost in detail too soon.
04

Show and tell

Create a culture of feedback

Listen to Chapter

Feedback is the lifeblood of a healthy design team. It informs the design process, leads to better products, and helps designers grow. Despite its essential role in design, it’s too often absent in our work.

In most design programs, feedback is folded into virtually every aspect of learning. I was reminded of this fact a couple years ago when I was invited to the Stanford d.school to speak to Enrique Allen’s class about design. Before meeting with students, Enrique provided a quick tour, pointing out works in progress. His colleague Scott Doorley joined us to explain the thinking behind each workspace in the school.

In some ways the school was like many others I’d visited—the energy of overly caffeinated students laboring over projects was palpable. But there was something peculiar about it: every space was messy. Not unkempt, but messy with ideas in progress. There was a sense of urgency to the way work was posted on walls and scribbled upon. Work tables were strewn with exacto knives, rulers, tape and scraps of paper—instruments of creation. All the furniture—desks, couches, work tables, and whiteboards—was fitted with casters and either pushed into clusters for conversation or lined up against the walls to open up room to build. The space was very carefully designed to facilitate the chaos of creative thinking.

The energy was incredible, and I didn’t want to leave. It was an ecosystem of ideas, where projects sprouted and grew or died to make room for the next experiment.

The d.school’s design studio is so different from those in nearly every tech company, where the space is pristinely decorated and filled with desks for solitary work. The walls of most startups I’ve visited are reserved for clever posters or artsy murals, not the design concepts that will lead to the next product release. Those designs remain trapped in a legion of MacBooks, starved for critical discourse that could help them grow into something far greater.

Healthy feedback

Something’s lost when we transition into the professional design world. Work no longer happens out in the open. Creative chaos is traded in for tidy presentations of fully formed ideas. Things stop being messy.

The d.school’s messy studio is an indicator of a healthy feedback process. Students are making things, showing what they’ve made, and getting feedback that helps them see their work differently. Then the process repeats, often quickly.

Healthy design teams have feedback built into their processes, so ideas can evolve and designers can grow. Work is shared with colleagues consistently and intentionally in design reviews, daily standups, and casual conversations.

Building feedback into our design practice helps in so many ways:

  • It helps us avoid spending too much time on a design that may have significant flaws.
  • It gives us multiple perspectives on a single problem, helping the designer get closer to an effective solution faster.
  • Presenting work for feedback keeps the team synced on project progress, and holds everyone accountable to milestones and deadlines.
  • As designers get in the habit of presenting their work and giving feedback to others, they 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.

There are many ways to create a culture of feedback in your team, but be patient—change won’t happen overnight.

Related: E-course: Making a product designer

Creating a culture of feedback

Giving and receiving feedback is a skill that needs to be cultivated. Dropping a few design reviews on the team calendar creates the opportunity for your team to exchange feedback, but it doesn’t ensure that anyone will actually know how to participate.

It can be a little scary to give feedback—we don’t want to create conflict by coming across as negative. And receiving feedback is even more intimidating. No one wants their work to be criticized! With practice, your team will learn that these fears are misplaced. Design feedback, when properly delivered, is constructive, supportive, and helps designers grow.

As they talk about design, your team will develop the language they need to deliver constructive feedback, and their perspectives on the qualities of good design will mature. You’ll hear fewer vague observations and more constructive feedback that can improve the design. For instance, rather than hearing, “I like the type you’ve chosen,” you’ll begin to notice statements like, “The type selection feels trendy, which contradicts the project’s goal of inspiring trust in the content.” The former isn’t helpful, while the latter is instructive.

Tweaking the language used in critiques can help ensure designers don’t take criticism personally. Say “the design doesn’t meet the goals of the project,” not “you didn’t meet the goals of the project.” Always talk about the work, not the person who made it.

Good feedback develops with rapport. For that reason, you may want to temper overly critical feedback early on so people feel safe presenting their work. Designers need to hear where they’re headed in the wrong direction, but deliver the message with encouragement. Work your way into more direct criticism once rapport and trust are established.

Setting the stage

Feedback happens more naturally when you create the right environment. Does your design practice make affordances for creative chaos like the Stanford d.school does, or is it built for solitary work?

By simply changing your space, 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 feedback and post it.

The design team at Greater Good Studio has gone so far as to create project bays, a modular space to post work for critical discussion. Each new project they begin gets its own bay—a physical manifestation of their progress.

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 lower fidelity or with notes scribbled on it will make it clear to all that you’re still working through ideas.

Remote

Remotes teams can also set the stage for feedback using tools like Slack, Trello, Google Hangouts, and of course, InVision. The entire design team at InVision is distributed and uses their own product to conduct design reviews. LiveShare, a design collaboration feature in InVision, lets the team present and get real-time feedback. Early ideas are explored with Freehand and Boards, later becoming Prototypes that are again shared with the team for feedback.

With so many affordable tools at hand, remote teams can easily build feedback into their design process too.

Bringing everyone into the process

Once your space is set up and designs are being posted, pay attention to how people behave. In person, are more people stopping by, curious about your work? Are spontaneous conversations happening in front of design work? Do you see designers staring at the wall, head tilted, pondering what’s been posted? Online, are people commenting on work shared on Slack or InVision? Is your Trello board exploding with links to new ideas?

These are all positive signs that your culture is shifting for the better. You’re bringing everyone into the design process!

Formalizing 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. 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: Early, midway, and at the end of a project

Who should be there: The designer plus no more than 7 people

How it helps: Designers get the feedback they need to refine their work

Design reviews are critiques that let designers get detailed feedback that’s framed by the project goals. Design reviews can happen at a number of different points in a project. It’s often helpful to do it early on so the designer can get fresh perspectives before investing too much time in an idea that may be misguided. The midway point and towards the end of a project are also natural times to get additional input.

Never use a design review as a big reveal of project. If you wait until you have everything polished, you’ll be too invested to accept the feedback you’re given.

Design reviews are a great opportunity to bring in experts from other teams. Colleagues from customer support, engineering, QA, legal, marketing, or even an executive may have a new perspective to help you see the problem differently. But try not to overload the guest list in these reviews—too many people and you’ll have a hard time guiding the conversation.

Design reviews are not a free-for-all. They should be run with these rules in mind:

Use a facilitator

The designer is not the best person to facilitate a conversation about her work. She’ll have biases that could influence the feedback, and she needs to be free to listen to the conversation unencumbered. The facilitator will write down all of the feedback and share it with the design team after the review.

A facilitator will set the ground rules for the conversation:

  • State the time limit for the design review
  • Introduce the designer and remind everyone that feedback should not turn into committee design. “Susan is the designer of the work we’re reviewing today. We’ll be helping her get fresh perspectives on her work, but let’s offer feedback—not design suggestions. She will use our feedback to inform her decisions.”
  • Let people know how they should give feedback. “Feedback should be specific and candid. Let’s point out what’s working well and what needs refinement. Remember, we’re critiquing the work, not the designer.”

Don’t rush into the review. The facilitator should give everyone time to review the work and for their observations to take shape in silence before the conversation begins.

Frame the problem

The facilitator should give the designer an opportunity to frame the problem at the beginning of the review, including any user and business goals. For example, “Users want to save money more effectively, and we want to keep customers engaged by teaching them to manage their money better.”

Identify the constraints of the project: ”Due to legal constraints, we have to disclose this information before the user can enroll in this new program.” If reviewers aren’t aware of the constraints and goals of the project, their feedback is unlikely to be helpful.

Say what you need

The designer should state what she needs from the design review: ”I’m trying to determine if this photo upload workflow is intuitive.” This will help keep the feedback focused, and prevent the group from wandering into unproductive conversations.

Don’t pitch, just listen

The designer should not pitch her idea or over-explain her designs. If she does, she robs everyone of the fresh eyes they bring to the design review. Once the designer has framed the problem and stated her needs, she should simply listen to the feedback.

Design standups

When they should happen: Daily, if possible

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 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 in your way?

While most teams choose to conduct standups in the morning, you may want to consider doing them after lunch—the morning is when our minds are clearest and ready to focus on creative work.

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 by. When you’ve launched a project or completed a sprint, reflect on what went well, what was confusing, and what didn’t go so well.

Matth Spiel, 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.

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:

  • What worked well for us?
  • What didn’t work well for us?
  • 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 a typical postmortem is run:

  • 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. This person, who wasn’t on the project and can be impartial, 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. It’s a conversation about the shortcomings of the team’s process, not the people involved. It’s an opportunity to learn!
  • 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.

Putting show and tell into practice

I’ve mentored a number of talented designers seeking guidance on their career path. All tell me the same thing: “I just want to work somewhere where I can grow and learn.” As they visit various companies, interviewing for their next design post, they can sense right away if the environment will give them the growth opportunity they crave. How? They recognize the signs of a company with a culture of feedback.

They see work on the walls. They see the messy signs of creative progress. Design critique is fluid and not limited to formal meetings. These are the signs of a healthy design team, fueled by feedback and always improving.

Building a culture of feedback takes time, but these simple steps will help you enact change:

  • Rethink your design studio: Create areas for work to be posted to foster spontaneous design discussion. It’s okay to be messy. Scribble on comps, add notes, post different versions of the same concept.
  • Stay in sync: Schedule short, daily standup meetings for your team to sync up on projects. It may be best to schedule them at the end of the day, so you don’t block the mornings when minds are most creative and ready to design.
  • Make time for feedback: Schedule design reviews for every project. They should be frequent enough for designers to get the feedback they need to avoid going too far down the wrong path.
  • Learn and grow: Schedule retrospectives after every project to capture lessons learned. When things go wrong, a postmortem meeting will help you learn from your mistakes without pointing fingers.

Hiring, coaching, and retaining great designers is made much easier when design and feedback are out in the open. Help your team show their work and tell you all about it.

05

Fast feedback

Product prototyping—accelerated

Listen to Chapter

Have you ever watched a great chef at work—the kind of chef worthy of a coveted Michelin Star? Whether she’s in the kitchen, the field, or at the market, she’s always tasting the food. Her palette guides her to the right flavors, aromas, and textures that combine to create an unforgettable meal. The alchemy of great cooking can only happen when the chef gets feedback at each step of her process.

Similarly, design teams that produce great products have something in common—they habitually test their designs. Before a single line of code is written, they build high-fidelity prototypes and put them in the hands of colleagues and customers, collecting fast feedback and correcting course before development.

These product design teams have a huge competitive advantage over those that get feedback only after their product ships: they learn faster. They spot problems quickly and fix them. They talk to customers early and align the product to their needs.

The software industry isn’t the first to grasp this principle. The animation industry was transformed by an underdog studio in Los Angeles that found a way to learn faster than the big New York studios by getting fast feedback.

Learn fast, leap forward

In the early 20th century, the boundaries of animation had been drawn and the industry was happily operating within them. The medium was crude—settings were flat, characters lacked personality, and the content was often limited to slapstick gags.

Then Walt Disney Studios changed everything.

Disney’s faith in the medium as an artform pushed the studio to experiment with new ideas that lead to astounding technical achievements. In 1928, they introduced sound with the release of Steamboat Willie, and in 1932 they introduced full color with Flowers and Trees. Each is an impressive achievement, but it was the studio’s contributions to process that enabled animation to evolve into the rich medium we know today.

In 1931, seeking faster feedback on their drawings, Disney animators began making what they called “pencil tests:” rough drawings on inexpensive negative film that they fed into the Moviola, a device with a small screen for viewing footage.

This process let Disney animators meticulously refine their drawings immediately, not weeks or months later, and enabled them to learn the art of the medium faster than any other studio. Soon the animators began stringing together pencil tests to review entire scenes, the interaction of characters, and the delivery of the story.

Walt Disney Studios’ prototyping method pushed the medium into new territory. While other studios produced silly gag films to make people laugh, Disney created art with emotionally complex characters that made audiences cry.

By building fast feedback into their creative process, Walt Disney Studios was able to make a huge leap. What worked for Disney can work for your design team too. Don’t worry, you won’t need to track down a Moviola on eBay. All you need is a high-fidelity prototype.

A pencil test from the production of Disney's Snow White

Prototyping and tools

Prototypes let us present product concepts to colleagues and customers without diving into the production process. A good prototype is a balancing act—it feels like a real product, but doesn’t require a lot of time to build.

I used to create prototypes using HTML, CSS, and JavaScript. It was a painful, time-consuming process that affected my judgement when testing. I’d spend a week or more producing a prototype that was vaguely realistic enough to show customers. When feedback called for big changes, I found myself reluctant to act, as the work seemed daunting.

That process seems ridiculous today, as we’re in a golden age of product design tools. We can now create prototypes that are much higher fidelity in less time without writing a single line of code. With less time invested, tweaks to a prototype come easy.

There are a number of prototyping tools on the market—more than we can cover here. Do some research to find the right fit for your needs. As you consider various prototyping tools, ask yourself these questions:

  • Is it easy to focus on product design problems, or will I be fiddling with the tool or code?
  • Can I deploy my prototype to various devices to create a realistic testing experience?
  • If you’re working remotely, is it easy to share the prototype and conduct remote testing?

InVision and Sketch

As you might’ve guessed, we’re partial to prototyping with InVision. Before joining InVision, my product design team at MailChimp used InVision to prototype new apps and explore feature concepts. It helped us move fast and get the feedback we needed. We shared InVision prototypes with the engineering team early to get feedback and keep everyone in sync.

Many product designers have transitioned from Photoshop to Sketch, which lets you work on multiple screens in a single file. You can save common UI elements like buttons and forms as shared symbols to build a screen quickly. There are a number of great learning resources to guide you if you’ve yet to make the leap to Sketch.

Craft by InVision, a suite of free plugins for Sketch and Photoshop, creates a tight integration between Sketch and InVision, shortening the prototype design process. It lets you pull real data from an API, fetch content from a site, or grab elegant photos and drop them into your design file to make your UI more realistic. Craft even lets you build a prototype directly in Sketch.

Design tools today are doing for product design what Disney’s pencil tests and the Moviola did for animation—they’re shortening the learning process so the craft can evolve faster.

Keynote

Keynote, Apple’s popular presentation software, has become a go-to prototyping tool for many designers. It’s simple enough that almost anyone can prototype with it, and sophisticated enough to do elegant animations that make a series of images feel like a real app.

Install Keynote on your iPhone or iPad to run prototypes on the target device, making the testing experience more realistic. Design prototypes in Keynote faster with Keynotopia’s UI templates for both iOS and Android. If you end up doing a lot of prototyping, you’ll probably want to take some time to create your own UI template library so you don’t have to continuously apply your brand’s colors and style to stock elements.

Faster prototyping with a pattern library

Your product prototyping process can be accelerated exponentially when you work with a pattern library—a collection of standard elements that can be combined like LEGO blocks to create a new UI. Creating a pattern library is time consuming work, but it pays off with the design of each new product or feature.

Facing UI fragmentation across many products and platforms, the design team at NASDAQ revised their schedule to spend time creating a pattern library. The process was intense, but helped them unify the user experience across all of their products. There was an additional benefit they hadn’t initially anticipated—prototyping with a pattern library helped them move very quickly.

Spending less time noodling on UI treatments means designers can focus more on aligning the product to customers’ needs. Companies like Salesforce, IBM, Atlassian, MailChimp, Spotify, and Westpac have all developed detailed design systems that help them design new products quickly.

Getting feedback on your prototype

Testing internally

With your prototype built, you can start collecting feedback. Before you put your prototype in front of customers, spend time talking with your design and engineering colleagues. They’ll help you look at the UI with fresh eyes, and reconnect with the key objectives of the project. Now’s a great time to conduct a design review.

Deploy your prototype to the devices you’ll be targeting so everyone can get a feel for the real experience. It’s not uncommon for designers to walk around the building to grab a few colleagues for an impromptu test of a prototype. Great feedback can come from unexpected places, so look beyond the design and engineering teams.

With feedback in hand, revise your prototype accordingly and get ready to test with real customers.

Testing with customers

You’re going to learn a lot as you show your product prototype to your customers. Your ideas and assumptions will be put to the test, which may at times make you uncomfortable. It can be frustrating to watch users struggle with your design.

Your instincts might lead you to help customers figure out how to use your app, but you’ll taint the feedback if you do. Instead, stick to your testing script or work with a moderator who can conduct the tests impartially.

Michael Margolis, UX Research Partner at GV, follows a very simple process as he conducts tests with customers: a welcome, an ice breaking period, the introduction of the prototype, the test, and a debrief. Michael’s script is wonderfully simple and easy to remember. Dive into his process in more detail in the book Sprint from GV.

According to research conducted by the Nielsen Norman Group, the majority of problems with your prototype will be identified after testing with just 5 customers. Instead of testing more customers, Jakob Nielsen recommends another small batch of tests after refinements have been made.

Recruiting customers

Running the test is actually the easy part of the feedback process. Finding test subjects is the hard part. If you have an existing customer base, query your database to find power users. Devout customers are often excited to see new design concepts, and will likely give more informed feedback. This is their chance to influence the design process!

If you’re testing a prototype for a brand new product, you’ll need to be more creative in how you recruit. Once again, the GV team has a clever solution. They create a form to screen customers that asks a few carefully considered questions. A worksheet guides them to create a screener that will target the right kinds of people. They post a link to their screener form on Craigslist, Twitter, Facebook, and send to an existing mailing list if available. Since you’ll only need about 5 test subjects, you don’t need a high response rate to the screener.

Be prepared to compensate your customers for their time—remember, they’re doing you a big favor by testing your prototype.

Alternatively, you could hire a professional recruiter to find customers for you. The downside is it can be very expensive, and it won’t be a hands-off process. You’ll still need to give them enough information to target the right customers.

Testing remotely

Not all the customers you recruit will live nearby. You’ll need to make plans to conduct tests remotely too. Gregg Bernstein, Senior User Researcher for Vox Media, has developed an elegant system to conduct tests with users remotely using inexpensive, freely available software—a rig that runs just $99, a small price to pay for fast feedback!

Here’s how he does it:

  • Gregg shares a Calendly link with a potential test participant, letting her select a convenient test time. Calendly also lets Gregg ask for permission to record the session, and lets him send details on what the test participant can expect.
  • The Vox design team posts a prototype to InVision.
  • Gregg invites the participant to an InVision LiveShare—a shared screen with voice chat where the customer can use the prototype while Gregg asks questions, observes, and takes notes.
  • The session is recorded using ScreenFlow.
  • After the test session is complete, Gregg re-watches the video to fill in gaps in his notes. He then shares those notes and his insights with his Product team via Slack.

This process is simple and fast, yet effective. It lets Vox’s remote product team get feedback from users anywhere without hopping on a plane.

A service like Lookback.io can also help you get fast feedback from both colleagues and customers remotely. InVision and Lookback integrate to let you test a mobile app prototype with customers. It records the customer’s screen, their interactions with your prototype, and even overlays a video of their face as they use your app, helping you read their emotional state.

When your app is built, your developers can integrate Lookback into your app so test sessions can be triggered any time. Users can shake their phone to reveal a secret button that triggers Lookback’s recording feature. All sessions are stored in a central dashboard for designers and developers to review and make revisions.

Lindsey Campbell, UX researcher at InVision, has a unique approach to getting customer feedback remotely. She’s set up a Slack channel to share prototypes with devout customers to get early feedback and bring customers into the design process. The design team monitors the feedback and tweaks the product as needed.

Related: Get stakeholder approval 46% faster

Better, faster product prototyping and testing

Like a chef sampling her ingredients, designers need to get a taste of the user’s experience while designing, not just after the product ships. When you shorten the feedback loop, you can learn faster how to make a product that will appeal to your audience. Here’s some guidance to get you started.

  • When should I build a prototype? After you’ve done initial research and worked through many ideas on paper.
  • How much of the app should I build in my prototype? Don’t waste time prototyping the entire app. Focus instead on the parts about which you have the most questions.
  • How real should my prototype be? It should be real enough that customers won’t realize it’s just a prototype.
  • When should I show others my prototype? Early and often. Don’t let yourself get too far down a single path before you start getting feedback from colleagues. Show your prototype to customers after you and your colleagues have ironed out the kinks.
  • Who should I show it to? Start with the people in your design or product team. Be sure to get an engineer’s perspective to ensure the design you’re proposing is technically feasible.
  • How should I present my prototype? It’s always best to show the prototype on the target device if possible. Frame the problem you’re trying to solve before you ask for feedback from others.

We’re fortunate to know the importance of testing, and to have access to tools that make capturing feedback cheap and easy. Whether remote or in person, your team can build fast feedback into your process so you can build better products faster.

About the Authors

Aarron Walter
VP of Design Education

As the VP of Design Education at InVision, Aarron Walter draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices. Aarron founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million.

He is the author of the best selling book Designing for Emotion from A Book Apart. You’ll find Aarron on Twitter and Medium sharing thoughts on design. Learn more at http://aarronwalter.com.

Eli Woolery
Director of Design Education

Eli is the Director of Design Education at InVision. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.

In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.

Principles of Product Design
Principles of Product Design

Design better. Faster. Together.

Transform your products with the world's leading digital product design platform

GET STARTED NOW