There’s nothing quite like visiting a foreign city for the first time — especially with a great tour guide. That eye-opening, first-hand experience just doesn’t compare to reading a description or looking at photos a friend brought back from their trip. The same is true for UX research interviews. No second-hand research report or highlights video alone can deliver the same jolt of insight and impact as when the core team actively observes a full set of customer interviews. As a researcher, I try hard to help teams see and hear their customers (and the research process) themselves. I try to be startups’ UX tour guide instead of just their “report-er.”

This guide includes tips and the templates we’ve used to facilitate hundreds of successful UX watch parties with GV startups.

Top reasons your team should gather to watch UX research sessions live

Gets consensus faster on ideas based on their merits.

Research participants react to designs and concepts without knowing which came from your CEO or your intern. A stubborn Decider (usually the CEO or PM) might still override customers’ feedback on their pet idea, but it’s a lot less likely when the whole team watched it bomb in interview after interview. And an unpopular or unlikely idea can win a team’s support by performing well in research. Watching sessions together creates a shared understanding on a team, and makes it a lot harder for any individual to deny the results when a team has witnessed it together.

Accelerates understanding of users and motivates team.

More than most sales or customer support calls, good UX research interviews accelerate teams’ understanding and empathy for their customers’ goals, circumstances, and difficulties. Watching and listening to these sessions turns abstract “users” into real people with unique stories. And it consistently rallies GV startups’ teams to work even harder to improve their product or service for those customers.

Saves time and streamlines communication.

After a team has watched a day of research interviews, you don’t have to spend nearly as much time trying to document and communicate all the details and nuances from the study. It shortcuts a ton of the reporting and subsequent communication work you’d have to do otherwise. Observers are usually very eager to share the stories, findings, and next steps (as well as their excitement about UX research!) with the rest of the company.

Get your team to show up.

• Make sure you’re planning a study that’s directly aligned with the team’s and stakeholders’ top priorities. If they’re not interested in your research, you might be working on the wrong thing. (See Questions to ask before starting user research and Start at the end: How to do research that has real impact.)
• Get stakeholders’ input on your study goals, plan, interview guide, and recruiting criteria. Those are good chances to make sure they’re invested, and eliminates their excuses for dismissing results.
• Schedule interviews in a clump. Whenever possible, I schedule five one-hour interviews in one day. And we ask (require, really) teams to reserve the whole day and attend all sessions, preferably from the same room. Reserving a whole day allows them to focus on the study without getting distracted by other meetings and demands. Observing all five interviews in a day also makes it MUCH easier to spot the patterns, and to agree on key takeaways and next steps. When stakeholders or team members attend only one session, there’s always a chance that’s the session that goes sideways or is an outlier.
• Talk it up! Promote the study to your team. Remind them how it will help the project. Ask team leads to encourage others to attend. Add it to their calendars. Send reminders.
• Stoke FOMO. Ask an observer to send the team catchy updates during the interviews.

Make it easy for them to watch.

• Build a simple UX lab to make it easy to stream and record from almost anywhere.
• Reserve a good room for observing together. Lure people with lunch, popcorn, cookies, or whatever special goodies are popular in your company. Provide plenty of drinks and caffeine!
• Stock the observation room with supplies, like pens, paper, sticky notes, white board, extension cords and trash/recycle cans (snacking teams create a lot of detritus in a day. You might even want an air freshener!).

Coach your team to be good observers.

Unless your team are experienced interview-watchers, they’ll need explicit instructions about what to look for and how to listen. Remind observers of the study goals and big questions you’re trying to answer. (And write them in the first column of your Summary Sheet.) Provide a brief description of the participants, along with your recruiting criteria. Review the schedule and plan for the day. Then outline the “house rules” for the observation room:

• Try to see and understand the world through participants’ eyes.
• Focus on your observations. Don’t jump to conclusions. (And for Pete’s sake: Don’t make premature changes to the product or prototype during the sessions!)
• Be careful about taking participants’ comments too literally. Watch what they do vs. what they say.
• Don’t dismiss feedback from participants you disagree with, or who don’t match your assumptions or expectations.
• Respect participants’ privacy, and protect their PII. Don’t go digging into their accounts without their explicit permission.

As an example, here’s the Observer Instructions template we use for GV research studies. It includes links to templates for a Running Notes Doc, Summary Sheet, and Big Takeaways Form.

Give them jobs.

Assigning teammates specific jobs (and rotating roles throughout the day) keeps them engaged, and helps them resist the siren song of their Slack or email.

• Primary “Running Notes” Notetaker: Captures notes and quotes in your Running Notes Doc. (As the researcher, knowing others are taking detailed notes frees me to focus 100% on the participants.)
• Secondary “Running Notes” Notetaker: Adds accuracy and depth to notes. Highlight important observations, and capture noteworthy quotes and time stamps.
• Interview Technique Notetaker: Captures specific interview techniques the interviewer
  uses, so you can use them when you run our own interviews in your Running Notes Doc.
• Facilitator: If possible, it helps enormously to enlist a partner to facilitate the observers. While I conduct a day of interviews, one of my partners, Vanessa or Kate, joins the product team to keep them on task, highlight key observations, communicate with me, and manage debriefing between sessions. I like to check in with the observers after each session (especially the first ones) to get feedback and answer any questions about how I’m conducting the interviews.

Debrief together while it’s fresh.

After each interview, help the team fill out one column of your Summary Sheet. Discuss each of the key questions (the rows in the Sheet) while the Facilitator or researcher types the team’s answers.

