Framework

Partners in your users' success

Take a moment to think about what your team values.

Not every organization puts users first. Sometimes, they have an explicit business rationale. For example, in a highly commoditized industry you might prioritize cost of delivery over user experience. As a design thinker, you might not agree with it, but it’s still a valid strategy to pursue.

But we’re not measured by the features and functions we ship. We’re measured by how well we fulfill our users’ needs. Whether we’re helping them discover a cure for cancer, collaborate across continents, or just do their expense reports a little faster, our users rely on us to help get their jobs done everyday.

When we shift the conversation from one about features and functions to one about users and user outcomes, we deliver more useful, usable and desirable solutions. We elevate professions and redefine industries. But most importantly, we earn the trust, respect and repeat business of the people we serve.

In practice

At a time when user needs are increasingly synonymous with market needs, delivering great user outcomes is increasingly synonymous with business success. But as our users’ needs grow and evolve, they expect our offerings to grow and evolve too. It’s no longer enough to stumble our way to great user outcomes. Every aspect of how our teams work—from the metrics we measure to the language we use—must be user-centered.

As a team manager, you can do your part by identifying who your users really are and aligning the way you manage with the user outcomes. As a team member, you can do your part by getting to know users as people and learning about the role they play on their team. Lastly, take the time to learn more about the practice of human-centered design.

As a team manager

Differentiate between users and clients

Your first line of contact with a client organization is oftentimes a client or economic buyer (for example, a CIO), not an end user.

Take any second-hand information about your users’ experience with a grain of salt. While your client might do their best to represent the user as faithfully as possible, they might not have the exposure required to understand the lived experience of users in their organization. Work with them to identify and connect with the real users for whom you’re designing.

Manage toward user outcomes

Delivering great user outcomes demands leadership and management practices that align your teams’ work with your users’ needs. No matter what project governance process you use today, the Keys of Enterprise Design Thinking help put user outcomes at the center of your work:

• Hills define success based on discrete user outcomes instead of a list of features and functions.
• Playbacks capture the nuances of your users’ context by telling stories from their perspective.
• Sponsor Users get real users involved in the project from the very beginning.

Measure user outcome metrics

You are what you measure. Paying attention only to metrics like revenue and operating costs undermines your team’s effort to focus on the problems that matter most to users of our offerings. Choose appropriate user outcome metrics that help us learn and understand user behavior. Measure usability, usefulness and desirability, both in development and in-market.

If you don’t know where to start, consider employing a metric such as Net Promoter Score (NPS), which gauges a users’ loyalty with an offering. An offering’s NPS is shown to correlate with other similar metrics such as customer effort score. It is also shown to act as a leading indicator of growth—when your NPS goes up, it’s likely that your revenue will too.

As a team member

Build empathy with users

An authentic focus on users begins with a simple acknowledgment: we’re not our users. Understanding what really matters to people requires you and your team to put away biases, set aside personal preferences, and see the world as they see it. This requires empathy.

When we make the effort to truly empathize with users, we understand that our users are real human beings with values, behaviors, hopes and fears as complex as our own. Each of these characteristics influences the way that our users interact with the systems we build.

Understanding users isn’t just about creating great personas or making accurate user behavior predictions with data. It’s about getting to know them as people first, “users” second.

Understand their role

In reality, most users don’t work alone. They’re often part of complex, interdependent systems of people and processes that work together to achieve a greater goal.

While each individual user is important, it’s equally important to understand the needs of their teams. Get to know the spectrum of processes in which your users participate and what’s expected of them in their role, from the mission-critical to the mundane. Find out whom they rely on and who relies on them. The needs of their business play a key role in shaping the way they behave.

Solve old problems in new ways

Human needs fundamentally don’t change. The ways we address them do.

Consider this: we’re still improving the way that we get from point A to point B. Yesterday’s horse-drawn carriage was a prototype for today’s automobile. Today’s automobile is just another prototype for tomorrow’s transportation breakthrough.

The problem is defined by a fundamental human need: getting from A to B. The solution at any point in time is situated in the constraints and affordances of the era: technological advancements, evolving resources, changing consumer expectations.