After a full day of interviews — before your observers leave! — capture the team’s big takeaways. Review the Summary Sheet together to look for patterns and to counter recency effects. I like to ask, “What surprised you?” Ask each observer to complete a copy of this Big Takeaways Form. Before anyone leaves, ask the Decider to weigh in on next steps. In the coming days the team will have time to reflect and continue discussing what they saw and what to do next. But those initial, fresh reactions are a valuable snapshot that teams refer to again and again.

What if team members can’t attend in real time?

• Record audio and video of your interviews (with participants’ permission).
• Throw a viewing party. If team members can’t attend sessions live, schedule a viewing party to watch a recording of at least one session of your choice. Lure them with lunch, special treats, or highly coveted “I’m a customer champion” badges. While watching the session together, point out key moments, observations, and specific interviewing techniques you want them to notice. (“At this point, I was building rapport. They were nervous at first, but see how they relaxed as we chatted about their dogs.”) Reserve time at the end to discuss what everyone observed and what was interesting or surprising.

Some startups resist watching their own UX interviews. They say they’re too busy, and will just read the report later. Maybe they don’t like hearing frank feedback about their ideas or testing their assumptions. The best startups value these opportunities to learn about their customers, test new ideas, and accelerate their progress. As a great UX tour guide, you can give your team the memorable, first-hand exposure to their customers they need to build great products. After they experience it that first time, they’ll be hooked.

Thanks to Kristen Brillantes, Kate Aronowitz, Vanessa Cho, Anshu Agarwal.

UX Watch Parties was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to spot the 5 studies startups need most

After completing hundreds of research projects for startups across dozens of industries, I finally noticed something. Although each project seems unique on the surface, they actually match several patterns that emerge again and again. In my experience, startups look to UX research most often to achieve one of these five objectives:

1. Improve a Process or Workflow

2. Better Understand Customer Shopping Habits

3. Evaluate Concepts

4. Test Usability

5. Refine a Value Proposition

This practical field guide offers a way to quickly identify a startup’s objective, and what kind of research they actually need. It outlines how to conduct research that will deliver actionable results for each of these five common objectives. And most importantly, the “North Star Questions” will help you steer the project from start to successful finish. I’ve included a couple case studies to illustrate how they work.

Like any guide, you may have to reference this a few times until you get the hang of it, so don’t get discouraged if it feels like a lot of information right away. Whether you’re a founder, an engineer, a designer, or a seasoned research pro, I hope this guide will help you plan and use UX research more effectively.

Improve a Process or Workflow

When to use it

The company wants to streamline an existing process, or they want to create a new system or product that will save their customers (or themselves!) time, money, and mistakes. Use this to document the details of who does what when, highlighting problems and opportunities for improvement.

What to listen for

The client will say things like: “streamline,” “identify pain points,” “When is the best point to. . .?” “best practices for…,” “efficiency,” “process,” and “How do our customers currently. . . ?”

North Star Questions

This objective requires careful observation and a specific type of interview: we need to prompt customers to walk through a given process/workflow step-by-step so that we can study what happens. I flesh out a complete interview guide, but a few core questions serve as my North Star. I get pretty detailed with each step of their process, asking the participants, “What’s your goal right now? How does it start? Then what? And then what? Can you show me?”

During interviews, those North Star Questions help me focus on gathering the information I need most, and keep me from getting lost in the weeds, especially when talking to experts about an unfamiliar or fairly technical domain.

In addition, I will watch for and ask about:

• Pain points: What parts of the process are difficult, slow, unpleasant, costly, or error-prone?
• Variations: When have they deviated from the process they just described? How has this process changed over time?

Final deliverable

Our final step will be to put this information together in a way that makes sense to the client. In this case, I usually use a spreadsheet. Down the first column on the left, I label rows with the key details I want to capture for every step, such as: name of the step, who’s involved, their goals, what they do, questions they’re trying to answer, and pain points (or opportunities!). Then I fill out all of the fields for each step, fleshing out the columns from left to right.

Example

Let’s look at a real-life example so you can see how it works.

Flatiron Health’s mission is to learn from the experience of every cancer patient, and a top priority is improving clinical trials for potential new cancer treatments. A while ago, one of their product managers spoke to me about the difficulties of identifying and enrolling eligible patients into clinical trials, and he asked questions like:

• How can we help cancer centers enroll more eligible patients faster?
• How do practices find and enroll eligible patients?
• What are existing pain points in enrollment?
• When is the right time to alert physicians about eligible patients?

These questions may seem specific to Flatiron, but when I listened closer, I heard key words like “pain points” and “How do they. . . ?” and “How can we move faster?” I recognized he was really asking me, “How can we improve the existing process or workflow of enrolling new patients for clinical trials?” And to answer that question, I knew I’d need to interview clinical research teams about the nitty gritty details of each step of their workflow, then create a grid like the one I described above, highlighting specific points where Flatiron could help.

And that’s what we did. We visited five cancer centers in three states in four days, and interviewed 25 people. Every session followed a typical arc, starting with introductions, context questions about their roles and organizations, and conversation about their goals and metrics for success. But my North Star for the interviews (What’s your goal? How does it start? Then what? And then what? Can you show me?) helped me get what I needed most from my precious time with those clinical research teams.

We created giant posters of my summary grid to inform a design sprint we facilitated with the Flatiron team. After a lot more hard work by Flatiron, their OncoTrials product is now live in many oncology practices across the US.

Better Understand Shopping Habits

When to use it

A company wants to figure out how best to merchandise their product to increase online conversion. They need to know how customers judge and choose items in their category, and what content to present at each stage of the journey.

I’ve applied this method to improve online conversion for products as varied as coffee, APIs, furniture, vacation rentals, doctors, and databases.

What to listen for

Companies don’t usually frame their goals in terms of shopping or merchandising. They usually start by asking “How do we get more people to sign up/buy?” Listen for phrases like, “What do people want to know about our…?” and “What information or imagery is most important to explain or convince…?” “How do people want to sort or filter. . .?”

North Star Questions

When studying shopping habits, I build my interviews around a “shopalong,” shadowing target customers as they visit several sites or stores for an item. These shopping trips usually include a client’s homepage (or physical store) or prototypes, along with their competitors’. It’s easy for these sessions to stray if you’re not careful. In these interviews, I’m guided by my North Star Questions. Getting the answers to these is what makes each project a success. I ask each participant, “What questions are you trying to answer here? How? In what order?”

In addition, I will watch for and ask a few more things from the participant:

• Recent relevant experiences: Talk through both successful and unsuccessful shopping attempts.
• What content reassures you? What design elements convey (or detract from) trust and credibility?

Final deliverable

Describe their steps and the hierarchy of key criteria prospective customers use to narrow their options and validate their selections. In other words, answer the North Star questions: What questions are they trying to answer? How? In what order? You can read more about this in The Shopping Shortcut: How to Design for Your Customer’s Mindset.

Example

One Medical asked our team for help redesigning their homepage to increase member sign ups. They wanted to answer questions like:

• How do we get more members to sign up on our site?
• What information do they want to see?
• Where do they look for that information?
• How do they choose a primary care physicians? What criteria are relevant?

“Doctors” and “primary care physicians” seem pretty industry-specific, so it would be easy to assume this project would need a custom approach. But a second look at their questions reveals that what One Medical really wants to understand is how people shop for primary care physicians.

That objective told me what kind of interview to conduct. As usual, I planned the full arc of the interview — starting with introductions, learning a little about the participant and their past experiences, etc. But what really mattered was the shopalong and my North Star: What questions are they trying to answer? How? In what order?

And for One Medical, we learned that patients first look for doctors who are conveniently located, accepting new patients, and of the preferred gender. Once they have this, they narrow their list based on additional criteria like expertise, years of practice, education, hospital affiliations, and online presence. As a result, One Medical redesigned their landing pages to help prospective members find the details they care most about at each stage of their shopping process.

Evaluate Concepts

When to use it

A company needs to gauge interest and reactions to an idea or concept before they invest time and effort to build it. They have to determine which parts of a new concept appeal to their target customers and why. In this case we’re trying to understand customers’ perceptions of new features and ideas rather than testing usability.

I often plan this type of interview for the last day of design sprints to test the ideas we’ve prototyped.

What to listen for

Questions like, “Which way will people prefer to. . . ?” “Will people want to. . .?” “How will customers react to this?”

North Star Questions

With these interviews, I want participants to experience a few different prototypes or sites during our interview session. I also want to see what they think are the best (and worst) parts of each. My North Star questions are: How does this idea compare to the others? What are the pros and cons of each product (or prototype)?

In my interview, I’ll follow this basic arc:

• Discuss relevant habits, experiences and needs: For context and to help me interpret their feedback, I ask about any relevant past experience.
• Introduce prototypes and products: Next I’ll describe a scenario and invite participants to look at a mix of sites or prototypes with me. For example, “Imagine your boss asked you to review and evaluate these different services for use at work.” How do participants perceive what each site or prototype does or is offering? (You can even use competitors’ offerings as “free prototypes.”)
• Compare features & value prop: Prompt participants to contrast the products they’ve just tried. The goal is not to pick a single winner, but to tease out the best elements of each that we can combine into the next better prototype.

Final deliverable

After these sessions, briefly highlight what worked well about each concept, and what didn’t work well. (What are the pros and cons of each product (or prototype)?) Document which aspects of each prototype seemed most (and least) useful, valuable, and credible to the testers, along with any additional insights about customers’ needs and expectations.

Example

This short video demonstrates what this kind of interview actually looks like.

Test Usability

When to use it

These studies help teams see whether their users are able to complete certain tasks with a detailed design prototype, a launch candidate or a live product — and why! This is what people typically think of when they talk about “user research” or “user testing” or “usability testing.”

What to listen for

Questions like, “Will users be able to. . . ?” and “Are there any red flags in this design?” “Why are users getting stuck?” Will our customers understand how to. . . ?” “Is it intuitive?”

North Star Questions

In these sessions, we present testers simple goals and scenarios so we can observe them using the product or prototype to complete key tasks while they think aloud. For task-based usability sessions, my North Star is: Can users complete the task(s) with this design? Where do they get stuck or confused? Why?

I usually start these sessions with a brief conversation about their past experiences and existing habits that are relevant to whatever I’m testing with them. Every session helps the team learn a bit more about their customers.

Final deliverable

After several test sessions, a topline summary simply answers the North Star Questions: “Where did people get stuck or confused? Why?” Document patterns you observed about what did and didn’t work well about the design and instructional text. Also take note if most users failed to discover any important elements or features. Indicating the relative severity of the different problems helps teams prioritize their work.

For more details about conducting basic usability studies and interviews, see the PDFs and video from my User Research, Quick and Dirty workshop.

Refine a Value Proposition

When to use it

A company needs help communicating the key benefits of their existing service or platform in ways that resonate strongly with prospective customers. . . or they’re struggling to distinguish themselves from their competition. This type of study also often reveals weaknesses, along with where a company should invest in amplifying distinguishing features.

What to listen for

Questions like, “What is our value prop?” “What features distinguish us from competition?” “Why should customers choose us?”

North Star Questions

The goal of these interviews is to study your happiest, most successful customers (like Dan Heath’s “bright spots”) to find out why they chose your service from among other alternatives, and what they value about it. The answers may surprise you!