Being essential to your users and clients over time is about engaging in a continuous conversation with them through the solutions that you offer. As you iterate on the next generation of offerings, stay true to the fundamental human need you’re solving, and stay in touch with the evolving context it inhabits.

In practice

Here’s the thing about restless reinvention: you never feel done. There will always be a better solution just around the corner. If only you had a little more time. If only you had a few more resources. If only the technology was a little better.

But if you don’t commit to an idea, you risk missing your window of opportunity as the market evolves and your users’ lives move on. Without committing to an idea, there can be no outcome.

Recognize that from the perspective of your users, no solution is perfect. When you use Enterprise Design Thinking, your bias is toward action. You pursue perfection with the humility of knowing that in the fullness of time, nothing is actually perfect. That is: everything is a prototype.

Better together

Team: A group of people working together toward a common outcome

We’re often asked to solve our users’ and clients’ hardest problems—problems too complex and multifaceted to be meaningfully solved alone. We rely on the strength of our teams in order to solve these complex problems and generate value for our users and clients.

While it’s important to focus on user outcomes, it’s equally important to design the way our teams are organized to achieve those outcomes. To ensure our teams’ ability to generate better ideas and deliver real-world outcomes for users, we consider two important team factors: diversity and empowerment.

Diverse: composed of differing elements or qualities

Differentiation through diversity

Diversity is more than just a moral responsibility. It’s fundamental to the success of our teams. Consider this: when building teams, you aren’t just assigning resources—you’re framing your approach to the problem. Each team member brings their unique perspective and expertise to the team, widening the range of possible outcomes. If you want a breakthrough idea, you’re more likely to get it with a diverse team.

Diverse teams see the same problem from many angles. They have a better understanding of any particular situation and generate more ideas, making them more effective problem solvers. While it takes effort to harness and align such different perspectives, it’s at the intersection of our differences that our most meaningful breakthroughs emerge.

Empowered: Having the expertise and authority to achieve a desired outcome

Speed through empowerment

If diversity helps teams generate breakthrough ideas, empowerment enables them to turn those ideas into outcomes.

Consider a design team that can quickly deliver mock-ups but must wait for a separate engineering team to implement the work. Or consider a team bogged down in meetings, constantly trying to win stakeholder agreement for every little operational decision. Neither situation enables a team to move fast.

In contrast, empowered teams have the agency to make everyday operational decisions on their own. They’re equipped with the expertise and authority to deliver outcomes without relying on others for leadership or technical support. By pushing operational decisions down to the lowest level, we give our teams the ability to achieve the rapid iteration our users and clients demand.

In practice

A recent visual design graduate from a historically Black college in Atlanta, Georgia might be working with a software architect in Beijing, China who’s been in the tech industry for decades. They might not understand each others’ way of life. They might never meet in person. But their fates are intrinsically linked—because in the midst of the complex problems we’re solving, they need each other more than ever.

Making these relationships work requires effort from managers and team members alike. As a team manager, your responsibility begins with staffing teams with the diversity of perspective and expertise they need to be successful. As a team member, your responsibility is to cultivate inclusive behavior, harness conflicting perspectives to generate new ideas, and take the initiative to achieve a great outcome.

As a team manager

Assign team leadership

We define teams as people working together toward a common outcome. When you use Enterprise Design Thinking, you use Hills to define your intended user outcomes, and therefore, the breakdown of your teams as well.

For each Hill team, you also want to assign a core leadership team. These leadership teams should be composed of functional leads from each discipline. Grant them the authority to handle day-to-day triage on the team and hold them accountable for achieving their assigned outcome.

Form self-contained teams

Consider these different aspects of your own identity, experience and expertise. No single dimension defines who we are. Rather, they combine together to shape our unique perspective.

Identity

• Age and ability
• Gender identity
• Race and ethnicity

Experience

• Cultural upbringing
• Geography
• Language

Expertise

• Education
• Organization
• Discipline

Building diverse teams requires you to actively seek people with different perspectives. Avoid staffing teams based on alignment of identity, experience or expertise. While it might seem counterintuitive at first, every dimension of diversity is vital to a team’s ability to manage complexity and generate breakthrough ideas.

However, empowering your teams to turn those ideas into outcomes requires special attention to a team’s diversity of expertise. To achieve self-reliance, equip each team with the full range of expertise needed to independently deliver their assigned outcome. This minimizes dependencies on resources beyond their control, enabling them to decide quickly and independently.

Give them space

The most challenging part of working with a truly diverse empowered team might have nothing to do with staffing.

As a stakeholder, working with an empowered team requires you to give them the space to define their unique character. While it doesn’t mean you can’t stay in the loop with them, it does mean giving control over day-to-day operational decisions to the team.

You might not always agree with the way they work. But just remember: when John F. Kennedy challenged NASA to go to the moon, he didn’t micromanage the team. He got out of their way and empowered them to do what they do best.

As a team member

Be inclusive

What goes through your mind when you’re adding people to a meeting invite? Whom are you including? Whom are you excluding?—and why?

The truth is that instinct often leads us to avoid conflict and seek out people who think alike. But keep in mind: When teams fail, it’s usually not because they don’t have great ideas. It’s because they aren’t including the people who have them.

As a designer, you might find yourself struggling to understand the limitations of a technology stack. As an engineer, you might find yourself struggling to identify the prevailing values of your client’s organizational culture. But if you fail to use each others’ expertise, you both fail to grow.

At minimum, critical team conversations should include representatives from every discipline affected. It would be unwise for engineering to make timeline decision without engaging product management in a conversation, or for product designers to make brand decisions without consulting the marketing team.

This kind of radical collaboration requires a foundation of trust, respect and shared ownership across the team.

Take advantage of conflict

Consider the last time someone disagreed with you.

Did you listen to understand their argument, or did you listen to poke holes in it? Did you explore the underlying reasons behind their point of view, or did you seek reinforcement from others who shared yours?

Diversity invites conflict—and conflict is a wellspring of creativity. Harnessing this creativity requires us to listen to understand, not just argue with, with those who might disagree. When you’re listening to understand, you uncover brand-new ideas together and contribute to a more open and collaborative culture.

We have a saying: “Empathy: first, with each other, then with our users.” The next time someone disagrees with you; don’t jump straight to why they’re wrong. Try saying: “Help me understand.” It takes courage to admit we don’t know everything, but it’s essential to improving our team’s collective outcome.

Take the initiative

Being empowered to act means that your stakeholders have entrusted you with a shared responsibility for your team’s collective success. It doesn’t mean that you can ignore their counsel and direction. However, it does mean that your team is expected to take the initiative to solve problems and deliver your assigned outcomes on your own.

This responsibility can be uncomfortable at first. But when your team rises to the occasion, you deliver better outcomes faster, build trusting relationships with stakeholders and grow your skills as a leader.

Immerse yourself in the real world

Whether you’re identifying new opportunities or evaluating existing ideas, breakthrough ideas are born from a deep understanding of the real-world problems we’re solving for our users. This understanding isn’t gained by sitting at our desks and conference tables. It is gained by getting out of the building and meeting our users where they are.

Observing users in their world allows you to empathize with their experience, understand their context, uncover hidden needs, and hear their honest and unfettered feedback. As you investigate their world, soak up what you see without judgment and observe the obvious with a critical eye. Great discoveries often begin with an observation that you can’t explain.

Understanding can’t be delegated. Observe as a team when you can and share your findings with each other when you can’t. Everyone on your team should have the chance to see their users’ world so they can contribute their unique perspective to the situation.

Get to know users

Empathy begins with getting to know people as people, not just as users. Ask open-ended questions about how they live and work. Listen to their stories to understand their hopes, fears and goals that motivate them. Better yet, put yourself in their shoes to absorb the highs, lows and nuances of their lived experiences first-hand.

Understand context

Your users don’t live in a bubble. They’re often part of complex, interdependent systems of people and processes that work together to achieve a greater goal. Watch users interact with the people and tools in their environment. Find out who they rely on and who relies on them. Sometimes the most effective way to help your users is to help the people around them.

Uncover needs

Your users aren't always able to express their needs, so it’s your job to read between the lines and uncover them. Reveal their challenges and figure out what’s at stake if they fail. Find out how they measure success and where their existing solutions fall short.

Listen for feedback

Test your ideas, assumptions and prototypes by putting them in your users’ hands. Observe their interactions, listen carefully, and capture their feedback as faithfully as you can. Take care to avoid leading questions.