When trying to understand what appeals to happy, high LTV (lifetime value) customers, my North Star Questions are: Why do you use this service or platform? What are its strengths and weaknesses?

It’s also important to ask about:

• Background about their business or organization: Get some context about the work they do, and why they need this kind of service or platform. What are their goals and constraints?
• Previous experiences: What other solutions have they tried? What did they like and dislike about those? Why did they switch?
• Stories and examples: Ask customers to describe (in detail) recent examples of how and when they used your service or platform.

Final deliverable

Summarize key takeaways and patterns you heard from customers to answer the North Star questions: Why do high LTV customers use this service or platform? What are the strengths and weaknesses?

Conclusion

Phew! We made it. Hopefully you’re able to see that no matter how unique each project may seem on the surface, identifying the patterns provides a shortcut. Of course, these aren’t startups’ only UX research objectives, but in my experience they’re the most common by far.

For some additional material, I recommend checking out this article on a 4-day process for answering important startup questions that also offers some insight on recruiting the right participants for your projects.

Best of luck!

Field Guide to UX Research for Startups was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

Twenty years ago, when I started my design career, I made a lot of fake stuff. I can still clearly remember when I designed my own CD covers for albums by famous bands, created a fake e-commerce site with my friends, recreated famous logos in Corel Draw, redesigned a popular website just to see what I would do differently, and designed fake logos for fake products that didn’t exist yet. You might say, “What a waste of time on unpaid work!” You could say “Gosh, you didn’t understand the intricacies of designing for the real world!” But, all of this fake design work was critical to my career.

Fake design work let me get in thousands of reps. When I was about seventeen, I literally designed a hundred album covers in one year. I bought a stack of cheap jewel cases and repackaged my CD collection in my own designs. I didn’t make a penny, I didn’t get critique from anyone, but I sure as hell got a lot of practice digging into Photoshop 5, trying typography in ways I’d never done, using photography in ways I’d never considered, and trying to get decent results on a crappy color inkjet printer. The final ten album covers were leagues better than the first ten.

Fake design let me try work that I wasn’t qualified for. When my friends and I started a design agency in 1999, many of us were in our late teens and we had never built an e-commerce platform before — this was all scary brand new tech back then. Who was going to trust a bunch of kids to build a secure payments system? Heck, we didn’t know if we trusted ourselves to build one. So, we made a fake one called Coffee Cartel. We “sold” coffee mugs with funny slogans, beans, and coffee makers. It all worked, except we only processed credit cards for a penny and we didn’t actually make any products. We learned a ton about designing for e-commerce and also acquired technical prowess.

Fake design let me build a portfolio in a chicken-and-egg situation. That Coffee Cartel website was in our studio’s portfolio page for over a year. On the back of that work, we landed a real e-commerce client and built a sophisticated e-commerce system and inventory management system for a large Canadian retailer.

Fake design let me learn the intricacies of product design. Back in about 2003, I created a fake redesign of Verizon Wireless. I thought their website was crap and I was convinced I could bang out a big improvement in a day or two, just to prove to myself that I could. Turns out those big company suits were better at design than I thought. Creating a text input that suggested the user enter their full 10 digit phone number was surprisingly hard. I started to guess that the stupid 300x250 advertising banner jammed into the page was likely a release valve for internal marketing pressure. So, I embraced those constraints and ended up coming up with a design that seemed about 20% better, not the 200% better that I’d arrogantly predicted. That 20% improvement was totally based on my own judgement (no user studies, no quant, no qual) but it was an excellent learning experience.

If you’re thinking of doing fake design work, what should you watch out for?

• Don’t be a sucker and do unpaid work for other people — it’s called spec work, not fake work, and there are a lot of risks to doing work on spec. There a handful of exceptions to this rule (see below) but generally people who ask you to do spec work are assholes.
• Try not to gloss over complexity. Design work in the real world is pretty hard. If you design a fake graph, put in realistic data. If you fake redesign a site, like my Verizon Wireless redesign, don’t just magically remove an ad unit. If you create a sexy fake login screen, don’t forget to include a way to recover lost passwords or usernames.
• Write real copy. Lorem ipsum is for amateurs.
• The gold standard is to actually test your design work. Real designers often measure their work by putting it in front of real users. My Verizon project would have been way stronger if I had tested it with some potential customers in 1-on-1 user studies. This is how some great design schools like Tradecraft teach students to conduct unsolicited redesigns: design > test with customers > design again.
• Design to learn, not to get accolades. Other designers are rarely your real audience. It doesn’t matter if ten thousand designers applaud your work if your customers find your designs hard to use.

Go out there and fake it til you make it, my friends. Hell, I still fake it to learn new stuff and I’m not quitting anytime soon.

PS: You can also build your experience by doing “free” work. Not to be confused with spec work, some of us got a ton of experience by doing free work for groups we respected or as fun side projects.

For instance, way back in 2004, my friends and I volunteered to work with Mozilla on the branding of Phoenix as it was being renamed Firefox. Mozilla is an open-source project and we thought it would be cool to volunteer design work just like engineers were contributing code to the project. Note that Mozilla didn’t coerce us into doing it, we did it for the love of the project, and we consciously volunteered our time. We learned so much as a team and built confidence (and reputation) to do more work like it. And we had a lot of fun. Jon Hicks wrote a great article explaining the project and how we each contributed.

PPS: Thanks to Ariel Waldman, Dann Petty, Helen Tran, Kristy Tillman, Tim Van Damme, and many others for furthering the discussion on these issues.