Remember: this isn’t about selling ideas or seeking approval. It’s about discovering new opportunities to improve your project’s outcome.

Ask each other

If you don’t know where to start, begin with your unanswered questions. Flag answers founded on untested assumptions or answers that might have changed since your last observation.

Who are our users?

• What’s their story?
• What’s their experience?
• What influences their experience?

What are their needs?

• What problem are they solving?
• How do they define success?
• What do they stand to gain or lose?

What’s their context?

• Who do they work with?
• What processes are they part of?
• What’s expected of them?

What’s their feedback?

• How do they feel about us?
• What’s working and what isn’t?
• What ideas do they have for us?

Come together and look within

As a project progresses, we’re constantly taking in new information. Observing generates fresh data about the real world, while making generates new ideas and opportunities to pursue. But as this information reveals the complexity of our problem space, it’s easy to get overwhelmed, lose alignment or lose sight of the mission we set out to accomplish together.

This is why it’s important to regularly reflect as a team. Reflecting brings your team together to synchronize your movements, synthesize what you’ve learned, and share your “aha” moments with each other. If the situation has changed, it’s also a time to rethink how you want to move forward.

When reflecting, have the empathy to understand diverse perspectives, the flexibility to respond to change, and the integrity to stay true to your team’s values. Be honest about what you know and be open to what you hear—positive or negative. It isn’t easy to get started, but when you reflect regularly, the feedback you receive spurs your best ideas.

Get to know each other

Cultivate a common identity by discovering what unites you as a team. Get to know each other as people and build empathy with them as you would with your users. Take stock of the diversity of perspectives. Acknowledge everyone’s strengths and think of your own limitations as an opportunity for others to shine.

Align on intent

If you find yourselves drifting out of alignment, slow down and examine the intent and motivations behind your work. Come to a common understanding of your users, the problem you’re solving, and the outcome you’re working to achieve together. Take stock of the work that you’re doing and make sure it’s aligned with your team’s big picture mission.

Uncover new insights

As you take in new information, take stock of what you know and what you don’t know. Synthesize your knowledge to uncover hidden insight that illuminates the path forward. An insight isn’t restating an observation—it’s a leap in clarity, reframing your point of view and changing your convictions about what’s important.

Plan ahead

As your understanding evolves, don’t move forward blindly. Decide together on your next move. You can either take another loop, or put a stake in the ground and commit to an idea. Whatever you decide, make sure you’re all clear on what you’re doing next.

Ask each other

If you don’t know where to start, consider these questions as an individual and as a team. Work to address any disagreements you might uncover.

What’s our reality?

• What are our capabilities?
• Who are our stakeholders?
• What can we control and influence?

What are we learning?

• What did we observe or make?
• What’s working and what isn’t?
• Can we derive any insights?

Are we aligned?

• What problem are we solving?
• How do we define success?
• What do we stand to gain or lose?

What’s our plan?

• What’s on our roadmap?
• What resources do we need?
• Are we ready to commit?

Give concrete form to abstract ideas

We all get caught in “analysis paralysis” sometimes. It’s tempting to put off making because we aren’t confident we have enough understanding. Sometimes we’re just afraid to share ideas before they’re fully baked. Some of us are conditioned to save making for last.

But at the end of the day, the only way to see an outcome is to make one. Making gives form to abstract ideas, giving you the chance to try out new ideas and see them take effect in the real world.

The earlier you make, the faster you learn. Summon the curiosity to try out unexplored ideas. Have the audacity to put your ideas into the world. You might be wrong—and there’s nothing wrong with that.

When you go to make, ask others to participate and build on your ideas together. Collaborating with your team members is often where your best ideas are born.

Explore possibilities

Don’t wait until an idea is perfect—it won’t happen. Think with your hands to uncover new ideas in real time. Find out what works and what doesn’t. Take advantage of happy accidents. When you’ve run out of ideas, invite others to respond, remix and transform what you’ve made. You never know what you might learn from others.

Communicate ideas

Are we seeing the same thing? A picture is worth a thousand words, so don’t tell people your idea; show them. Get your ideas out by making something that expresses your intent. Come up with your story and show them why it matters.

Prototype concepts

Prototypes are experiments that help to validate or invalidate your hypotheses and assumptions. Although it’s helpful to think of everything you make as a prototype, low-fidelity prototypes can help simulate ideas and test hypotheses quickly and cheaply. No need to make it perfect—just make it appropriate for the feedback you need.

Drive outcomes

Once you’ve committed to an idea, turn your intent into an outcome. You don’t need to know everything to get moving. Listen, learn and course-correct as you work out the details. Remember: everything is a prototype—even in-market solutions. Fail early and learn fast.

Consider these questions

If you don’t know where to start, consider the answers to these questions. If you come across a question that you haven’t explored, stop talking and start making.

What’s possible?

• What could we make?
• What ideas can we combine?
• How else might we make it?

What’s the concept?

• What is its form?
• What are its parts?
• How do the parts relate?

What’s the story?

• What’s our big idea?
• What’s the intended outcome?
• How do we show it to others?

How do we deliver?

• How do we build it?
• How do we deploy it?
• How do we maintain it?

Hills are statements of intent written as meaningful user outcomes. They tell you where to go, not how to get there, empowering teams to explore breakthrough ideas without losing sight of the goal.

Get in sync

Here’s the truth: on complex projects, things don’t always go as planned. A never-ending stream of feature requests and technical roadblocks threaten to derail progress, delay releases, and throw even the healthiest teams out of alignment. Despite these uncertainties, how can a team stay true to a project’s intent?

Hills communicate our intent for a project with clarity and flexibility. They frame problems as intended user outcomes, not predetermined implementations, empowering teams to discover breakthrough solutions. They help us keep the eye on the prize, even despite the many challenges that stand in our way.

Anatomy of a Hill

To write a Hill, start with the user you want to serve. Next, specify the outcome you want to enable them to achieve, and the differentiator that makes your solution worth their while. We refer to these elements as the Who, the What, and the Wow.

A good Hill is implementation-independent. It should specify what users are trying to accomplish, not a tool they use to do it. If you read your Hill back and it feels like it already describes a specific implementation, take a step back and try again.

Who
Who are your users? Make it clear who you aim to serve—and who you don’t.

What
What’s the need that they’re trying to meet? Turn user needs into project goals.

Wow
How will you differentiate from competitors? How will you measure success?

Examples

“A GMU-based sales leader can assemble an agile response team in under 24 hours without management involvement.”—IBM Connections, 2012

“It should take no more than 30 minutes for a developer to build and run an app using IBM and 3rd party APIs.”—IBM Bluemix, 2014

“I believe that this nation should commit itself to achieving the goal [...] of landing a man on the Moon and returning him safely to Earth.”—John F. Kennedy, 1961

Managing with Hills

If you’re on a product team, Hills are owned by product management and defined in collaboration with design and engineering. If you’re on a service team, Hills are owned by the senior client stakeholder but defined in collaboration with the delivery team. Work with your client to arrive at well-defined Hills your team can feasibly achieve within your constraints.

Don’t worry about writing perfect Hills on Day One. Hills should evolve based on your understanding of the problem. As you iterate, hold Hills Playbacks early and often. Your Hills can change right up to Playback Zero—that’s when you need to really commit.

Three Hills, one Foundation

You can do anything, but you can’t do everything. Hills should reflect an investment in the most valuable outcomes for your users, and the most important differentiators for your organization. That’s why we strongly recommend that a project takes on no more than three Hills at any time. This helps you maintain a focus on a manageable set of goals.

In addition to the three Hills, invest a portion of your resources to the Foundation to either fix issues from past releases or to lay the groundwork for your project’s future.

Commit resources

Allocate resources to your Hills and Foundation based on their relative value to your users and your organization. Form diverse empowered teams around each Hill and equip each one with the expertise and authority needed to deliver their outcome independently. Strive to recruit at least one sponsor user per Hill.

Once resources have been allocated to a Hill, treat them as thread-safe investments. Hills provide the language to have outcome-driven conversations around your resources. If a Hill needs more resources, base your decision to reallocate on the value of each investment.

For example, let’s say you’ve allocated 25% of your resources to each of the three Hills, and the remaining 25% to the Foundation. If something in the Foundation goes wrong, ask yourself: is it worth the risk of diverting resources from a Hill to fix it?