Fake designs yield real results was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, Jared Spool caught my attention with an article about how Netflix’s performance engineers are actually designers. It’s a provocative idea, but it makes sense. His argument is that everyone in your organization (including performance engineers) designs the product, not just the people with “design” in their job titles.

From some of the reactions, you might think Jared had kidnapped a baby for ritual sacrifice. What exactly did Jared write?

The members of this team are performance engineers. They are architecting, engineering, and maintaining the performance of a very complex system. It occupies all their time and then some. In systems engineering, there are few jobs more technical than these.

And yet, at the very moment that a Netflix viewer’s video stream stops and that spinning animation appears, indicating the player is now awaiting more data, these engineers make a dramatic change. They become user experience designers.

I made that last sentence bold — because it’s really important. Some designers are uncomfortable with the idea that an engineer or a salesperson or a CFO could be a designer.

Whether you like it or not, whether you approve it or not, people outside of your design team are making significant design choices that affect your customers in important ways. They are designing your product. They are designers.

This shouldn’t be provocative — it’s just a statement of fact. I work with dozens of startups every year, and I see it happen at every one. A CFO makes a pricing decision and changes the product experience. An engineer makes a performance trade-off. A salesperson writes a script for talking to customers. In my view, people who fundamentally change the customer’s experience are designers.

If this is so self-evident, why do Jared and I press the point? I keep beating the drum because I want designers to change the way they think about their role and become better stewards of good design.

For a moment, consider how this shift in perspective could change the way you work.

Everyone needs a design mindset

When you accept the reality that design decisions are coming from outside your group, by people without “design” in their job titles, you approach your co-workers differently . Now they’re not just your co-workers — they’re your design team.

The companies that produce great design, such as Apple and Airbnb, have learned this. Alex Schleifer, VP of design at Airbnb, tells Wired how the company isn’t design-led:

The solution [at Airbnb] actually deemphasizes the designers. The point… isn’t to create a “design-led culture,” because that tends to tell anyone who isn’t a designer that their insights take a backseat. It puts the entire organization in the position of having to react to one privileged point of view. Instead, Schleifer wants more people to appreciate what typically lies only within the realm of designers — the user viewpoint.

Does everyone need all the skills of a designer? Of course not. But each person needs to be armed with the tools to understand how their decisions affect the customer experience.

When an engineer takes a shortcut and scrimps on performance, they need to understand how that damages the user experience. Likewise, when a designer pushes an engineer to make a change that affects performance, that engineer should help the designer make the best overall design decision — not just roll over and do what the designer asked. It’s this type of respectful collaboration that makes great design happen.

One of the best ways to encourage empathy is to watch customer research studies with co-workers from across your company. When my colleague Michael Margolis runs a study with a GV company, we insist that the real team — not just the designers — watch those interviews and take notes. If it’s not possible for everyone to watch in real time, you can record the sessions and schedule a “viewing party” for later.

Work outside your design team

When you accept that design happens almost everywhere in your organization, you have to take responsibility for it. Your app is slow? Go sit with your engineering team. Your marketing team is poorly communicating your product to future customers? You’d better offer to work with them on the problem.

Yes, doing design with everyone at your company is a lot of work. But it’s necessary if you want to be a truly great designer — otherwise, you’re simply papering over bad decisions. For example, imagine that your CEO created a complex pricing structure for your product. You could focus on making the pricing page as clear as possible using your interface and information design skills. But the harder and more important design opportunity is to work with your CEO on repricing your product so it’s clear to customers and compatible with the business goals.

Focusing on the core business is what differentiates real product design from interface design or even user experience design. Fundamental product design is really hard and requires a lot of legwork, but this is what designers at the highest level do — and it’s why their work is better than yours.

Grow your design team to include non-designers

Design is a hard job. You’ll need a wide range of skills (look at all of those circles in the diagram of UX Disciplines by Dan Saffer) and years of practice to truly master design.

Maybe that’s why so many designers are offended when non-designers do design work or get called “designers” by Jared and me. You can act offended if you want, but the reality is that other people are making design decisions with or without you. Embrace them . They don’t make your job less valuable. They don’t make your job title less meaningful.

Having more people who do design is additive, not competitive. These designers make your team and your product stronger, because they’re contributing from their unique perspectives. Help them bolster their skills, and use their expertise to the advantage of your product and company.

Let’s make a better future together

A few years ago, I met an executive from a Fortune 500 company. When I told her I’m a designer, her eyes lit up. “Oh, I love design!” she said. “My group is just down the hall from the design team. They do so much creative work in there.”

My heart sank. The design team was just down the hall from this executive, but they didn’t work together. Instead, the designers sat behind soundproof glass walls and did special “creative work” in isolation.

This executive made decisions every day that affected her customers. She bears some of the blame for not reaching out to the designers “in there.” But the design team is primarily at fault — for missing an opportunity to reach out and work together on some of the business’s most important challenges.

Thanks to Jared M. Spool for writing an excellent article, John Zeratsky, Nick Burka, and Michael Margolis for editing and suggestions, and Alex Schleifer for the excellent Wired interview.

Everyone is a designer. Get over it. was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most common questions about the GV sprint process is “How do you run a remote sprint? What if the team can’t be together in one place?”

I’ve heard stories of people running successful remote sprints, but to be honest, I never totally believed it. Part of the sprint magic is being in the same room.

But this year, our team at GV was forced to run a few distributed sprints… and it actually worked. It’s not ideal and it’s not great, but it’s definitely possible.

I still don’t have a perfect answer for how to make remote sprints work. But if you decide to try it, I have enough ideas to (hopefully) keep you from going crazy. Here goes…

Tricks I’ve tried that worked:

• Use Google Hangouts for video. I am totally biased toward Hangouts because I used to work on it long ago. But it really does work nicely for multi-person video chat.
• Use Google Slides for Monday’s whiteboard (or a Google Drawing). I am biased against Google Slides because I don’t think it’s very good for making presentations. But it does make a decent whiteboard. The collaborative features allow people in all locations to edit Monday’s map, long-term goal, and sprint questions.
  Maybe more important, everyone is equally disadvantaged. When you have a whiteboard in one location, it’s great for the people there and lousy for everyone else. With Slides, everyone’s looking at the same mediocre thing.

• If you can, buy a decent USB conference microphone for any room where there are multiple people. We’ve used this one and it’s pretty solid.
• Try multiple webcams in one room. If you have several people in one location, don’t just have one computer dialed into the Hangout. Aim one web cam at the room, one web cam at the whiteboard, potentially even a third on the speaker. (Obviously mute all the mics except one or it’s gonna get real psychedelic real fast).
• Consider narrowing the sprint to one location on Wednesday and Thursday — just have the people in one location decide, map, and prototype, then bring the group back online to review the prototype (Thursday afternoon) and to watch the test (all day Friday) together. I know it sounds like a cop out, but Wednesday is especially tricky over video chat.
• On Friday, just debrief at the end of day, not between each customer interview (unless you have specific requests for the interviewer). Each location can take their own notes, come up with their own conclusions, and then talk over video chat at the end to compare. We’ve done this a few times and it works well — syncing up with a call or video chat between every interview burns a lot of energy.

Things I haven’t tried that might work:

• Do How Might We notes separately. Let each location (even if it’s just one person) come up with their own top 1–3 How Might We notes, then merge them at the end.
• Do sketching separately. After doing lightning demos as a group, each individual could sketch on their own and turn in their work at the end of the day.
• You could probably use Google Slides for Wednesday’s decision activities. Put photos of the sketches into a slide deck and have people add dots using circle shapes. It would be a pain.
• Divide up for storyboarding and prototyping: These activities are super hard to do over video chat. If you only have people in two locations, try dividing the prototype into two chunks (especially easy if you’re doing a Rumble). Then the team in each location can make their own storyboard and prototype, checking in with each other a couple of times ahead of the test.

Running a remote sprint is pretty exhausting

Remote sprints are harder than in-person sprints. There’s something about tracking a group of people over video that exhausts our poor caveman brains. If there was ever a time to break a sprint over a couple of weeks (maybe “Monday” happens on week 1, and the rest of the sprint happens on week 2) it’s with a remote sprint.

I still say sprints in person are the way to go. And like I said, this list is incomplete. If you have more ideas, write a response below! (And hey, pick up the Sprint book if you haven’t already.)

How to Run a Remote Design Sprint Without Going Crazy was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two notes:

1. Yes, that’s my best acting.
2. Yes, the video is 98 seconds long. But the last 8 seconds are a sales pitch, so they don’t count.

Speaking of sales pitches, if you’d like to read more about sprints, you can buy our book here.

GV’s Sprint Process in 90 Seconds was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

GV has invested in more than 300 startups, so I’ve had a lot of practice. Again and again, I start from scratch, understand the business and industry, then find a way to help each team answer their most important questions.

So when I had the opportunity to address a group of Google UX researchers, I decided to talk about what I’ve learned from this experience and how I approach research projects.

Here are the slides and audio from the talk.

Feel free to respond below if you have thoughts or questions!

Start at the End: How to Do Research That Has Real Impact was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

In other words: I’ve seen a lot of design teams in action over the past decade. The people on these teams are invariably talented, smart, and hard-working. But having great people doesn’t guarantee great teamwork.

I’ve come to recognize eight common dysfunctions of design teams. Fortunately, I’ve also seen solutions to these dysfunctions — proven, reliable, and simple techniques that teams can use to work better together. And finally, I’ve translated these ideas into a set of mantras that capture the best behaviors of successful design teams.

1. The “everybody knows” fallacy

When we start a project, we assume that everyone shares the same understanding of the problem and goal. The truth is that knowledge is not distributed evenly on a team — everybody knows different things. Even on teams that communicate well, there’s rarely an opportunity to unpack all this knowledge for the benefit of the group.

Solution: Assemble a cross-functional team, then interview your teammates and write down what you learn.

Mantra: “Get the right people in the room.”

2. Starting with solutions

Design teams are full of enthusiastic, creative problem-solvers. Our instinct is to kick off a project by thinking of solutions right away. It’s a lot of fun, and it feels like an efficient way to work. Unfortunately, it’s not the best use of everyone’s problem-solving energy. Without a good understanding of the problem, we get solutions that are all over the map — some good, some bad, and some solving the wrong problem.

Solution: Understand the problem. Talk about your goals, metrics, and questions for the project. Map out the problem before you create solutions.

Mantra: “Start at the end.”

3. Brainstorming

Research back to 1958 shows that group brainstorming produces ideas that are inferior to good old fashioned solo work, but we do it anyway. We can’t resist!

Solution: Ask individuals to work on their own, then record, vote, and combine ideas. Avoid unstructured group discussions.

Mantra: “Individual work is better than group work.”

4. Premature commitment

In our march toward solving a problem, we’re too likely to get stuck on the first reasonable solution that comes along. Many teams explore a range of ideas, but they’ll commit to one before validating or evaluating the others in detail. In other words, premature narrowing is often the cause of premature commitment.

Solution: Create time and structure to capture competing solutions to a problem in detail.

Mantra: “Diverge before you decide.”

5. Groupthink

Groups are no good at making decisions — at least not the way we normally do it. We want everyone to be happy, so we talk and talk until we’ve reached consensus on a decision. And we let social dynamics get in the way: power relationships, seniority, loud mouths, etc. This all leads to decisions that nobody is excited about; that don’t reflect a unique, opinionated perspective.

Solution: Use voting to capture everyone’s opinions, then lean on the decider to make the call.

Mantra: “Wisdom of the crowd without the groupthink.”

6. Polishing a brick

We spend way too long polishing and perfecting unproven solutions. It’s understandable — we aim for a certain level of quality before releasing anything — but it’s sadly common when we don’t have a short-term plan for testing our ideas.

Solution: Set deadlines you can’t get out of. Use a timer to keep track of activities. Create uninterrupted “deep work” time so you can really get stuff done.

Mantra: “Create time pressure.”

7. Shaky foundation

Every promising solution is built on a foundation of assumptions about our customer, our product, and our world. And that solution represents a hypothesis that we believe is true (i.e. “if we build this it will help our customers”). But too often, design teams let these assumptions and hypotheses go untested. Instead of a solid foundation, we stand on a shaky foundation of things we believe to be true — but don’t really know.

Solution: Ask your team to list assumptions, hypotheses, and risks. Build prototypes you can use to test and validate.

Mantra: “The more we learn, the less we know.”

8. Obsessed with shipping

Shipping has achieved mythical importance, at least in our world of software products and digital services. “Ship early, ship often.” “Move fast and break things.” We’re obsessed with shipping because we think it’s the only way to truly test our ideas. It’s fun, it’s rewarding, and it gets us attention. But launching always takes longer than expected, and it’s very difficult to un-launch a product that’s not working. Most importantly, measuring a live product won’t tell us why it’s working — or not working.

Solution: Do a series of prototype-and-test loops before you commit to building and shipping something new.

Mantra: “Learn early, learn often.”

I’m willing to bet that these observations aren’t surprising to you. Maybe you’ve seen the dysfunctions cause problems for your team, or recognize the solutions from a time when your team was firing on all cylinders.

But it’s not always easy to do the right things. These eight are common dysfunctions for a reason — they represent the path of least resistance for design teams.

One of our goals with the sprint process was to package together all of these good habits, to make the right behaviors the default behaviors. It can be hard to remember these habits day to day, but in a sprint, good behaviors happen automatically.

This article was originally published at InVision.

Eight common dysfunctions of design teams (and what to do about them) was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

Plenty of authors have proposed systems and philosophies for getting more done at work. My writing partner Jake Knapp created his own solution in 2009: the sprint. It’s a five-day process that helps teams focus on one big goal, taking them from ideas to prototypes to customer research in just a week. In a sprint, you get to fast-forward your project — to see what the end result might look like and how customers would react.

But the sprint is not another theoretical model or framework. It’s a proven recipe, and in our book Sprint, we provide detailed hour-by-hour instructions for following that recipe. At GV, we’ve tested the process with more than 100 companies. We help our startups use sprints to answer big questions, test new business ideas, and solve critical challenges. We’ve seen firsthand, again and again, how sprints help teams get more done and move faster.

Yes, sprints are fast, but it’s not what you think. The sprint is not an all-out, late-night, stack-of-pizza-boxes-on-the-conference-table affair. In fact, the sprint day only lasts from 10am to 5pm. You’ll have plenty of time to hang out with your family, meet up with friends, get a good night’s sleep — and yeah, stay caught up on those pesky emails.

Why do sprints help teams get more done? It’s not just about speed. It’s about momentum, focus, and confidence. The companies who use sprints (in fields like oncology, robotics, coffee, and dozens more) see consistent results from the process. Here are five of the most important outcomes.

Sprints help you start

When a big problem is looming, it can be tough to dig in and get started. Sprints make an excellent commitment device — when you gather a team, clear the calendar, and schedule customer interviews, you commit to making progress.

GV portfolio company Savioke found themselves in this same situation: they had spent months developing their delivery robot for hotels, but felt paralyzed by big questions about the robot’s personality and behavior. We planned a sprint, and by the end of the week, the Savioke team had tested a simple robot personality with actual customers.

Sprints move you from abstract to concrete

Too many projects get stuck in Abstractopia: an alternate universe where debates, theories, and hunches are plentiful, but concrete progress is rare. For podcast startup Gimlet Media, an abstract question — “should we become a technology company?” — was causing anxiety for founders Alex Blumberg and Matt Lieber.

Gimlet decided to run a sprint on the question, and almost immediately had an answer. That’s because, in every sprint, you sketch specific solutions (not abstract ideas) and build a realistic prototype before the week is up. Gimlet’s sprint helped them see what their future as a technology company would look like. And in their case, it led the team to decide it wasn’t necessary to reach their goals as a company.

Sprints focus you on the important things

Think about the typical day at work. With all the noise, distractions, and demands for your attention, it’s almost impossible to see what’s truly important. That’s why every sprint starts with an entire day devoted to mapping out the problem at hand. Then, after your team has built a shared understanding of the challenge, you can figure out exactly where to focus.

When Flatiron Health began work on a new tool for cancer clinics, their focus naturally turned to doctors and patients, the typical stakeholders for their products. But when we sprinted together, the Flatiron team realized that research coordinators (the folks who administered clinical trials) were actually a more important group to focus on. By the end of the week, Flatiron had tested a prototype with research coordinators and had the confidence to move forward with the project.

Sprints force crisp decision-making

Business-as-usual decision-making is busted: we strive for consensus; we don’t make tough calls; we aren’t transparent about how decisions are made on our team. The sprint corrects these problems with a recipe for better group decision-making.

The leadership at Slack used that structure to decide between two fundamentally different marketing approaches. One approach was unique, bold, and difficult to implement. (It was also the CEO’s favorite.) The other was more conventional but easier to build.