Break them down

Sometimes a Hill is necessarily complex and might benefit from another level of decomposition to further divide the work. If you choose to write Sub-Hills, make sure each one is still a proper Hill that, if independently released, still delivers meaningful value to users.

Playbacks align us across time

Stay focused on user outcomes

In a Playback, users are the stars of the show. Give them a face and introduce them by name. Bring your audience through the experience of what it’s like to be a user. The more empathy that your audience can have for users, the more valuable their feedback is.

Playbacks bring stakeholders into the loop in a safe space to tell stories and exchange feedback. They reveal misalignment and measure progress against the big picture problem that you’re solving.

Stay in sync

In practice, not everyone has time to be in the loop on every project. If you’re a project stakeholder, it might feel like the team has drifted off-course over time. If you’re on the team, it might feel like your stakeholders are out of touch with what your team has learned about the problem and solution. How do you keep teams and stakeholders aligned across time?

Playbacks are a time to bring stakeholders into the loop to reflect together. They’re a safe space to tell stories and exchange feedback about the work. Holding Playbacks consistently keeps teams and stakeholders aligned and in sync on a project’s ever evolving situation.

Anatomy of a Playback

Playbacks come in all shapes in sizes. You can hold them one-on-one or with a larger group. You can showcase low-fidelity sketches or polished demos. Hold them anytime you need feedback from stakeholders, but consider scheduling them at regular milestones.

1) Invite stakeholders

Consider the work that you intend to share, and the stakeholders it might affect. If you’re a software team, maybe your legal counsel needs to know you’re using a new open source library. Maybe your sales teams need to know what’s next on the roadmap.

If you’re not sure who to invite, err on the side of inclusivity. Playbacks bring stakeholders together across organizational silos and levels of hierarchy, bringing diverse perspectives into the conversation and promoting a culture of transparency and inclusion.

2) Tell your story

Features and requirements are forgotten. Stories endure.

Stories show context. They have characters, relationships and plots. Stories reveal a holistic picture of what makes up a user’s experience and help the audience understand the stakes in a way that goes beyond project line items. In other words: stories make us care.

3) Listen for feedback and misalignment

Whether they’re an intern or a senior vice president, good feedback can come from anyone. Give everyone a chance to make their feedback heard. Capture what you hear without judgment.

Playbacks reveal alignment or misalignment on a team. If a Playback goes well, congratulations—you’re one step closer to moving forward. If disagreements arise, don’t panic. It’s time to take another loop around the problem and try again.

Managing with milestone Playbacks

You can hold a Playback anytime you need feedback. However, it’s helpful to schedule milestone Playbacks at critical moments in the project when your team and stakeholders need to come together and agree on how to move forward. Though each team will have their unique milestone moments, here’s an example of how a typical software product team might set up their milestones.

In your work

• Aim to have a Hills Playback as early as possible. As you refine your Hills, continue to hold them as often as you need. Instead of trying to get your Hills right on the first try, move forward and iterate on them as you learn more.

Hills Playbacks

At the beginning of the project, the team schedules a Hills Playback to ensure that all stakeholders agree on the project’s intended outcome.

The team opens the Hills Playback by sharing what they know about their users, where their product’s current user experience falls short, and what’s at stake. They discuss the project’s Hills, Foundation and proposed resource allocation.

After a successful Hills Playback, the team breaks down into their subteams. Each sub-team explores potential solutions to take on their assigned Hill.

In your work

• It can take time for teams to reach a consensus. Don’t wait until Playback zero to get investment from stakeholders. Hold draft Playbacks (“Playback -2,” “Playback -1” and so on) leading up to Playback zero. Iterate until you’ve reached alignment.

Playback Zero

Once the team believes they’ve reached a proposed solution for each Hill, they schedule their next milestone: Playback zero. Playback zeros are a time for the team and stakeholders to agree on what the team will actually commit to deliver.

During Playback zero, the team focuses on their proposed user experience. They tell a realistic, compelling story of a complete user journey for each of their Hills, visualizing the proposed solution in midfidelity: low enough to leave room for refinement, but high enough to get meaningful feedback. They travel through the solution at a high frame rate, moving through each screen the way a user might move through them.