Slack could have debated the merits of each approach, or just went with the CEO’s hunch. But in our sprint together, we cleanly separated the two concepts, then decided to prototype and test both. After Friday’s customer test, the results were clear: the simpler marketing was more effective, and the CEO’s favorite, while clever, wasn’t as successful with customers.

Sprints point you down the right road, so you can go full speed ahead

Your team will accomplish a ton in every sprint, but the knock-on effects — the confidence of knowing you’re on the right road — are even more powerful.

When GV startup LendUp began working on a new credit card for consumers with no or low credit, they had a lot of ideas for helpful features. But they were stuck: without a clear prioritization of features it was difficult for them to make progress on designing and launching the card. In our sprint together, we created fake credit-card marketing to test LendUp’s ideas. Armed with the results — a clear delineation between essential and unimportant features — their team went full speed ahead with the card.

How would your team behave differently if they knew they were right? How much faster could they go? Sprints can give any company the confidence to get more done, not just during the sprint, but down the road. And the best part is: you don’t have to make sweeping cultural or personnel changes to make it happen. You just have to try a sprint.

This article was originally published at Harvard Business Review.

Every team can get more done with sprints — but it’s not just about going fast was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

What to do when your team is focused on unimportant details

Last week, I met with two companies that are building incredibly complex, ambitious medical products. One of the companies is trying to fundamentally improve cancer outcomes in a way that could save millions of lives. The other company is trying to eliminate an entire class of diseases — not improve treatment, not cure a specific disease, but to eliminate a whole set of diseases. Wow.

I’m a pretty experienced designer, so when I talked to these companies’ leaders I expected to discuss the complexities of their product design challenges. Instead, the first company wanted to talk about what shade of carpet they should choose for their new office and the other company wanted me to work with them to improve their PowerPoint master template.

Wait, what?

These companies aren’t ignorant about the power of design. My team at GV has worked with them before and previously we worked on big, strategic projects. So, why were they focusing on such surface-level design challenges this time around?

Back in 1957, a guy named C. Northcote Parkinson observed that people often give disproportionate focus to trivial projects at work. As an example, Parkinson described a team that is creating a nuclear power plant. During the planning stages, a big debate breaks out about the design of the shed where employees will park their bicycles. Instead of arguing about the details of power mechanisms, cooling systems, or waste fuel storage, it seems like everyone’s focus is on what material should be used for the bike shed roof.

And, no wonder. At work, you’re expected to have intelligent opinions and propose smart solutions to problems. But, when you’re working on something that is very complex, it’s intimidating and exhausting to have opinions on the biggest challenges. It’s so easy to focus your attention on the issues that are easy to grok and which won’t (literally) blow up in your face if you’re wrong. So, it’s understandable that people schedule meetings about the roof of the bike shed so that they can voice their opinions and feel useful and heard.

This idea became known as Parkinson’s Law of Triviality or “bikeshedding” and there’s an excellent Wikipedia article that explains it in more depth if you’re curious. So, now that you’ve got a name for the phenomenon, what can you do about it when everyone is breathing down your neck about the carpet color or the PowerPoint design?

Here are the key things I’ve found that help when people start bikeshedding:

Embrace the attention

Be patient and look on the bright side. Wow, everyone is suddenly focused on your little corner of the world! Sure, it can be frustrating when many people voices their opinions, often unasked-for, but it’s also your chance to shine on a project of perceived importance. Grab this opportunity by the horns and keep your frustration under check. Try to embrace the mindset that every project is important — even the PowerPoint deck or the choice of carpet color. You have everyone’s attention and if you can pull the team together and choose a great roof for this particular bike shed, they’re going to be thrilled with you.

Listen carefully

If you’re the designer who is responsible for the project, the first thing you need to do is take the time to listen to everyone else. We know what’s driving this sudden interest in a seemingly trivial project: people feel overwhelmed by a different, complex issue and your project has become an escape valve. In some ways you’re now a therapist. Listening and accepting input is valuable in itself because you’re offering people an outlet. And remember, just because people offer direction and advice doesn’t mean you have to do everything they suggest, so take the time to absorb everyone’s contributions.

Ensure that people feel heard

This is the most important part. It’s not good enough to just listen to people, you also need to make sure they know they were heard. This is part of your role as a designer/therapist. I’ll repeat what I said earlier, you shouldn’t necessarily literally do what people suggest. But, when you choose Franklin Gothic for those PowerPoint titles, explain where this decision came from and show how people’s feedback helped you reach this choice. Your teammates will feel like you’ve accomplished something important together, even if you personally feel like the project is a distraction.

Timebox the project

Setting a deadline for your “bike shed” project has two benefits. First, it will help you spend an appropriate amount of time on the project. You’ll get the job done but quickly move on to more important efforts. And second, a deadline can actually produce better results. We’ve seen again and again how time pressure helps teams create great solutions together.

Gently refocus people’s passion

It’s often really difficult to redirect people’s focus back onto larger problem, but sometimes it is possible. One way to be successful is to lean in and work on the hard problem yourself. Of course, you may not be qualified to make decisions on something as complex as a nuclear power plant’s power supply systems, but you may be able to step in as a facilitator to help move that decision-making process along in a healthy way. Now that the big, tough issue is unlocked and moving ahead, people will hopefully turn their focus away from your simpler project.

And, in the end, it’s often simply helpful to have a name and an explanation for things. The next time you’re caught leading a 2-hour meeting about fabric samples, you’ll be that person who laughs knowingly… we’re bikeshedding here, people.

A designer’s guide to Parkinson’s Law of Triviality was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.