After a successful Playback zero, the team breaks their proposed solutions into agile epics and user stories, and begins to deliver real production code.

In your work

• Hold delivery Playbacks after significant delivery milestones—for example, at the end of each sprint, or after you’ve achieved a Hill.

Delivery Playbacks

At the end of each sprint, the team holds delivery Playbacks to review the overall user experience and measure progress against their Hills.

Instead of relying on mock-ups or prototypes, the team runs the Playback by using the real working solution. But unlike simple end-of-sprint demos, delivery Playbacks tell the user’s end-to-end story through the solution, helping the team identify important user experience gaps they need to prioritize.

After a successful delivery Playback, the team leads discuss whether the product is ready to release to real users.

In your work

• Before you hold a client Playback, make sure that you have the necessary legal agreements in place to share confidential information.

Client Playbacks

As the solution develops, the team holds Playbacks with important clients who have agreed to sign a nondisclosure agreement. In client Playbacks, the team presents their product’s roadmap, their three Hills and the user experience they intend to deliver. In return, the clients provide feedback for the team to continuously improve their offering.

Sponsor users align us with their reality

Stay in touch

Despite our best efforts, empathy has its limits. If you’re designing the cockpit of an airliner but you aren’t a pilot, you don’t know how it feels to land a plane. Without that first-hand experience, it’s easy to lose touch with our users’ reality and allow bias and personal preference to creep into our work.

Sponsor users are real users or potential users that bring their experience and expertise to the team. They aren’t passive subjects—they’re active participants who work alongside you to deliver a great outcome. While they can’t completely replace formal design research and usability studies, sponsor users help you break the empathy barrier and stay in touch with real-world needs throughout your project.

Anatomy of a sponsor user

A good sponsor user is representative of your intended user, they’re invested in the outcome, and they have the availability to regularly work with you and your team.

1) Are they representative of your target user?

A good sponsor user reflects the actual user that you intend to serve. As enthusiastic as your client, customer or economic buyers might be to help you, they are often not the user who will ultimately derive personal value from your offering.

2) Are they personally invested in the outcome?

A good sponsor user cares as much about your project’s outcome as you do. Look for candidates who have a particularly demanding use case—a sponsor user that relies heavily on your offering to be successful has a vested interest in your project’s success.

A word of caution: don’t mistake a demanding use case with an “extreme” use case. If you’re working on a Hill regarding a family minivan, a race car driver probably isn't a great sponsor user candidate, regardless of their interest to work with you.

3) Are they available to collaborate?

A good sponsor user is open and willing to share their expertise and experience with your team.

While being a sponsor user isn’t a full-time job, it is a commitment. Set expectations, but be respectful of their time and be flexible around their schedule. What’s important is that their insights and ideas are heard.

Working with sponsor users

If you’re on a product team, sponsor user relationships are owned by product management and design, but it’s worth connecting with your sales and marketing teams to provide candidates. If you’re on a services team, your client can connect you with sponsor user candidates in their organization. However, the product team is responsible for communicating sponsor user criteria to the client.

While sponsor users don’t replace formal design research and usability studies, every interaction you have with them closes the gap between your assumptions and their reality. Treat them as a part of the team. As collaborators, they leave a significant mark on the project.

Sponsor users and Hills

Make sure to write Hills and have a sense of your target users before attempting to recruit sponsor users. As you refine your Hills and clarify your target users, you can begin to recruit sponsor users whose use case best fits a particular Hill. We recommend having at least one sponsor user per Hill.

Observe through their eyes

Let sponsor users show you their world. Help them see with fresh eyes and enable them to share their insights with you. Share your insights back. You might discover a side of their story that you wouldn’t otherwise see.

Reflect together

Listen carefully to your sponsor users’ input. Include them in your Playbacks and have them help refine your Hills. Like any other team member, they don’t always get what they want. But if they tell you that you’re not solving their problem or that you’re adding complexity to their lives, you’re probably going in the wrong direction.

Make collaboratively

As you make, let your sponsor users be your guide. Consult them frequently. Better yet, encourage them to contribute their own ideas by giving them the tools to express themselves and make alongside you.