A UX strategy workshop
led by Jared Spool USA, Europe & Australia   ·   2020

UX Strategy Stories

UPDATE: Temporarily Postponing our In-person Workshops

March 13, 2020

by: Jared M. Spool

It’s disappointing, but probably not surprising, that we will be postponing our in-person Creating a UX Strategy Playbook workshops.

For US workshops, we’re keeping our team safe by asking them to work from home. The Chattanooga Chamber of Commerce, whose building we are in, has canceled or postponed all of their events until further notice.

For international workshops, both our Adobe and Thoughtworks partners have closed their offices, and are still asking their employees to work from home. This will make it impossible for us to host the workshops. It’s probably also wise for everyone who was planning on attending to keep their own social distance, to help keep the Coronavirus infection rate down.

It’s our current plan to reschedule all workshops including the ones for Chattanooga, London, Berlin, and Manchester.

Once we know more details about our rescheduled workshops, we’ll post the details here. Everyone who has registered for a postponed workshop is guaranteed a seat in any of our future workshops.

If you have any questions, please reach out to us.

Stay well and wash your hands. We hope to see you at a future Creating a UX Strategy Playbook workshop.

UX Hiring: The Power of the Screening Question

March 10, 2020

by: Jared M. Spool

“In 250 words or less, tell us about the UX project you’re most proud of.”

We use a tailored form of this question when we’re helping clients with their UX hiring. While the specific question we ask candidates will vary, it does the same thing each time: It tells us which candidates to talk with first.

It’s a great prioritizing tool because, unlike a résumé or portfolio, it’s specific to the job we’re hiring for. For example, when our client was hiring a new senior designer to lead a massive design system implementation and rollout, we asked “Tell us about the biggest design system implementation and rollout you’ve ever led.” The answers that came in told us exactly which applicants we should talk with first.

A simple technique to speed hiring

The number one priority for hiring great team members is to uncover the evidence of each applicant’s comparable experience. The answer we get from each applicant is the first inkling whether they have the experience we are seeking in an ideal new hire.

Candidates love a chance to brag about their best work. But résumés and portfolios aren’t tailored to tell us what in their past history is relevant to the job we’re trying to fill.

Résumés and portfolios are often generic documents that candidates create once. They send the same documents to every position they apply for, independent of the job.

By asking about something that’s specific to the team’s upcoming project work, we can get the applicant talking—from the first moment they apply for the position—about potentially relevant accomplishments.

We can push candidates with high-potential to the front of our hiring pipeline. If it turns out they are right for the job, we find out early. We can expedite their subsequent interviews, discussions, and reference checks. If the candidate meets our needs, we’ll make them an offer.

All this happens faster because we asked this simple question up front.

Tailoring the question for our upcoming work

We’ve always tailored the screening question for the specific job we were trying to fill.

When we were hiring a senior design leader to start a new team at one of our bigger clients, we asked applicants to “Tell us how you built the best design team you’ve ever led. What made the team so great?” The answers we received were amazing and highlighted the most promising candidates right away, in a way that neither their résumés nor their portfolios ever did.

With another client, we were hiring more junior UX team members, to free up their senior team from day-to-day production work. For these candidates, the team expected to train any new hires on the production work. They wouldn’t have that experience already.

For these positions, our screening question focused on how the applicants learn: “Tell us about a recent difficult project that you learned how to do on the job. What made it challenging and how did you learn how to do it?” We were looking for answers that demonstrated they were strong self-learners, even when things got complicated.

We work hard to get our screening question to reflect the bulk of the work. That makes it more effective. We receive better answers from our applicants and we can quickly identify those candidates with the most promise.

The question comes early in the application process

We ask the question up front. It’s part of applying for the position.

In the job ad, we describe the work that the new hire will do. In the ad, we ask applicants to share their résumé and, optionally, their portfolio (we never require a portfolio). It’s at that point that we also ask applicants to answer the screening question by sharing their relevant experience.

The combination of the two—describing the work and asking for their comparable experience—is what makes this technique so effective. The job ad and screening question make it clear what we’re seeking. This gives highly-qualified candidates the opportunity to call attention to themselves in exactly the right way.

What we do with the answer

The first thing we do with an applicant’s answer is thank them. You’d be surprised at how many organizations never thank applicants for applying. Sending a simple thank you helps us stand out.

We do a quick review of their answer. If there’s anything confusing or something we’d like a little more detail on, we send a quick email asking for elaboration. Every time we’ve asked, the applicant responded quickly with helpful additional information.

As we start to get applications, we look for who we’ll contact first for their 30-minute screening call. In this call, we ask the candidate a few more questions, share a little bit more about the position, and field their most pressing questions.

The answers to our screening question tell us who to call first. If we’re lucky enough to get a response that indicates this candidate has high potential, we schedule their call right away. If they’re a great match for our job, they might also be a great match for other employer’s jobs. We don’t want to risk losing them because we didn’t respond quickly enough.

During the first 15 minutes of our 30-minute screening call, we start by digging into their response. We ask as many follow-up questions as we can fit:

  • How long did this work take?
  • Did you lead it or were you working under someone else’s leadership?
  • Had you ever done this kind of work before?
  • What made this project different?
  • How did you learn how to do this work?
  • What did you find challenging about the work?

We’ll often send the candidate some of these questions ahead of time. This gives them a chance to prepare. That improves the quality of their answers during our initial 15-minute discussion.

Because we asked the question when they first applied, we can have a more focused discussion during our initial call. We leave that call with a deeper understanding of the applicant’s experience. That understanding helps us decide how to continue with interviews.

The screening question aids in self-selection

Sometimes, we get an application without an answer to the screening question. Often it’s because the application submission tool or the recruitment site won’t let them add a customized message to their application. (We’re shocked at how many job sites refuse to let applicants provide custom information to potential employers.)

Or maybe the candidate didn’t see the request for the information? We could have accidentally buried the request in the submission instructions. Because it’s not something employers commonly ask for, the applicant missed it.

If we get an application without an answer, we email and ask for it. Most of the time, we get back something that is quite helpful.

However, there are instances where we won’t get an answer, no matter how often we ask. These applicants don’t have the experience we’re seeking and therefore can’t answer the question. They might be an awesome UX professional, but they’re not the right person for our job.

In these instances, we send them a nice thank you, explaining that we were looking for someone with more experience. If it turns out they have the experience they’re looking for, we invite them to reach back out to us.

Those applicants that don’t have a response—or don’t have an answer that matches what we’re seeking—have eliminated themselves from our process. At every stage of the hiring process, we want to focus only on the candidates with the highest potential. The applicants without a great answer are telling us they aren’t right, even though they might have had an impressive résumé or portfolio.

A very powerful, yet simple tool

We got the idea of the screening question from Lou Adler, who invented the process he calls Performance-based Hiring. We’ve since adapted the question for our own use when hiring UX Professionals.

It’s delightful when we get a fantastic answer from an applicant. They are so proud of what they’ve accomplished. We can start our interview process by celebrating that accomplishment with them. The entire tenor of the hiring process starts upbeat and fun, because they get a chance to shine as we learn more about them.

Today’s hiring environment is more competitive than ever. There aren’t enough qualified UX professionals to fill all the available jobs. We need a hiring process that will quickly identify those applicants with the highest potential, so we can act quickly and get to an offer if they’re the right person for the job. The screening question is a simple tool that gives us the power to do just that.

UX Hiring: The Performance Profile is a Game Changer

March 9, 2020

by: Jared M. Spool

After all these years, it still amazes me how much a single document can improve the teams we build, and the products and services our teams deliver. That single document is a performance profile and it’s a game changer.

The idea of the performance profile came from the recruiter Lou Adler. I first read about it in his book, Hire with Your Head, which is where you’ll find the best description of his thoughtfully-designed Performance-based Hiring approach.

The idea is simple: get the team together and describe what the work will be like for their new team member. What will they accomplish in their first year? What will the work environment be like for them?

At first, it’s unlikely the team members will agree. Yet, as they discuss and come to a consensus, they’ll develop a shared understanding of what their new teammate will face. That shared understanding improves the entire hiring process. And it all gets documented in the performance profile.

Solves problems we didn’t realize we had

The first time a hiring manager creates a performance profile and goes through the Performance-based Hiring approach, they come out stunned at how much more effective it is. Going through the process makes it easy to see how horribly ineffective their old process was.

They now realize how many highly-qualified candidates they had been pushing away without even realizing it, because their job ad didn’t clearly say what work the team needed the new person to do. With their improved process, they get applications from candidates who are far more qualified than those they’d seen in the past.

They also now realize how slow their previous hiring process was. By establishing, up front, a clear understanding of what makes a great candidate, their new hiring gets to an offer much faster.

The Performance-based Hiring process removes much of the stress out of hiring. With a detailed understanding of the position and what it will require, those endless theoretical discussions of what makes a great UX professional fade away. Instead, the hiring team can quickly focus on each candidate’s comparable experience.

Hiring managers realize they’d been making it harder on themselves, because they couldn’t see the problems in their previous process. Once they adopt the Performance-based Hiring approach, they can clearly see the difference.

Capturing shared understanding of the job

A performance profile is a job description on steroids. It’s a detailed document that tends to run five to six pages long. Of course, the length isn’t what’s important. It needs to be as long as necessary to communicate the job clearly.

What’s important is what the performance profile contains. The hiring team uses it to capture an in-depth look at what they can expect their newest team member to accomplish and the environment that team member will be working in.

The performance profile is a type of design deliverable, just like a persona description or a journey map. In the case of the performance profile, it’s capturing the team’s shared understanding of the new job. And like any great design deliverable, it’s the discussion and alignment that goes into it that is important.

Our performance profiles have five sections, each make up a kind of framework for thinking about the position we’re trying to fill:

Section #1: The position summary

These two or three paragraphs describe, in high-level terms, what this new person will bring to the team. We describe the good things the team will deliver because we’ve hired someone great in this position. If this is the only section someone reads, that reader will learn why the team believes this position is essential to fill right now.

Section #2: The position objectives

This section describes what the new hire will accomplish in their first year. This is a meaty section, often describing five to eight critical objectives.

For example, if we are hiring someone to oversee the design and deployment of a new design system, our objectives might be:

  • Conduct a UI component inventory
  • Get organizational buy-in for a design system project
  • Choose two pilot projects for the first design system rollout
  • Create and document the initial set of components for the first rollout
  • Work with pilot project teams to integrate new components into their next releases

An image of Position Objectives with detailed bullets for Objective #1: Creat A UI Inventory and Objective #2: Get Organizational Buy-in for A Design System Project as well as a timeline for each of these objectives to be completed by the new hire.Example above shows what Position Objectives look like.

For each objective, we describe what we think the steps are. (This becomes the outline of each candidate’s comparable experience we’ll be looking to identify.)

The position objectives tend to be the largest section of the document. We want to supply enough detail so that it’s obvious to every reader what is expected of our new team member.

We’ve found this section can be difficult to write. We use exercises, like The Thank You Note technique to help get things started. (We also got this from Lou Adler.)

It’s a quick sketch of what the objectives could look like. Once everyone agrees on what we’re thanking our future new hire for, writing the objectives becomes much easier. The team just fleshes out the details.

Section #3: The organizational structure

Here we describe where the new person will be in the organization. It’s usually only one or two paragraphs, listing who they’ll report to and who they’ll work with to accomplish their objectives. We can use this paragraph to inform who should be involved in the hiring process. Everyone on this list should have input into the performance profile and probably have a role in interviewing the candidates.

Section #4: Situational needs and challenges

This section describes the hard truths of the job. What does the work environment demand of the person who will fill this position? What will make this job challenging?

We list (as politically carefully as possible), all the things that make the job easy and all the conditions that make it challenging. And, yes, we describe how organizational politics will affect the work.

This can be a hard section to write. We want to be as honest about this as possible.

An image of Situational Needs and Challenges with a brief company history and detailed Technological Needs and Challenges for the company and detailed Team Structure Needs and Challenges for the company.Example above shows Situational Needs and Challenges.

It’s important that we identify challenges. In interviews, we’ll want to explore how candidates have dealt with similar challenges. We need to know what comparable experience to look for.

Eventually, our final candidates will read the performance profile. We want them to understand what they are getting into, so there are no surprises on their first day of work.

Hiring managers are often concerned that, if they are too honest, they’ll scare these candidates away. I’ve always been surprised how many highly-seasoned candidates tell us they loved this honesty. More importantly, those candidates could then share stories on how they encountered similar challenges in their previous work experience, which gave us confidence they’d handle our challenges well.

Section #5: Basic Requirements

This is where we put in the basic, non-negotiable requirements for this position. Does it require reporting to work in a particular location, or is working remotely a possibility? Will there be travel associated with the work? Does the new hire need to be a citizen or have a security clearance?

It’s typically a short section that ensures we know what questions to ask up front, so we don’t waste anyone’s time.

The performance profile becomes the basis of hiring

A performance profile gives a hiring team new superpowers.

The hiring team will use the objectives and the situational needs to write a very compelling job ad. That ad will attract an improved set of highly-qualified candidates.

The performance profile also makes interviewing much less stressful for the team. We assign each interviewer their own objectives. Because they have their own objective, they can dive deep into the specifics.

For example, the interviewer assigned the objective “creating a UI component library” can spend their entire interview just talking about how the candidate has done that in the past. Other interviewers cover other objectives, so each interviewer can dive deep into learning what skills, knowledge, and experience on just one topic.

The interviewers can use their interviewing time exploring every nook and cranny of the candidate’s previous work. They’ll emerge with detailed notes full of evidence describing how each candidate achieved their past accomplishments.

The performance profile also helps us hire people who are earlier in their career and don’t have many accomplishments under their belt. In the objectives, we focus on what the new hire will need to learn once they arrive. We can use that information to uncover how each candidate has learned similarly challenging skills and techniques in the past.

Solidifying our partnership with top candidates

When we’re writing the performance profile, it’s top-of-mind that we’ll eventually share the document with our top candidates. Any candidates who make it through the first round of in-depth interviews (the ones where we explore each objective) will get a copy of the performance profile to read. We’ve seen several benefits from sharing the document with our top candidates.

First, they can see what we’re looking for. Maybe we were smart enough to ask all the right questions, but there’s a chance we missed something important.

Hiring isn’t a gauntlet of tests that each candidate has to run through to prove their worthiness. (Well, it seems to be in some places, but it shouldn’t be.)

A smart hiring process is a partnership between the candidates and the interviewing team. The goal of that partnership is to surface all of the comparable evidence that the candidate can do the job.

If our previous interviews haven’t uncovered something important, the candidate will discover that when they review the objectives. In subsequent interviews, they can bring that evidence to the surface, so the team can grow their understanding of how qualified the candidate is.

Second, after reading through the profile, we’ve had candidates withdraw from the process. They didn’t withdraw because they were somehow scared away from the position.

Instead, they withdrew because they now had a better understanding of what we needed. One candidate gave us this reason: “I can see exactly what you’re looking for, and it’s a good opportunity for someone. It’s just not where I see my career going at this point.”

That’s a fantastic thing to learn before we give them a job offer. Much better than if they’d accepted our offer and learned about it after they had started.

By sharing the performance profile with each top candidate, they now know exactly what we need from a new team member. Those that stay in the interview process are now committing to the position, because it’s the right thing for their career.

Getting to an offer faster

A well-crafted performance profile reduces the time it takes to identify a highly-qualified candidate. Because we’re confident that candidate can do the job, we can make them an offer quickly.

In today’s market, where every organization is competing for the same small pool of UX professionals, it’s important to act quickly. If the hiring process is delayed in any way, the chance that a great candidate will get swept up by a competing organization increases dramatically. Time is critical.

The performance profile is our definition of what we need. As soon as we meet someone who matches that profile, we make them an offer, even if other candidates are in the pipeline. Hesitating can cost us the candidate, so using it to speed us through our hiring process gives us a great advantage.

Getting to an offer faster also means having someone start the work faster. After all, we’re not hiring because it’s just a fun thing to do. We’ve got work to get done.

And because the hiring profile helped us identify a professional with the right comparable experience, they already know what to do. They come prepared on day one to dive into the work and hit the ground running.

The performance profile is a game changer.

It’s amazing how a little document can dramatically improve our hiring process.

In essence, we’re creating a user manual for the new position. We’re capturing what we need from our new teammate in that user manual. We then assess the qualifications of every candidate against that user manual. We make an offer to the first person who matches what we’ve described in the manual.

It’s hard to break old habits, and this is no exception. The first time hiring managers sit down to write a performance profile, they usually struggle with it.

Yet, persistence is key here. After using a performance profile for a few positions, it becomes substantially easier.

That’s because we’re thinking about the positions we want to fill in a new way. We’re starting with the end in mind. As Lou Adler says, we’re now hiring for year one, not day one.

And that’s what will improve our team’s capabilities to deliver better-designed products and services.

What Proactive UX Research Looks Like

February 20, 2020

by: Jared M. Spool

Proactive UX research anticipates the critical user experience decisions that a team faces. The team’s UX research effort uncovers sound findings and insights to ensure they make the best possible decisions for their users and customers.

This is in contrast to how most teams conduct their UX research today. Most teams react to questions that arise during the design process. Can the users successfully use the thing we are building? Have we designed this thing to meet their expectations?

These are important questions to answer. Teams often answer them through validation techniques, such as usability testing. However, they focus the team on one particular aspect of design: making sure the team delivers a solution that works well.

Of course, the team does need to deliver a well-executed solution to the users’ problem. And having a rigorous usability testing program will uncover where their execution isn’t working. It gives the team a chance to fix any identified issues before release.

However, these questions, and the methods teams use to answer them, only touch the surface of the users’ experiences. They focus on smoothing out the experience of a particular solution, whether it’s the best solution or not.

The most critical decisions happen before most research

It’s not unusual for a team, during their usability testing efforts, to uncover that a designed feature is the wrong approach to solve their users’ problem. Unfortunately, it’s likely too late to make dramatic changes, such as solving the problem in a completely different way. The course of action was set into motion long ago, and the team is now too far along to rethink the entire solution without incurring potentially heavy financial and political costs.

Choosing the right solutions to the users’ problems are highly critical decisions. These decisions require understanding the problems in-depth, and then evaluating multiple alternatives to pick the best-fit solutions.

The reactive UX research techniques teams employ, do not help them make these critical decisions. The important information from reactive research comes long after these decisions have been set in stone. Even when everyone can clearly see that they’d made a wrong choice, the team is lacking enough resources or political capital to roll the work back and start over.

Often, when these critical decisions are made, the UX team isn’t consulted. The decisions are made when the organization’s leadership sets its strategy, or during the impromptu horse-trading that happens when the product leadership formulates its roadmaps.

Even if there was UX research available to suggest a better direction for these critical decisions, the people making the decisions didn’t have access to that information. They subsequently made what they believed was the best decision, not realizing that what they didn’t know would come back to bite them later.

Proactive UX research gets in front of key decisions

Proactive research anticipates the information needed for the people making these critical decisions. Proactive research provides a deep understanding of the users’ problems, to guide the decision-makers to the right solutions. To make the right decisions, those decision-makers need to understand these problems in-depth, not at the surface level that reactive UX research typically provides.

The questions proactive UX research answers are different than those answered by reactive research.

  • What are the users trying to accomplish?
  • What problems prevent users from accomplishing their goals?
  • What does each problem look like?
  • What is the sequence of events that lead up to each problem?
  • Who are the users who run into each problem?
  • Do some users experience the problems differently from others?
  • What happens when these problems get solved?
  • How are users currently trying to solve each problem?
  • What happens if a problem doesn’t get solved?
  • What are the downstream effects when a problem isn’t solved?

The team uses the answers gathered from this research to paint a solid picture of the problem. They are staying away from potential solutions. Instead, they work hard to become the world’s foremost experts on every aspect of the problems their users encounter.

It is research like this that avoids the trap of copying competitor’s features without understanding what problems they’re solving. It’s not unusual for proactive UX research to bring forward an understanding of user problems that no other competitor is even aware of, let alone solving. It opens the door to delivering market-leading products and services well ahead of anyone else.

Proactive UX research requires growing research maturity

When we see teams actively engaging in proactive UX research, we see them using a wide variety of sophisticated research techniques indicative of a mature UX research practice. They use ethnographic techniques from in-the-field observations, (often called contextual inquiry or “deep hanging out”) to diary studies.

These don’t remove the need for reactive validation techniques, such as usability testing. They are still essential when the team needs to focus on whether a user can or can’t use the design. The reactive techniques help the team identify and remove obstacles in the design to smooth the interaction and experience of the user. But these techniques assume the implementation is the right solution.

Alternatively, proactive techniques are more exploratory. The team may not have a specific design to study. Instead, the researchers are observing the people who might use a future product or service, in whatever situations they’re in.

These future users may not have a product to use today. Instead, they are just living their lives and doing their work. During the research, the team is taking note of what’s happening, looking for patterns that suggest obstacles that a future product or service would overcome.

An example: managing store inventory

Let’s say a team is watching retail service workers during the day-to-day operation of their stores or businesses. The team’s goal is to learn about any problems the team could eventually deliver solutions for.

In their research, they might observe that there’s confusion around how inventory is managed at several stores. Digging a little deeper, teams might realize that every store has a different approach to tracking and managing their own inventory. These variations are creating problems with bookkeeping and keeping popular items in stock.

The team will then try to answer specific questions about these problems, to really get a solid understanding of what’s happening in the stores.

  • What are the service workers trying to accomplish when they are managing the inventory?
  • What are the business’s goals of managing the inventory correctly?
  • What does it look like when inventory is managed incorrectly?
  • What is the sequence of events that lead up to the inventory problems?
  • Who are the people who either cause or are affected by the inventory issues?
  • How do each of these people experience the inventory issues?
  • What did it look like when the inventory was managed correctly?
  • How are the problems with the inventory remedied after they’re discovered?
  • What happens if nobody discovers or fixes the inventory problems?

These questions will lead to other questions. As they research, the team will become deep experts in these problems. They’ll learn all the nuances and subtleties of how it manifests and what causes it. It’s with this deep knowledge that they can return their desks and start crafting potential solutions for their users.

Proactive UX research pulls back the lens

We can think of reactive UX research as a microscope that zooms into a very specific part of the design and how users interact with it. It’s valuable to look through that lens, but it leaves out a big part of the world. Only using reactive UX research will prevent the team from delivering improved designs.

To deliver those designs, the team needs to pull back the lens and take in a wider view. They need to look at the entire user experience. And they need to focus on problems before they dive into solutions.

This is critical if we’re to ensure that the most important design decisions—the decisions that lock us into the specific solutions we’re delivering—are made by people who truly understand the problem. That’s where proactive UX research comes in.

When we can research our users ahead of the critical decisions, we can ensure we’re choosing the right solutions. That’s how we’ll drive our team to deliver better-designed products and services.

The UX Strategy of Hiring Juniors Over Seniors

February 5, 2020

by: Jared M. Spool

“That was the big mistake we made.” I was listening to the new Senior Director of User Experience at a Fortune 200 company. They were in their 4th month as Senior Director, having inherited the team from the person who had started the UX group.

The Senior Director had just finished up a meeting with all of the group’s 160 UX professionals. Practically everyone complained about finding their daily work challenging.

Some team members were so frustrated that they were strongly considering leaving. Many already have. The team was losing great people.

“We’re only hiring the best and brightest.”

The Senior Director’s predecessor had a philosophy of only hiring “the best and brightest” UX designers, researchers, and content specialists. Using this philosophy, the team that they built was amazing. Some of the best UX folks in the world were on this team. It was a who’s who of amazingly talented individuals.

The predecessor had grown the team out of just a small handful of mainly visual designers. The predecessor revamped the team, hiring leaders in user research, interaction design, information architecture, content strategy, and other expertise that was new to the company.

These folks happily joined the team, rolled up their sleeves, and set out to work. They built a design process, established basic tools, and integrated design practice into each major project.

The problems of hiring only experienced UX professionals

The Senior Director’s predecessor had built a great team. Yet, the hiring philosophy was holding these talented professionals back. It was preventing them from putting into action the exact talents they had been hired for.

The Senior Director told me that there were plenty of big challenges for the team to tackle. And, the team had the skills and experience to take on this important work.

Yet, the Director couldn’t assign any team members to these challenges. Their plates were full with day-to-day production work.

The predecessor had only hired team members with lots of experience. There weren’t any junior team members to take over this production work and free up their senior teammates to solve the bigger challenges.

For the existing team members, the daily work was no longer interesting. They were open for organizations to poach them with promises of more challenging work. Some team members jumped at these opportunities.

Bringing in juniors to take over the production work

It’s tempting, when we’re growing a new UX group, to do exactly what the Senior Director’s predecessor had done. It’s natural for a new manager to approach launching their new UX group by recruiting highly-skilled and experienced team members.

The first few team members hired need to have the skills to do the work effectively. This will get the UX work started.

However, it quickly becomes important to start hiring individuals who are earlier in their careers. Early-career UX folks will have fewer skills, knowledge, and experience than the initial team members hired. They might be right out of school, or they might have just a few years of narrow working experience.

These new team members wouldn’t be equal peers to the existing team. They’d join as apprentices to the more experienced folks.

The rookies would take over the work that’s become routine for the existing team. To the new rookies, it’s challenging work and a growth opportunity. They’ll learn new skills and gain new experiences, even though the work may seem routine and unchallenging for their more senior teammates.

Transitioning seniors to bigger challenges

Once the rookie team members learn how to do the work, the more senior team members can move onto those new, harder challenges. These challenges can be focused on growing the UX capacity in the organization. They can be bringing better user research to the decision-making process. They can be growing the overall design practice, pushing new boundaries of what’s possible.

By hiring more junior UX team members, the team grows without losing the capability to do the day-to-day work. Senior team members can put in the time and dedication needed to overcome hard challenges, while more junior team members handle day-to-day production work.

The Senior Director I talked to was stuck because their predecessor didn’t leave them with a path to grow the team. As a result, it’ll be difficult for the current director to keep their team, many of whom were itchy to get out of work they find routine and boring. It will be hard to bring on enough junior talent quickly enough to take over that work.

Balancing juniors and seniors is part of our UX Strategy

Being intentional about hiring and team growth are essential for a successful UX strategy. If we pick the wrong strategy, we’ll hold our team back.

However, if we pick the right strategy, our team will grow the value of design throughout our organization. Hiring and team growth are critical factors to delivering better-designed products and services.

UX Hiring: Let’s Talk About Comparable Experience

January 30, 2020

by: Jared M. Spool

UX leaders need an effective hiring approach to fill a position and build their team. If they take an ineffective approach, they risk pushing away highly-quality candidates, which makes it harder to fill the positions. And if they hire someone who isn’t capable of doing the work, because they’ve hired the wrong person, they create problems down the road as the team tries to achieve its goals.

As we’ve worked with user experience leaders to build up their team’s UX capabilities, we’ve noticed there are two approaches to hiring. Of these two approaches, we’ve found that one is far more effective in the long run.

Interestingly, the more effective approach isn’t the one most UX leaders start with. We only see it among teams with seasoned UX leaders. Leaders who have learned the hard way that how they hire matters, when it comes to building a team that will drive their organization to deliver better-designed products and services.

One approach: A quest for a perfect UX professional

Many teams approach hiring as a quest to find the ideal UX professional, whether they’re hiring a UX designer, a researcher, a UX writer, or a content specialist. Their hiring process eliminates candidates through tests and challenges, until there’s only one or two left. It can seem like their hiring process was inspired by The Bachelorette reality TV show.

On the surface, this feels like the right way to hire. After all, you want your team to be made up of the “best and brightest.” Every new addition should raise the average capability of the team. It feels like the right process should be to evaluate all the candidates for their individual talents, then make an offer to the winner.

‘The ideal UX professional’

It’s easy to identify teams that hire using this Bachelorette approach. They talk about the designer, researcher, or writer in terms of some ideal. Ask any member of the team what they’re looking for in a candidate, and they’ll describe qualities that are generic across all different skills.

For example, a team seeking a UX designer would talk in terms of an ideal UX designer. They’ll list out qualities that all ideal designers should possess. They should be ideal problem solvers, have a good eye, be masters of their tools, know how to sell their ideas, and so on.

Similarly, the ideal UX researcher should know how to conduct a variety of different styles of research, know how to plan studies, have the skills to sell the results to the team, and so on.

And the ideal UX writer should be both clever and smart with their writing. They should be skilled at choosing the right voice and tone. They must be skilled at knowing where the right copy needs to go. And they must work smartly in an agile setting, where their content might be for things that change frequently.

You get the idea. After the team identifies the role they’re trying to fill, they seek candidates who are as close as possible to this ideal version of that role. Of course, nobody’s perfect, but that won’t stop the team from trying to get close to perfect with their next addition.

The traps of UX perfection

As I said, on the surface, this feels like the right way to hire. What could be wrong with it? Well, lots, actually. This approach turns the hiring process into a Greco-Roman competition-of-the-fittest. Think of it as something like America’s Got UX Talent.

The team focuses their hiring process on tests and challenges. What kinds of questions should we ask to uncover who is a real UX professional and who is faking it? What kind of exercises can we give the candidates to eliminate those that aren’t good enough?

They choose to ask theoretical questions of each candidate, like: What’s your definition of great design? What’s a website or app you’d like to redesign and why? What’s your design process?

They approach these questions as if there’s one right answer. (Sometimes, they will tell the candidate there’s no wrong answer. That may be true, but there are definitely answers that will end up disqualifying a candidate.)

I’ve talked with many teams that have adopted this approach to hiring. It’s rare for those team members evaluating the candidates to have actually shared and discussed the qualities that they believe make a great UX professional amongst themselves.

Each team member has a different picture of what an ideal candidate should be, but they probably haven’t talked about it with others. That means each team member is judging each candidate on different—often conflicting—criteria.

There are rare cases when team members have discussed the ideal qualities. That conversation almost always surfaces a big difference in opinion. Some think designers should be more visual, while others believe it’s more of a leadership role.

They often don’t reconcile these differences, because it’s based on opinions and personal experience. That forces the reconciliation to happen after every high-potential candidate is interviewed.

It takes a long time to find the perfect candidate

The biggest downside of this approach is how long it takes. Because the team is looking for the best possible candidate, they can’t stop until they’ve talked to every applicant. If they get a large number of applications, it takes quite a while to screen and interview everyone. Stop too soon and you may miss someone better in the pipeline.

Add that to the reconciliation time when a candidate has high potential. The team must discuss what makes an ideal role as they evaluate each candidate’s potential. Each team member’s opinions must be hashed out. This can happen multiple times during the hiring process, slowing everything down.

By searching for an ideal UX professional, the team must look at the position’s maximum qualifications. Those qualifications describe the ideal new hire.

Yet, there could be many candidates who have the minimum qualifications to do the job. But, in the pursuit of UX perfection, those candidates will get pushed aside if it’s possible there’s someone more qualified in the applicant pool.

The other approach: Searching for comparable experience

There’s an alternative to the Bachelorette hiring approach. What makes it different is the team starts by establishing the minimum qualifications to do the job.

Those minimum qualifications may be quite high. The team doesn’t have to lower their standards. They only have to define the minimum of what the new team member will need to do a great job.

After the team has identified the minimum qualifications, they can start looking at each candidate with a different lens than the Bachelorette approach. They can look for each candidate’s comparable experience.

Comparable experience is what a candidate has done in their career to suggest they can do the job. It doesn’t look at abstract knowledge about design, research, or writing. There are no tests or exercises.

Instead, using the comparable experience approach, interviewers partner with each candidate to explore the journey of that candidate’s career. What evidence is there that this person has done, in their current or past work, anything close to what they’ll do when they get here?

The first step: What will our new hire do during their first year?

This approach requires some work from the team before they advertise the position. In contrast, a team using the Bachelorette approach starts advertising the position right away.

In the comparable experience approach, the team must identify what the new hire will do after they’ve arrived. This can be difficult for some teams to identify. Do they need someone to do more of the work the rest of the team is currently doing? Or do they need someone who will do something new and different, to extend the team’s capabilities?

For example, let’s look at a team hiring a senior UX designer to lead a design system rollout to the organization’s 30 product teams. It may take a year or more to get this rollout moving.

What is the work the UX design system lead would do in that first year? They might inventory UI components across the products to look for variations and identify a common component language. They’ll need to understand the political landscape of working with different teams, each with their own schedules and deadlines. They’ll need to sell the idea and help attract teams to work on a pilot rollout. They’ll need to put a governance system together for controlling contributions to the component library and establish brand guidelines.

This is a big job. Ideally, the team wants to hire someone who has done all of these things before. They want someone whose past work has comparable experience.

Every new position may be different from a past hires

Our imaginary team will likely only need one person to lead their new design system. But they may need additional people to work on the design system with that project lead. The comparable experience for those candidates will be different from the UX design system leader’s comparable experience.

What would the first year’s work for those new design system project members look like? Well, they might be the ones to do the detailed work of the UI component inventory. They would document each component and establish a priority of implementation. They’ll need to work with the developers to identify the specific behaviors and interactions of each component. They’ll be responsible for working with the product teams to learn about edge cases and exceptions that individual products may need.

The day-to-day work of each newly-hired position will be quite different from each other. Therefore, for each position, the hiring team needs to explore different comparable experiences.

Interviews become about collecting evidence

When hiring based on comparable experience, the interviewer’s role changes. They are no longer a judge and jury for whether this person is the best of the candidate pool. Instead, they are partnering with the candidate to uncover any demonstrable evidence that they have the desired comparable experience.

The nature of the interviewer’s questions change. Behavioral interviewing questions are more effective here than testing the candidate on their theoretical knowledge.

For example, when hiring that UX design system lead, the team might divide up the interview responsibility. One interviewer could go deep on the UI component inventory.

The interviewer can ask “Tell me about a time you created a UI component inventory for 15 or more products.” After the candidate shares an initial project description, the interviewer and candidate can work together to surface more details.

How long did it take? Who was involved? What was the most challenging part of the project? How did you overcome that challenge? What were the deliverables? What lessons did you learn from this project?

As each interviewer collects evidence, they’re matching it up to the minimum qualifications the team initially established for the position. When they find a candidate who has all the established minimum qualifications, they are ready to make an offer.

For early-career hires, we look at learning experience

When a team uses the Bachelorette approach, they leave behind less experienced UX professionals. Those folks who are right out of school or early in their career suffer the most. The less qualified applicants won’t meet any standards that are looking for the best and brightest.

However, when the team is defining the minimum requirements for a comparable experience approach, they can lower those minimums to bring on less experienced folks. This is perfect for filling day-to-day production positions, where the work is ideal for someone just starting out.

For these positions, interviewers can focus on the candidate’s learning experience. Tell me about a time you had to learn a new design technique. How did you learn it? How long did it take? Who did you learn from? What was something that was challenging to master? How did you learn to do it? What lessons about learning new things did you discover?

The evidence collection process doesn’t change. It adapts to meet every position where it needs to be.

More time up front, less time to making an offer

The biggest downside of the comparable experience approach is it requires the team to spend much more time defining the position. The team leadership will need to align on what the candidate will do upon arrival.

This means planning ahead an entire year. That planning can be hard for teams that work reactively. They are not sure how to look that far out. (It’s not impossible. It just takes practice.)

All this upfront planning takes time. It can require a few weeks of meetings and writing to get a solid description of what the new hire will do. Part of that process is defining the minimum requirements to match the evidence against. (This gets faster the more teams use this approach.)

It’s an investment. But, hiring a new team member is the most important way to grow capability. It’s worth the heavy investment.

That investment pays off after interviewing starts. After each candidate’s interview round, the interviewers can easily come together and share the evidence they collected.

The moment they determine that a candidate meets all the minimum requirements, the hiring manager can make an offer. No need to interview every candidate in the pool. This can speed the time to an offer dramatically.

Comparable Experience is a more energizing approach to hiring

When we studied teams using either of these approaches, we noticed something very interesting. The teams who used the comparable experience approach were far more energized about their hiring process than teams who used the Bachelorette approach to find an ideal candidate.

The teams on a quest to find the perfect UX professionals found their process exhausting. These teams saw hiring as a burden. They would put it off until the last possible moment, creating problems and compromising on who they hired.

That exhaustion also drags out the hiring process for the candidates, who can see that the team’s not excited about hiring someone. This pushes away the best candidates, and, ironically, makes hiring someone take even longer.

The teams using the comparable experience approach loved the process. They enjoyed being a partner with each candidate, trying to draw out what those candidates brought to the process. They felt like they really got to know the people they interviewed. It feels more like a fun research job than an administrative burden.

That energy and excitement translates into a faster hiring process. Teams are excited to dive in and ready to surface someone they think meets all the requirements. They get to an offer quicker.

Comparable Experience produces better teams in the long run

The proof of which approach is better comes after their new person joins the team. A team that chose the comparable experience approach has done the hard work of figuring out what the job is. Their new hire (and everyone that person will work with) now has a clear understanding of what they should be doing on their first day.

Even more important, because that person was hired primarily based on their experience of having done similar work before, they likely know how to get started. They just need to look to what it is about the new environment that will change things up.

Teams that pick the Bachelorette approach still have the hard work of figuring out what that person will do. Yet, they often postpone that until after the candidate accepted the offer. That means most of the team isn’t prepared (and sometimes even the candidate doesn’t know what they’ll be doing.)

New hires that don’t know what they should be doing are more likely to leave in their first year. This creates the vicious cycle of forcing the team to do even more hiring.

We’ve found that the teams that use the comparable experience approach grow their overall UX capacity faster than teams that try to find the perfect UX professional with every new hire. They have higher retention and their teams deliver increasingly better designs.

Hiring is the most important thing a UX design leader can do. It’s important to choose the most effective approach. That’s an approach that focuses on a candidate’s comparable experience.

Your Necessary First Step to Creating Powerful UX Metrics

January 27, 2020

by: Jared M. Spool

When an organization's leadership values design, it falls on UX design leaders to show how good design is continuing to deliver that value. And in organizations where the executive leadership doesn’t yet value design, UX team leaders need to show how much poor UX design is costing the organization.

Existing metrics probably won’t work

Design leaders who aren’t thinking strategically fall into a trap. When asked for some sort of UX metrics, they'll use data and metrics the organization is already collecting.

Their organization is likely already measuring activity of their users, such as page views, button clicks, bounce rate, or conversion rate. They are likely collecting data from attitudinal surveys, like Net Promoter Score or customer satisfaction measures.

It’s tempting to use these measures, because their organizations are already collecting them. Unfortunately, these measures are usually unhelpful in telling the story of how the design benefits the users and the organization.

Knowing that a purchase was made doesn’t tell us anything about people coming to the site who aren’t quite ready to purchase. Knowing that someone said they might recommend the company doesn’t tell us if they felt they had no other choices for that company’s services.

It’s very tempting to use these metrics, but doing so frequently results in disappointment. That’s because changes in the data are often unrelated to the quality of the experience. And changes in the experience don’t result in changes in the data.

Existing data rarely tells the story the design leaders need to tell. These metrics measure, at best, outputs.

These UX metrics show activity in the design. They may occasionally show improvements in a few business metrics such as sales revenues or onboarding rates. However, the metrics won’t likely show if an improved design actually makes a difference to the customers or users.

Identifying UX metrics that tell the team’s story

In the workshop, we dive deep into better metrics. UX metrics that are mapped directly to what happens when we deliver well-designed products and services.

The first step is to determine the user experience outcomes the team is shooting for. Each UX outcome answers the question If we deliver a great design, how does it improve someone’s life?

The UX outcome is the end state we’re trying to achieve. Once we know our UX outcome, we can create key metrics detailing our journey getting there.

We can use our UX outcomes to choose the most powerful UX metrics. There are several categories of metrics we choose from. UX Success Metrics tell us the exact moment we’ve achieved our UX outcome. We use these metrics to report our accomplishments to our executives, in terms that show how our customers and users benefit from what we’ve delivered.

We can use Problem-Value Metrics to demonstrate how much poor design is costing our organization today. We’ll use the high costs of support and lost sales to motivate our executives into taking action, even when they don’t yet realize a better user experience will be the solution.

We’ll use Progress Metrics to put our product roadmap into perspective. These metrics demonstrate the progress tackling each roadmap item brings us towards our UX outcomes.

The necessary first step to creating powerful UX metrics

Before we can identify the right UX success, problem-value, and progress metrics, we must know what our key UX outcomes are. And the only way to know what our UX outcomes are is to spend serious time learning about our users and their challenges. For most teams, this will require they increase their UX research maturity.

The UX team’s research maturity drives how well the product and service teams understand their users and what they’re trying to accomplish. Teams without more mature research practices can’t get to the essential insights that drive that understanding.

If these teams are doing any UX research at all, it’s probably constrained to usability testing and surveys. Unfortunately, to craft the UX metrics that will have the power to persuade the executives into action, teams have to move beyond these starter methods.

These teams will need strategies to move to more proactive research. They’ll use techniques, like field studies and other ethnographic approaches, to dive deep into the lives and challenges of the people who use their products and services.

With a deep understanding of these challenges, UX design leaders easily gain alignment on the right UX outcomes. That alignment drives the identification of the key success, problem-value, and progress metrics the team will use. Now, design leaders have a way to communicate the increasing value of their teams’ efforts.

Building an Integrated Qualitative and Quantitative User Research Capability

January 22, 2020

by: Jared M. Spool

A case study of how one team used quantitative and qualitative data to their advantage.

Sam Nordstrom had a big problem to solve. As a product manager for Intuit’s Quickbooks, Sam had learned that the new feature his team just shipped wasn’t used nearly as much as they’d hoped. He didn’t know why.

When they demoed their new feature, their users told them they loved it and would use it. Everyone agreed the feature offered huge advantages to QuickBooks users. Yet, now that it was out in the world, the users weren’t getting those benefits.

Sam’s team had implemented a new way for QuickBooks users to get their customer invoices paid. The software added a button to invoices labeled Pay Now. When customers pressed the button, the software set up an instant transaction that sent their invoice payment directly to the Quickbooks’ customer.

Early testing showed, when the customers paid this way, the Quickbooks user would get paid substantially sooner than when they used regular invoices. It was a huge advantage to every small business person using the product, as it increased their cash flow.

But users weren’t using it. Sam and his team didn’t know why.

Learning from deep hanging out

Sam and his team visited their users. Intuit has customer visits in their DNA, so this was not a special trip. It was common for the teams at Intuit to visit customers.

Yet, this time, Sam’s team was looking for specific answers. Why weren’t the users taking advantage of the speedy payment feature?

They hung out with several QuickBooks’ users. They watched those users send out their invoices and process their collections.

They saw it was awkward to use the Pay Now feature. Many of their users preferred Gmail to correspond with their customers. The QuickBooks users often had an existing correspondence thread, complete with price quotes and status updates.

The QuickBooks users would invoice their customers by replying with a Gmail message and attaching the invoice PDF. To these users, this made more sense than sending the invoice from within the QuickBooks user interface. But those users didn’t get the Pay Now capability, because saved PDFs can’t have the necessary button.

When users sent an invoice from inside the product, instead of in Gmail, their invoice message was disconnected to other messages in their thread. The users’ customers missed the Quickbooks-sent messages in their inbox, as they had a different ‘from address’ and ‘subject.’ This made collections more difficult.

Learning from deep data dives

Visiting a few users showed the new feature had a clear problem. Yet, Sam’s team wondered how widespread this issue was. Were other users avoiding the new Pay Now feature for the same reasons?

When Sam and his team returned to the office, they dove into the data QuickBooks already collected from their users. How many users were saving invoices as PDFs? It turns out it was a high percentage of regular users.

When those users saved invoice PDFs, were they attaching them to email threads in Gmail? The team asked a bunch more users and, sure enough, many of them were doing just that.

Were the users who were saving PDFs getting payments through the new Pay Now payment system? Their usage data said they weren’t.

Were the users who did get payments through the new payment system also saving PDFs? Rarely.

Their usage data suggested most users were saving PDFs and not using the payment system. More importantly, those users saving PDFs were paid substantially slower than those using the payment system.

Testing a hypothesis

Sam and his team formed a hypothesis: If they could get users to send invoices with a Pay Now button, those users would get paid faster. But how could they do that?

The team developed a Gmail extension that inserted an invoice with a Pay Now button directly into an email reply. They tried the extension out with a few customers and, sure enough, the customers found it easier than saving PDFs, adding them as attachments, and dealing with the collection headaches.

As Sam’s team rolled out the Gmail extension, they watched their usage data. Were users who installed the extension using it? Yes. Did they save fewer PDF invoices? Yes. Were they being paid faster? Yes.

Integrating Qualitative and Quantitative Data

Sam and his team solved their big problem. They created an innovative solution to a hard problem.

The team couldn’t have done it without their data. They formed their deep understanding by hanging out and observing a few customers. They learned how extensive the problem was by diving into the product’s usage data. They observed, in real-time, the changes in the usage data, as they rolled out the fix to the problem.

All of this data—qualitative and quantitative—guided the team to an ideal solution. It told a complete story that drove the team’s problem-solving process.

Sam’s team built a sophisticated approach to user research. They used data strategically, which delivered insight into their problem and its potential solutions. They couldn’t have achieved the improvement as quickly without it.

To deliver better designs, teams need to grow their own qualitative and quantitative data collection capabilities. They need to integrate these efforts into their user research processes. With this expanded capability, they’ll drive their organizations to deliver better-designed products and services.

Shifting Our Team Goals to be UX Outcomes

January 15, 2020

by: Jared M. Spool

It’s common, when the new year rolls around, for teams to think about their goals. What can we hope to accomplish over the next year that will show growth and improvement over the previous year’s efforts?

There are several ways to come up with goals. For example, the leadership of a UX team might pick goals for increasing what their team accomplished during the previous year. They could count their team’s activities, such as the usability tests they conducted or wireframes they delivered. Their new 12-month goal would be to accomplish more of those activities.

However, when a team measures their goals using activities, they are focusing on the outputs of UX research and design efforts. Outputs are necessary, but they are not the end of the game.

Shifting to outcomes instead of outputs

We’ve found that more experienced UX teams steer clear of outputs, instead of focusing on outcomes. While outputs represent the effort and activities of the team’s work, outcomes represent the results they achieved because of that work.

Many teams start their shift to outcomes with business outcomes. How will their UX work improve the business? Could their designs increase new subscriptions or generate more income? If their UX efforts can deliver those improved results, it would certainly be valuable to the organization.

Some teams, however, take it a step further. What if, instead of focusing on how they improve the business, they focused on how their work improves the lives of their users?

The big shift to UX outcomes

A user experience outcome answers the question if we work hard and deliver great designs, how does that improve someone’s life? The person whose life we want to improve might be a customer, a non-paying user, an employee, or even someone who has never heard of us, but benefits because we’ve delivered a great user experience.

An example: Our team at Center Centre – UIE just launched a new job board for UX professionals. We chose UX outcomes for our users of the job board: the hiring manager and the job seeker.

Our UX outcome for the hiring professional is to improve their life by making it easier to identify and screen highly-qualified candidates. We want candidates who come through our board to be a great match for the position, and to clearly identify what it is that makes them such a great match.

For the UX professional job seeker, we want to improve their life by making it easier to locate jobs they’d be highly qualified for. We want potential applicants to understand how the hiring team is passionate about delivering great user experiences, and to make it easier for the applicant to show how their past experiences make them ideal for the position.

Both of these outcomes have driven how we designed the UX Centered Careers job board. It drives our roadmap and all the new features we’re considering. It helps us continue to make our service unique in a crowded industry of job placement services and products.

When we can talk directly to improving someone’s life, we now have a big result to shoot for. We’re connecting the improvement in someone’s life to the reason the product exists. It connects the business objectives with the change we’d like to see as UX professionals.

The best UX outcomes come from research

Some teams find it difficult, at first, to identify a UX outcome. Teams that are very detached from the day-to-day life of their users have trouble imagining a substantive life improvement—one worthy of being their long term objective.

These teams have focused all their research on usability testing specific features, and all their design work crafting wireframes for their product. They rarely, if ever, get to step back to see what really frustrates their product or service’s users.

It’s when teams upgrade to a more mature research practice that UX outcomes become easier to identify. Teams who spend significant time with their users will see many opportunities for improvements. Each of these opportunities are great candidates for their UX outcomes.

When we started the UX Centered Careers project, we had already spent significant time working with both hiring managers and job seekers on their hiring experiences. In our research, we walked through the hiring process on both sides.

We watched teams review applications and evaluate candidates. Similarly, we spent time with job seekers as they were reviewing jobs they were interested in. We could see where the process was frustrating to each side, and could see how a well-designed tool might improve their life. From that, the job board was born.

The best UX outcomes will come from a deep understanding of the users’ current experiences. That deep understanding comes from a mature research practice.

The best UX outcomes make an aspirational story

Everyone loves a great, uplifting story. It’s no different for our products and services. It’s easy to get folks rallied around a big effort when they can see the benefits of their work.

The UX outcomes are a natural starting point for an engaging experience vision. The experience vision tells a story of what it’s like for a user in the future.

As we’ve been working on the job board, we used our aspirational experience vision of the hiring manager and job seeker outcomes to talk about what we would deliver right away, and what we’re planning in the future. The experience vision helped everyone on the team understand the importance of the little things we’re putting into the design, things that will grow into important features down the road.

Teams can use their UX outcomes as the seeds of the story they’ll put into their vision. The experience vision becomes the vehicle to garner buy-in for the UX outcomes from executives, stakeholders, and the UX team’s peers in product management and development.

The best UX outcomes are measurable

One can think of progress toward a UX outcome as a type of marathon race. It takes a long time to get there, with a lot of hard work.

Marathon races have finish lines. An exact moment when the runner has accomplished their goal.

The same is true for a thoughtful UX outcome. There should be a clear moment when everyone can see that the outcome has been realized.

That means the team needs to have a clear understanding of what their UX outcome looks like. They’ve improved someone’s life, but how can they tell? Part of defining the UX outcome is to describe the evidence they’ll observe when the outcome has happened.

The evidence we’ve achieved the outcome often comes from our research. For our UX Centered Careers project, our research clearly showed frustrating, ineffective experiences that hiring managers had. When looking at applicants, it’s often hard for them to tell if the applicant is a clear fit for their open position. We can observe that frustration happening, and, as we build out capabilities in the job board, we can see when that frustration goes away.

Similarly, job seekers often become frustrated because job ads are poorly written. As we create functionality to help hiring managers craft better job ads, we will also see the job seeker frustration disappear.

Because we conducted in-depth research and uncovered substantial frustration in the hiring process for both hiring managers and job seekers, we now can use that frustration as the basis of our UX Success Metric. That’s how we’ll measure how we’ve achieved our UX outcome.

UX outcomes drive great design

Just performing the rituals of design isn’t enough. We need to shift our practice from outputs to outcomes.

For customer-centric organizations, only focusing on the business outcomes won’t suffice. We need to look at how we improve the lives of our customers, and build all of our decisions around that.

That’s what it means to be design driven and customer centered. We’re putting the users’ needs into every decision. And to do that, we need to have strong guidance on how to make those decisions.

Well chosen UX outcomes get the entire team focused on the same goal, heading in the same direction. And that direction is all about making people’s lives better. That’s key to delivering great experiences in our products and services.

Four Articles for a New Year

January 2, 2020

by Jared M. Spool

Design is no longer—if it was ever—just about making stuff look pretty.

In 2019, we saw new progress in our teams’ and stakeholders’ mindsets on the importance of design. For this year-end wrap-up, we’ve picked four of this year’s articles that center on the expanding ways we can look at design, and how it’s important to our organizations.

#1: The Growing Demand for UX Managers

The hot UX job right now is User Experience Manager. It’s a sign that things are changing for the better. UX is growing in importance inside many organizations.

Organizations only need managers when they’ve been growing their design teams. They only grow their teams when they value design.

However, there’s a problem. There aren’t enough experienced UX managers to fill all open positions. Experienced UX managers are often happy where they are. It takes years for new managers to get the requisite experience to manage growing teams.

Continue reading on UIE.com.

#2: UX and CX: Same Language; Different Dialects

We’ve looked closely at high-performance CX and UX teams in dozens of organizations. What we learned was that they uniformly work towards an identical goal. They all want the organization to deliver the best experience for anyone who interacts with their organization’s products or services.

The difference between the CX and UX team is not their mission, but their origin. Because of that difference, they achieve the goal quite differently.

Continue reading on UIE.com.

#3: Understanding the Kano Model – A Tool for Sophisticated Designers

Working with our clients, we’ve seen teams prioritize their work using the Kano Model. They’re constantly monitoring their users’ current basic expectations, to make sure there’s nothing they’re missing. They are always on the lookout for inexpensive ways to add excitement generators. And they use the performance payoff to help understand how much delight they can generate with new features.

Continue reading on UIE.com.

#4: Zooming In and Out of UX Design Resolutions

In UX design, our tools and methods also need to change, depending on which resolution we zoom into. For screen-level UX design work, we created tools like usability testing and form design heuristics, to help us see problems at the screen resolution.

For application/site-wide UX design, we created sitemaps and wireframes. These tools aren’t as useful for screen resolution work, but they’re perfect for application/site-wide work.

For organization-wide UX design, we created design systems, service blueprints, and customer journey maps. Again, these are only of minimal value when we’re working at the lower resolutions.

Continue reading on UIE.com.

Strategies to integrate UX into every level of your organization

It’s not a mistake that these four topics drive many of the discussions we have in every one of our Creating a UX Strategy Playbook workshops. Bring your product and development leadership to the workshop, engage in these discussions, and build your UX strategy together.

We limit every workshop to 24 seats. If you want to bring your team to an upcoming workshop register soon to reserve your seats. Develop your 2020 UX strategy today.

Three UX Articles for Your Holiday Break

December 23, 2019

by Jared M. Spool

As our organization becomes more design mature, we can no longer use a one size fits all approach. We need to adapt specific approaches to different teams and different problems.

As you take a break from the hustle and bustle of the holidays, here are three different approaches to maturing UX in your organization.

#1: Driving Product Teams to be More Design Mature

As our organization’s user experience design leaders, our responsibility goes beyond the UX designers, researchers, and content professionals we work with. We’re also responsible for designs our organization’s product and service teams deliver. If we want to see those teams deliver better-designed products and services, we need them to attain the skills, knowledge, and experience to get there.

Continue reading on UIE.com.

#2: The Experience Vision: A Self-Fulfilling UX Strategy

The easiest way to create an effective experience vision story is to start with the current experience. What makes today’s experience with our product or service frustrating for our users?

Team members immersed in the current experience will do the best. This means the starting point for creating an experience vision is immersive user research. The key is to spend time studying the frustrations we put our users through.

Continue reading on UIE.com.

#3: The Need to Think and Talk like an Executive

Here’s a hard truth user experience design leaders find themselves learning: No one will buy into your UX design ideas if they can’t see how those ideas matter to them.

This is especially true for your organization’s leadership. They need to see how all those great UX design ideas will push forward their top priority, helping the organization. If they can’t see it, they won’t get behind your great ideas.

Within an organization, a design leader can only do so much on their own. At some point, getting executive buy-in becomes a necessity. Design leaders will then need to win over their executives by showing them how their UX design ideas make the organization stronger.

Continue reading on UIE.com.

Growing Our UX Maturity Pushes Beyond What’s Comfortable

December 19, 2019

by Jared M. Spool

In our Creating a UX Strategy Playbook workshops, it’s not unusual for the discussion to start to feel a little bit like therapy. This is a good thing. We’re talking about change and change is hard.

It’s not that the design leaders in the room have to change something about themselves. It’s that they need to push their organization to change. Important changes that will make the organization’s UX design efforts more mature.

The design leaders believe these changes are necessary. They won’t come easy.

This realization is when the design leaders start to feel like they’re in a therapy session. All their fears and issues around confidence start to surface.

It’s good, cathartic discussion. Fortunately, we’ve made the workshop a safe place.

Everyone there is among new friends who are in the same situation. They also have to push their own organizations to change, so they feel the same way.

Imposter Syndrome is a sign we’re doing something right

Design Leaders naturally have imposter syndrome. (Frankly, I believe there are two types of design leaders in the world: Those with imposter syndrome and those that should have more imposter syndrome.) That’s because design leaders are in a situation where they are pushing beyond what’s comfortable.

In our work, there’s a natural force to make what is uncomfortable become comfortable. After doing something that’s uncomfortable multiple times, we start to feel good about it. It becomes comfortable.

We create comfort zones. These are places where we feel confident and empowered about all doing our work.

Yet, when we’re pushing our organization to change, we have to push beyond our comfort zone. We’re pushing into new frontiers that are unknown.

We still have to show our confidence, because, as a design leader, we need everyone around us to think we know what we’re doing, while, deep inside, we believe we don’t. That’s where the imposter syndrome comes from. And it’s a sign we’re doing something right.

Picking UX strategies outside our comfort zone

In the workshop, each design leader chooses a small handful of UX strategies—approaches to growing the maturity of their organization’s UX capabilities. They need to find the right strategies. Ones that will be outside what they are now comfortable with, but not so far outside that they’ll be paralyzed from the discomfort.

To start with, we’ve done the hard work for the design leaders. We’ve identified and collected 130 different UX strategies. Each one has been successful for some design leader somewhere, so we know they work. Having the collection of proven strategies takes a lot of the pressure off.

The design leaders (and the peers they’ve brought along) take those strategies and sort them into three piles: Already done (or doing), Unlikely, and Could do.

The Already done (or doing) pile are changes they’ve already made in their organization. These things are already inside their comfort zone.

The Unlikely pile are the strategies that are too far outside of their comfort zone. The design leader doesn’t have enough confidence to even believe they are possible inside their organization.

That leaves the Could do pile. These are strategies that are possible to accomplish, but definitely outside the comfort zone.

To know which strategies to start with, we ask each design leader to score them on two scales: impact and feasibility. The strategies that will leave the biggest positive dent in their organization’s main initiatives and will be the easiest to implement get scored the highest.

Exploring the UX opportunities just beyond comfort

We encourage the UX design leaders to tackle the highest-scoring UX strategies from our Could do pile first. And because each strategy they’ve chosen in the Could do pile is highly feasible, the design leader feels confident and empowered to push outside what feels comfortable.

Important change can only happen if we leave our comfort zone. Important change is the only way we can push our organization to deliver better-designed products and services.

Strategies for growing our organization’s UX design efforts

At our 2-day Creating a UX Strategy Playbook workshop, we look at every aspect of a solid UX strategy, including how you’ll grow the maturity of design inside your organization. We’ll look at activities that help you find champions, drive human-centered UX outcomes, and increase the design skills of the teams you work with. You’ll choose the strategies that are most feasible, ready to put them into action the day you return to work.

You’ll leave with an action plan that will drive your organization to deliver better-designed products and services immediately. Register today.

Improving How We Design at Scale with Multidisciplinary Teams

December 18, 2019

by Jared M. Spool

If we rely on our UX team to make every design decision, then that team will become a bottleneck. That’s not going to work. Our team can’t possibly scale to handle every decision, especially as design becomes critical for our organization’s success.

We will need our partners from development, product management, and other key stakeholders to also make design decisions, using the lens of good user experience. They’ll handle decisions our team can’t get to, and we need them to make those decisions as if our team was involved.

It’s all the rage to talk about having multidisciplinary teams participate in the decision making. Yet, we rarely talk about how we empower folks from those other disciplines to make smart decisions at every stage.

In the All You Can Learn library, Kim Goodwin, Megan Grocki, and Leah Buley have great insights on how we can get more out of our multidisciplinary teams.

As you watch these seminars, you’ll want to focus on these key points:

Boosting Research and Design Adoption

photo Kim Goodwin

Kim Goodwin
Kim shares a fascinating model that shows how an organization’s culture falls into one of four categories. In this seminar, she walks through how we’ll need to approach our co-workers differently, depending on which culture we’re in. That’s essential for ensuring we frame how we work with the members of the multidisciplinary team.
Watch Now | 75 minutes

Talk To Me: Involving Non-Researchers in Customer Insights

photo Megan Grocki

Megan Grocki
Megan did exactly this at NASDAQ. As you watch this seminar, you’ll see how she used consensus-based approaches to focusing on research, and how she made the results available to the team. We love how she got others involved in the process, which was essential to her success.
Watch Now | 30 minutes

Research & Design for the UX Team of One

photo Leah Buley

Leah Buley
Even though Leah’s talk is mostly aimed at the solitary UX person in the organization, her techniques are valuable to teams of any size. She has great tools—the UX questionnaire, a project plan, a strategy workshop, and sketching—that create opportunities for others to participate and contribute to the user experience work.
Watch Now | 88 minutes

Get the essential tools for designing at scale

You get immediate access to Kim Goodwin, Megan Grocki, and Leah Buley’s expertise when you subscribe to UIE’s All You Can Learn Library. For just $29 per month, you can start watching these key UX seminars right away. (It’s easy to sign up, you can cancel without penalty, and it’s 100% guaranteed, so there’s no risk.)

Subscribe to UIE’s All You Can Learn Library.

UX Team of One: We Never Need to Feel Alone

December 13, 2019

by Jared M. Spool

It’s tough being the UX Team of One. We’re a solitary user experience person in a sea of co-workers who aren’t sure what delivering a great user experience is all about.

We’ve talked to folks about what it’s like to be a UX Team of One in their organization. We heard some fantastic tips for building UX awareness and capability when we’re in that situation. Here’s what we learned:

Discovering hidden champions inside our organization

When we feel supported and appreciated every day, we do better work. Having a highly-placed champion to support our work is key to having those feelings.

Often, our best champions are hidden from us inside our organization. We won’t find them in our group or directly in our management chain-of-command. Yet, these champions find that their key objectives are highly influenced by the user experience of our products and services.

Our champion could be the head of sales, who is losing sales because our product’s UX isn’t as good as it could be. Or they could be the head of support, whose team deals with hundreds or thousands of UX-related support problems every day. Or even the person in charge of development, who is frustrated their team wastes effort re-coding work that doesn’t meet our user’s needs.

When these individuals see how our design work can improve their objectives, they become our supporters. That can help us corral other resources from within the organization.

Reframing our design outputs as human-centered UX outcomes

It’s common for an organization’s leadership to state goals and objectives in terms of business needs. “We need to increase new subscriptions by 10% this year.”

We can get others on the program when we reframe this objective in terms of human-centered UX outcomes. These outcome statements answer the key question: “If we do a fantastic job improving our objective, how does that improve the lives of our users?”

Our business objective, when restated into a human-centered UX outcome, can look like this: “When we do a fantastic job improving the experience of signing up, 20,000 new subscribers will get delicious meals delivered to their homes, saving them the time and expense of planning a few dinners every month.”

Saying the outcome out loud reminds everyone why we all are working on this project. A great user experience isn’t just the responsibility of the solitary UX person. It’s the responsibility of everyone working to improve the product or service. We’re not alone.

Celebrate those that want to design with us

It’s not unusual for a developer, a product manager, or even an executive in our organization to suggest a design idea. Instead of pushing back and suggesting that design is the solitary purview of our own job, we can celebrate their efforts.

Because they may not have the training and experience to do good UX work, it’s likely their work won’t be up to the quality we would’ve produced. However, if we encourage their efforts, we can help them grow their skills. And that could take work off of our plate.

Just last week, we heard from a UX-team-of-one practitioner who regularly sits down with anyone in their organization who is interested in contributing to their product’s designs. The UX person collaborates with a developer or product manager who shows interest in flexing their own design muscle. They co-design the work, while they share the tips and experience they’ve learned over their career.

The end result is their co-collaborators are picking up basic design skills. Those collaborators get a glimpse into how much effort it takes to make a great user experience. That glimpse gives them respect and increases their understanding of design’s value.

Growing our community means we grow our support

While we may be the organization’s official solitary UX person, everyone else we work with is trying hard to deliver well-designed products and services. By increasing the visibility of our work, we’re promoting the value of good design.

When others show interest in learning from our experience, it creates a feeling of community. From there, we can build the case to no longer be the organization’s solitary UX person.

Because, in reality, we never were. Everyone else was right there with us, supporting everything we did.

Beyond the UX Tipping Point

December 11, 2019

by: Jared M. Spool

Surprisingly, few were talking about what could be the biggest user experience story of 2014: The introduction of the Disney Magic Band.

Once activated, park Guests use the Magic Band to gain access to the park, get in priority queues for the attractions, pay for their purchases at the concession stands, and even get into their hotel room.

Each family member has a wearable band with GPS and radio transmitters that track each other’s location in the park. At the end of their stay, Disney presents the family with a photo diary of their park adventures, having used automatic cameras to snap pictures when the Magic Bands are nearby. And imagine the face of a newly-turned six-year-old who just had his favorite Disney character address him by name and wish him a happy birthday.

The result is an extremely delightful vacation experience. Disney made a billion-dollar investment to create a wearable accessory that changes their park experience completely.

No Compromises on the Users’ Experience

To make the Magic Band work, Disney had to wire an entirely new infrastructure into its parks. Stores and restaurants needed to be outfitted with the new payment systems. Every hotel room needed new lock systems to work with the Magic Band’s RFID transmitter. Radio systems needed to start alerting the characters when a fan is nearby.

One billion dollars is a lot of money, but it’s easy to see how all these changes added up quickly. Yet, at any time, the team at Disney could’ve decided to cut corners. They could’ve said, “That’s a nice idea. Maybe we’ll do that in the second release?”

But they didn’t compromise. They decided to make the magic really work. After all, that’s what Disney is all about.

Just a decade ago, Disney was struggling to provide great online experiences. In those days, guests trying to make reservations found the system confusing and difficult to use. It was common for someone trying to book a resort stay through the website to have to call the customer support center to complete the transaction.

The real achievement of the Disney Magic Band is the transformation the organization has gone through to make it work. They made it past what we call the UX Tipping Point.

The Journey to Beyond the UX Tipping Point

The UX Tipping Point is the moment when an organization no longer compromises on well-designed user experiences. Before they hit the tipping point, they might talk about great design, but they’ll still ship a mediocre experience. However, once they’ve passed it, design has become an embedded part of their culture and DNA.

Many organizations take a similar journey to get beyond the tipping point. A typical journey might look like this:

The UX Dark Ages: At this point within the organization, there’s barely a mention of user experience. They build poor designs and deliver frustrating experiences, but don’t have any notion of how to improve that. Often, the organization’s priorities are focused on delivery and features, no matter what the design looks like.

Spot UX Projects: Someone in the organization is now feeling enough pain to create a couple of unrelated UX projects. It’s easy for these spot projects to succeed and get the attention of senior management, often because the thing they were improving was so bad, even the smallest improvement is notable. However, beyond talking about it, the UX “fever” rarely spreads beyond the manager that commissioned the initial projects.

Serious UX Investment: Senior management has caught the bug and thinks something should be done. Investment in outside help happens, whether an agency or consultancy, or maybe even hiring someone full time. More extensive projects are scoped. If they’re successful—producing solid, clearly identifiable results for the organization—more investment follows. Design starts to move from something done at the end of a project, to activities that help shape the project’s direction from the start.

Embedding UX Into Teams: Senior management realizes that UX is worth more investment, but also understands that integration into the teams is more effective. It gets faster results at a lower cost. Internal teams get staffed with UX folks who coordinate with each other while they work closely within the teams. Being embedded in the teams means that design is now an ongoing concern for the product or service, instead of being just something applied to a single release. Design roadmaps and visions start to appear.

It’s during this last phase that we see organizations crossing the UX tipping point. When UX skills are first embedded into teams, it’s still tolerable to ship a less-than-desirable design as a compromise to hitting business objectives. However, with more investment (that shows up as more UX skills added to the teams), the tolerance for compromising on design reduces. Eventually, a compromised design is more of an exception than a common occurrence.

Once the organization crosses the tipping point, we’ve found there’s still one more phase in their journey:

Integrated UX and Services: This is where Disney is with the Magic Band. User experience is no longer something delivered with a web site or an app. It’s every part of the organization. Non-digital service and product teams work together with their digital counterparts to provide a seamless, delightful experience for the customer, user, and employee. In this phase, it becomes impossible to separate out the investment in UX from the rest of what the organization delivers.

Startups Have the Tipping Point Advantage

Not every organization goes through all of these phases. The most notable exceptions are startups. If the founders understand how user experience and design will give them a competitive advantage, they build it in from the very beginning.

We see this with organizations like Cirque du Soleil, Uber, and Nest. These organizations didn’t need to prove the value of design to the senior management. Nor did they have to overcome legacy cultures and systems that never accounted for good design.

Instead, they jumped into creating great experiences from their very first day and kept running with it. Their competitors suddenly found themselves in a game of catch-up, trying to rush through the phases to pass through the tipping point.

In many cases, those competitors never quite got there. Look at Microsoft. While they’ve had some successes with products like the XBox, they’ve never made the shift of lowering their tolerance for poorly designed elements. When push comes to shove, they’ll ship something that is a less-than-ideal design to make their deadlines, instead of tailoring the ship date to when they can achieve an excellent design.

In these organizations, the rewards given senior management are for shipping features, not for delivering an excellent experience. With the rewards out of alignment, the UX Tipping Point won’t be crossed.

This Has All Happened Before

Look around any business today and you’ll see technology working in every nook and cranny. Yet it hasn’t always been that way. Just a few decades ago, there wasn’t any technology in most businesses. No databases and networks, no personal computers, and probably not even a mainframe sitting in a water-chilled room somewhere. The information technology that runs today’s businesses is a fairly new phenomenon.

Like the current UX Tipping Point, an IT Tipping Point appeared about 25 years ago. Before the IT Tipping Point, businesses got along just fine doing all their work by passing papers and relying on people to talk to each other. The business was slow and often didn’t scale very large.

When the technology came along, and then got cheaper to own, some businesses adapted right away and crossed the IT Tipping Point with glee. Others were dragged across it, kicking and screaming all the way. Many more never crossed it. They are no longer with us.

Like the UX Tipping Point, new companies of that era were born without having to make the journey across the IT Tipping Point. Because they started with the right technology in place, and a thorough understanding of how to use it, they were instantly competitive against the old mainstays in their industry. Old businesses that thought they were impregnable found themselves suddenly vulnerable to startups who had the right technological know-how.

That’s what we’re about to see with the UX Tipping Point. Suddenly, businesses that thought they were market leaders will be undermined by startups providing their customers, users, and employees great designs that don’t compromise on a better experience.

UX Literacy and Fluency: Keys to Moving Beyond

For an organization to move beyond the UX Tipping Point, it must first become literate in user experience, then fluent in how to produce great experiences. This doesn’t happen all at once, it can take years. However, if it never happens, the organization won’t make it beyond the tipping point.

Design is the rendering of intent: What does the organization intend their experience to be? Realizing they have control over their design, and the way it affects their users, is the first sign of movement in the journey.

Exposure to the current experience: Has every decision-maker been exposed to the current user experience? Seeing that their intention isn’t what users are experiencing can motivate them to invest in improving their designs.

Preventing experience rot: Can the stakeholders see the decisions that will degrade their experiences in the future? Thinking beyond a single release and understanding how new features today means complexity down the road is essential to curating a great experience.

Building the organization’s UX skills: Do product and service teams have the full set of skills necessary to deliver great experiences? Not just people with the title of designer, but everyone on the team that influences what the experience will be.

All this builds the underlying substrate that helps the organization work to a point when they feel they no longer need to compromise on good design. By understanding how to render their intentions with a team that is fully-skilled in up-to-date UX design practices, the organization can now regularly produce great user experiences for their customers, users, and employees. They’ve made it beyond the UX Tipping Point.

UX Strategy: It's Hugely Important. Unfortunately, It's Never Urgent.

December 5, 2019

by Jared M. Spool

The tactical work of user experience design has the benefit of always being urgent and important. However, it doesn’t leave any room for our non-urgent, but equally important strategy needs. This causes our important UX strategy planning to suffer. Suddenly, our non-urgent work becomes urgent, and we’re in a crisis.

We know a lot about this and it’s why we developed our Creating a UX Strategy Playbook workshop. We’ve designed this workshop as a haven for design leaders like you—to focus on the very important but not very urgent—work that helps our organization deliver better-designed products and services.

A workshop designed for you to focus on UX strategy

We intentionally designed our Creating a UX Strategy Playbook workshop to pull your leadership team away from the urgent day-to-day work. It’s the team offsite meeting you’ve wanted.

Your team will focus on your important UX strategy decisions. What do you need to change? Where should you focus your energy? What’s the story you need to tell the rest of the organization to show the value of great UX design?

This workshop is the two dedicated days your team needs to create their UX strategy action plan. With this action plan, your team will set deadlines, prioritize their urgent work, and drive the organization’s product strategy.

Taking the time to create your UX Strategy is hugely important. This workshop helps you bypass the problem of it not being urgent until it’s a crisis. Register today for your team to attend our Creating a UX Strategy Playbook workshop.

Bring your team together for our 2-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

Interview-Based Tasks: Learning from Leonardo DiCaprio

December 4, 2019

by: Jared M. Spool

The silence was deafening. The corporate Vice President of Marketing sat at the head of the table, with the rest of the room populated by the development team. Nobody was saying a word. They were letting the question just hang in the air: “What did we do wrong?”

It was the right question. The design recommendations seemed solid, yet sales had dropped 23% immediately after the changes were made. The recommendations came from a well-constructed set of usability tests. Everybody thought they were clear on where the problems were. Now they weren’t so sure.

What they didn’t know—what they learned later—is they had done everything right, almost. They’d recruited the right users, facilitated the test properly, and analyzed the results effectively. There was only one problem: the tasks didn’t match what real users do with the site. That one problem was the source of their current pain.

Scavenger-hunt tasks

The team used a very traditional approach to task design by carefully crafting a set of scavenger-hunt tasks. These tasks ask the users to find specific items on the web site.

When we first started testing on the web, we used scavenger-hunt tasks too. Some of our first tasks were “What’s the cheapest hotel on the monorail at Walt Disney World?” or “Who is Arizona’s Third District Congressional Representative?” They worked great. We could easily see if people could find the right information on these sites. We learned a lot about how these sites worked.

Scavenger-hunt tasks work best when you’ve thoroughly researched the types of things people look for on their site. Our tasks came from extensive interviews and field research. Unfortunately, many times, teams just make up their tasks without doing the research. That’s where the problems begin.

Leonardo DiCaprio tasks

For us, this problem came into focus in the early days of the web, when we had the opportunity to work with one of the leading search engine sites. They had just completed a usability test series put together by their advertising agency. The agency asked folks who worked in the Wall Street district of New York to come to the Madison Avenue offices to participate in the tests.

As each participant filed into the room, they sat them down in front of a machine with a browser and gave each of them the same task: “Pretend you’re interested in Leonardo DiCaprio. Find something out about him you don’t currently know.”

Now, imagine what you would do if you were asked to perform that task. If you have no real interest in Mr. DiCaprio’s life, you might enter his name into the search box and declare the task done on the first page you find with any real substance. The task would only take a few moments to complete.

However, someone with a deep interest in Leo’s world—maybe one of his mega-fans, let’s say—might spend more time on the task. They would dismiss information they already knew and hone in on content that was truly new and unique. We’d expect to see completely different behavior from this person.

Passion on a subject changes how participants invest in usability test tasks. That change can have profound effects on the results and the recommendations produced by the team.

Early solution: Role-playing

One of our first attempts at countering the effects of DiCaprio tasks was to ask participants to role-play. Role-playing is a time-tested psychological technique that puts people into a more conducive context, gaining the information you really need.

For example, we wouldn’t just ask our participants to find the cheapest hotel on the monorail. We’d first explain how we wanted them to pretend they had a family with a six-year-old who loved trains. Then we told them we wanted to pretend they were planning a trip to Disney for the kid’s birthday. Finally, we said that staying at a hotel on the monorail would be a real treat for the train-loving kid and was the desired outcome.

Imagining a trip to Disney isn’t hard for many people. It’s harder to get into the role of shopping for the ultimate retirement fund. We could only take role-playing so far.

Passion and its effects

We were quick to see that people who were passionate about the subject behaved quite differently than those that were not. The passionate people demanded more from the content on the site. They came to the task with more background and they wanted to see more to arrive at the right outcome.

Our challenge became to control the passion in our testing process. That’s when we started experimenting with interview-based tasks.

Interview-based tasks

In interview-based tasks, the participants’ interests are discovered, not assigned. Unlike scavenger-hunt tasks, the test’s facilitator and participant negotiate the tasks during the tests, instead of proceeding down a list of predefined tasks.

Because each task is drawn from the experience and interest of each participant, no two participants perform exactly the same tasks. As we’re looking for the usability problems that pop up, we’re also looking for how the user approaches their problem and the level of detail they require.

Surprisingly, we often see multiple participants run into the same problems. We find they rate the site consistently. Even though their tasks are radically different, they have very similar experiences.

We find the wording of their self-created tasks fascinating. As each participant designs their own tasks, they are telling us how they think about the content on the site, giving us insight into the words we choose for links and how we organize the material.

Starts with recruiting

Before we can sit down with a test participant and create an interview-based task, we need the right participant. The process starts when we begin recruiting the participants for the study.

It’s important to quickly identify those candidates that have a passion for the subject matter we’re evaluating. For example, when we were testing an e-commerce site that sold camping and hiking gear, we looked for people passionate about those activities.

We’ve found an open-ended interview technique works best for our recruiters. As the recruiter talks with each candidate, they probe about the candidate’s knowledge on the subject and their experience with the material.

For example, when we recruited for a retirement planning site, our recruiter discussed retirement plans with each candidate. They asked, with regard to retirement savings:

  • What have they done so far?
  • What are they considering doing in the near future?
  • Where have they been learning about their options?
  • What are their big concerns?
  • What are their long term goals?

By starting with broad questions, the recruiter gets a good sense if this is a subject area the candidate is passionate about or one they haven’t given much thought. A practiced recruiter can easily determine if a candidate is right for the study or won’t meet the team’s needs.

Facilitating the test

When facilitating the test, we add an additional 30 minutes for conducting the interview and creating the tasks. The goal of the interview is to explore the participant’s passion. The result is one or more tasks for the participant to perform with the design.

Starting with similar questions to those the recruiter asked, the facilitator probes the participant about their experience with the subject matter. After learning the details of their background and knowledge, the facilitator guides the discussion to current interests and tasks the user would like to accomplish. It’s at this point that they jointly craft the task description.

In crafting the task description, the facilitator wants to write down the words the participant used to describe their goals. They also want to clarify what “done” means, so that it’s clear to everyone if and when the task is completed. Once they’ve created the tasks, the facilitator directs the participant to try them, just like in other types of usability tests, looking for obstacles to attaining the participant’s objective.

Going places we didn’t expect

With interview-based tasks, participants take us down paths we never expect to go. We’ve learned that users often have very different ideas of what is necessary and what is important. We regularly see obstacles that, once eliminated with a quick fix, lead to dramatic improvements in the design. Terminology emerges to describe user needs in a way we hadn’t previously thought.

We’re happy to have interview-based tasks as one of the techniques in our toolbox. It’s ideal when we don’t have the resources available to do a thorough task analysis using more expensive field research methods. Alongside scavenger-hunt tasks, 5-second tests, inherent-value testing, and traditional usability tests, it gives us one more method to get the critical information teams need to build designs that truly enhance the quality of the user experience.

Undervaluing User Research is a Deadly Disease

November 19, 2019

by Jared M. Spool

During our UX strategy workshops, I ask design leaders to visualize the user research activities in their projects. They start with a timeline of a recent project, which shows the project’s kickoff date, when the project shipped, and major milestones that occurred along the way.

On top of that timeline, I ask them to answer questions about three groups of team members:

  1. When, during the project, did the team’s user experience professionals spend time observing real users interacting with the design under development? This group of UX professionals includes researchers, designers, content writers, or anyone else who sees themselves as designing the user experience.
  2. When did the other full-time professionals working on the project spend time observing real users interacting with the design? This group includes developers, product managers, and other stakeholders whose main responsibility was the delivery of the product or service.
  3. When did the other influencers working on the project spend time observing real users interacting with the design? This group includes the influencers who pop into the project for short durations, exerting influence in their wake. This includes executives who swoop-and-poop, critical high-ranking stakeholders, and folks like Legal and Compliance.

They mark up their timelines, showing when these three groups had a chance to observe users in action with the new design, with the previous version of the design, with competitors’ versions, or without using any existing product or service.

The takeaway: Not enough research

When they’re done, I ask the design leaders what their initial takeaways are from the exercise. The unanimous response: “We’re not doing enough research.”

Going into the exercise, they thought they were doing well with their research efforts. Many of them were conducting regular usability testing in most of their projects. Some were getting additional time conducting more ethnographic-style studies, getting into the customers’ workplaces or homes, and bringing back deeper insights into how the product or service might be used.

But the common observation amongst the design leaders is that there are too many holes in the project timeline when no research is happening. They need to find new ways to increase the research capability of project teams.

The distance between influence and critical information

Just yesterday, one design leader shared an additional insight with me. “The people who exert the most influence over the user experience often have the least amount of contact with our users,” he said.

I’ve found this to be completely true. In most projects, there are executives and stakeholders who make critical decisions that influence our users’ experiences. They decide how much money will be budgeted for the project, how much time the project can take, and how many people will work on it. Each of these decisions will have a dramatic influence over what the team can deliver to their users.

Yet, these executives and stakeholders are insulated from the users. They don’t have the deep awareness of the users’ struggles and delights with the product or service. They’re making important decisions without all the information they need.

Increasing exposure for team members

It’s at this point in the workshop that the design leaders have a critical epiphany. They need to increase the exposure that these influencers and other team members have to their users.

Exposure is how we measure the amount of contact team members have to users. We’ve found there’s a direct relationship between the amount of exposure team members have and the quality of the designs they deliver.

Increasing exposure makes users real to our team members and influencers. They now see when users struggle because of poor design decisions we’ve made. They also see when we’ve delighted users by delivering something that’s helpful to them.

Chronic undervaluing of user research

Usability testing is often the first place teams start their efforts to increase exposure. In these research sessions, they observe users interacting with the product or service. They give the research participants specific tasks and observe how the users complete the assignment.

While this is a good place to start with research, usability testing often comes towards the end of the project. The teams wait until they have a robust design for the participants to use.

This end-of-project approach limits the amount of change that can happen. It’s rare for a usability testing outcome to demonstrate that the product or service needs a major overhaul to truly meet users needs. At best, the outcomes are a list of incremental improvements.

As a result, the rest of the organization sees user research as a refinement tool that happens after the big decisions have been nailed down. They don’t see the research helping with those big decisions, because the technique limits what we can learn.

If we don’t have enough maturity in our user research efforts, we run the risk of limiting the understanding our team members and influencers can gain. And, in turn, they don’t see user research as a valuable contributor to their decision-making process.

Raising the value by increasing user research maturity

In her recent presentation at the Design Leadership Summit in Toronto, Jen Cardello, Head of UX Research & Insights for Fidelity Investments, shared how she increased the value of the user research maturity.

When she arrived at Fidelity, the majority of the user research effort was reactive usability testing. They were refining products, but not contributing critical insights about their users to the bigger decisions.

Jen and her team created a research framework with three simple perspectives:

  • The right problem: Do they know that the team is working on the right problem in the first place?
  • The right solution: Given they understand the problem, are they working on the right way to solve the problem?
  • Doing it right: With the knowledge that they’re working on the best solution, do they know the right way to implement and deliver that solution?

With this framework in hand, she launched a major strategic effort to educate teams on how to best take advantage of Fidelity’s research capabilities. She integrated the research into the project plan, using this framework to define research activities that happen all the way through the project timeline.

She focused on making user research more proactive within the organization. In turn, this increased the insights the teams integrated into their decision-making process.

The organization now values user research more, because they have a wider lens into the users’ experience. That wider lens came from a strategy to improve user research maturity.

Investing in increasing user research maturity is the cure

The biggest impediment to delivering well-designed products and services is a lack of understanding about our users. The team members and influencers can’t make smart design decisions with information they don’t have.

When an organization undervalues research, it’s a deepening, darkening, downward spiral of delivering poorly-designed products. Important influencers are only guessing when they’re making critical decisions. The quality of delivered products and services continue to get worse. This is a deadly cycle.

Investing in user research is the best cure. Increasing both the amount of exposure and the maturity of the research efforts will remedy this chronic condition.

Build Up Your Organization’s UX Design Capacity

November 15, 2019

by: Jared M. Spool

Almost every UX team starts the same way. I bet your team started this way too.

Your team’s first mandate was to improve the user experience. Your UX team members (which may have started as a single UX team of one) worked their collective butts off to make a difference in the products and services your organization delivers.

I’m betting your team has since demonstrated success. You may have even added more team members to the team.

Yet, you found there was still too much work to do. There was always more UX design work than your team could handle, no matter how many people you added. The user experience of your products and services could always be better than what your organization was putting into the world.

When the maturity switch happens

Faced with this never-ending cycle, many smart design leaders come to an important realization. I bet you’ve come to this realization too.

Your team will never be large enough. You’ll never have enough team members with the right skills, knowledge, and experience necessary to make the design of every product and service as good as it should be.

Instead of focusing only on growing your UX team, you need to increase your organization’s overall UX design capacity. By increasing your organization's overall capacity you’ll take the first steps to building a UX Design Infused organization.

When your organization is UX Design Infused, every product manager, developer, and stakeholder has enough UX design expertise to make their own smart decisions. Your UX team members can now tackle the hard challenges—the ones that will make your organization truly competitive in the marketplace.

To become UX Design Infused, you need to look beyond your own team members. You need to grow everyone’s ability to make smart design decisions.

You’ve switched the mandate of the UX team: From reactively trying to clean up every design, to proactively growing the organization’s capability to design and deliver well-designed products on their own. Switching from being reactive to becoming proactive is a big step.

This is a strategic switch

This switch in your mandate will require you to bring your organization along on a journey. That journey will increase what every individual understands about design. It will result in every person inside your organization to have the necessary skills and confidence to make smarter UX design decisions.

The good news is you’re not the first to make this switch. Other UX design leaders have taken their organization on this journey before you.

We’ve collected the successful strategies that other UX design leaders have employed in their organizations. Strategies from UX design leaders at organizations like Disney, Capital One, AirBnB, and Apple.

Identify the successful strategies for your organization

We’ll look at the experience vision strategies that successful UX design leaders use to communicate what great design does for customers and users. We’ll look at strategies for mapping those benefits into your organization’s business objectives.

We’ll explore how to drive decisions when you improve your organization’s research maturity. We’ll discover new methods to integrate quantitative data-driven metrics into your qualitative user research methods.

Most importantly, we’ll focus on how you’ll grow the UX design skills of each product manager, developer, and stakeholder. You’ll assess what their capability is today and identify where you need them to grow.

Together, we’ll identify which strategies work best for your organization. We’ll assemble the most effective strategies—those which will have the greatest effect soonest—into your team’s UX Strategy Playbook. And you’ll return to your office, ready to put these strategies into play immediately.

Building The Organization’s UX Capacity: A Quick Assessment Exercise

November 13, 2019

by: Jared M. Spool

To formulate a successful user experience strategy, UX design leaders need to have a deep understanding of their organization’s current UX capacity. What skills, knowledge, and experience in UX design and research do we have available in our organization? What will we need to accomplish the big things that lie ahead? Do we have enough people who can do the work?

We’ve created a simple exercise that identifies the gaps between your organization’s current capacity and what you'll need to successfully execute your UX strategies. While the mechanics of our exercise only takes a few minutes, the exercise’s benefit comes from the subsequent deep discussion around every aspect of managing and growing your UX capability.

Preparing to identify the organization’s UX skill gaps

To prepare for the exercise, we created a set of skill cards. Each card lists a particular set of UX skills, knowledge, and experience that your team will need to deliver well-designed products and services. The cards include a wide range of expertise, such as user research, marketing, information architecture, front-end development, and interaction design.

An image of four of the skills cards. First is Information Architecture - The organization of information, navigation, and wayfinding in your designs. Second, to the right of the first card, is User Research - Discovering who the users are, what they need, and how they solved their challenges. Third, to the bottom of the first card, is Visual Design - Creating a strong visual appearance that communicates the priority of information effectively. Fourth, to the right of the third card, is Information Design - Visualizing and interacting with complex data sets and information.
A few of the skills we’ve put on our skill cards. Download the full set from here.

We’ve included some blank cards. These are for the team leadership to fill out, with skills specific to your organization’s needs.

You’ll likely need to add specific skills around the domain of the products and services. For example, if your organization is delivering in the healthcare market, they need expertise in medical privacy regulations (HIPPA in the U.S.), medical technology, and how medical practices operate, to name a few.

There are skills specific to the business and technology your organization uses. Knowing how your business makes money and how to design for specific technology requirements are key.

We have a quick test you can use to figure out if a skill is worth adding to a blank card. We ask, if we were to hire a new designer who didn’t have any knowledge or experience with our domain, business, or technology, what would we have to train them on to be fully productive?

What are the upcoming big initiatives for your organization?

As part of the preparation, you’ll ask UX and product leadership to list out the major initiatives for the next year. What are the outcomes the leadership wants to achieve? What are the critical parts of the roadmap?

As you assess the skills of the team, think directly about these outcomes. We’ll be dedicating our new UX capacity specifically towards accomplishing these outcomes.

As you look at each skill card, you’ll want to go beyond just the UX and design teams. Consider all the other people who influence the users’ experiences for your products and services, like product managers, developers, and other influencers. After all, the decisions they make change up what your users’ experience will be.

For the exercise, the leadership of the UX and product teams sort the skill cards into these four piles:

Pile 1: Everybody has these skills, knowledge, and experience

In this pile, you'll put the skills that every member of our team currently has. It’s rare for an organization to have more than a few cards here. Most won’t have any in this pile. It takes a mature organization to make sure they’re hiring and training common skills across every job function.

Pile 2: Team has enough skills, knowledge, and experience

In this pile, you'll put the skills that, for the upcoming initiatives you’ve identified, your organization has enough skills on hand. This means no project will be stalled when a need for this expertise pops up.

Pile 3: Team needs more skills, knowledge, and experience

This is where you’ll put the cards for where your projects could use additional people with this expertise. Key projects will find themselves in a backlog until someone who has the skills, knowledge, and experience is freed up from more important work.

Pile 4: Team doesn’t have any skills, knowledge, and experience

This pile gets the cards where nobody on the team has the expertise. This is where your organization must go outside to get the skills, knowledge, and experience.

Assessing where you need to grow more capacity

The sorting usually goes quick. Then the fun starts.

Most teams end up with a lot of skill cards in the team needs more and team doesn’t have any piles. This is where UX capacity growth needs to happen.

The skills in team needs more means that there are people available internally to help grow the organization’s capabilities. They can lead training and coaching, to develop the skills in more individuals, eventually moving the card into the teams have enough pile.

The skills in team doesn’t have any mean there isn’t anyone already onboard to coach others. You’ll need to go outside to get this expertise.

A tool for planning your training and hiring needs

Looking at the skills most critical to the upcoming major initiatives and projects will tell you how to plan internal training and external hiring. You might find you can relax any hiring requirements for skills you have plenty of, while focusing on growing those skills you’re in critical need of.

This can feed into next year’s hiring and internal training plans. You can calculate the value of your team’s work necessary to achieve the major initiatives. That value is what you base your investment on for both training the team and hiring new team members. Calculating that value will give you a solid justification for both budget items.

This simple exercise yields tremendous strategic insight for UX design leaders. It gives a quick snapshot of where the team is and what it needs to go forward.

Reviewing UX Portfolios: 4 High-Risk Hiring Mistakes

November 6, 2019

by: Jared M. Spool

A UX portfolio seems like a no-brainer. You ask the candidate to give it to you. You review it. Then, if you like what you see, you interview them further and maybe you’ll offer them the opportunity to join your team.

However, there’s more to reviewing a portfolio than that. And many teams make serious mistakes in the process.

Hiring team members is hard enough. Let’s not make it harder.

It’s risky to push a candidate away who, had we hired them, would’ve done a great job for us. Losing a viable candidate means we’ll need to spend more time finding and interviewing other candidates to fill the job.

When we take too long to review their portfolio and give them feedback, they may decline to continue in our hiring process or refuse our job offer. This makes the hiring process more difficult.

It’s even worse if we hire someone who we thought looked great on paper and interviewed well, but can’t do the work we need them to do. We then find ourselves with a messy management and morale problem. It’s hard to work with a team member who is ill-equipped for the position, no matter how otherwise awesome they are.

Hiring mistakes put our team’s growth at risk. They can be avoided. Here are four hiring mistakes that teams make when reviewing UX portfolios, and how to avoid them.

Mistake #1: Not defining the position’s objectives upfront

Yogi Berra once said, “If you don’t know where you’re going, you’ll never get there.” So many hiring managers and team members open up a portfolio without knowing what they need to learn from it.

Treating a UX portfolio like a coffee-table picture book turns out to be a sure way to get a wrong understanding of the candidate. We can’t just flip through the portfolio and smile at the pretty pictures.

We must have specific objectives and assessment criteria for assessing each candidate’s portfolio. Otherwise, we’ll risk making judgement calls that are more about the aesthetics of the work and less about the capability of each candidate.

The hunt for comparable evidence

When we’re reviewing a portfolio, we’re on a hunt for direct evidence of the candidate’s comparable experience. Comparable experience is any work they’ve done in their previous jobs (or in school, when we’re considering an early-career candidate who is low on work experience) that matches the work we’ll need them to accomplish. We use the entire interview process, to collect all the evidence we can uncover that the candidate has similar work before. If they’ve done a great job in the past, there’s a good chance they’ll do a good job again, this time for us.

The goal of reviewing a candidate’s portfolio is simple: Can we tell if there’s enough evidence here to suggest this candidate should be prioritized higher in our hiring process than other candidates? If we find lots of comparable experience evidence in the portfolio, we want to quickly bring this person in for interviews. If we don’t see any evidence, we might hold up and talk to other candidates first.

What will our new hire accomplish in their first year?

To know what evidence to look for, we need to know what the new hire’s work will be. Will they be creating wireframes for a new design? Conducting research to identify user needs? Guiding a team to deliver a finely-designed mobile app? Rolling out a large design system to dozens of products?

No two designers will do the same job. Even if they work on the same project, they’ll likely divide up the work based on their strengths and experience. Having a clear picture of what we hope our new hire will accomplish in, say, their first year, will let us focus our review of every candidate’s portfolio.

When working with teams, we start them with a simple exercise of writing a thank you note to their future new hire. This is an easy way to start the conversation about what the new position will entail.

To know what to look for in candidate portfolios, the thank you note won’t be enough. For that, we create a much more detailed performance profile. The profile describes the objectives we want our new hire to achieve in their first year. By listing out the objectives, we can create a wishlist of what we want to see in every candidate’s UX portfolio.

Mistake #2: Requiring every candidate supply a UX portfolio

We know that résumés don’t tell us a lot about a candidate. When a candidate gives us a portfolio, they get a richer opportunity to communicate how they may fit the position we’re looking to fill.

Unfortunately, many candidates won’t have a portfolio ready when we start accepting applications. That’s not a reason to immediately disqualify them. There are several reasons why someone who could be a great fit might not have a portfolio ready and up-to-date.

The best candidates may not be actively looking

When we’re hiring, our goal is to identify those candidates who have the ideal skills, knowledge, and experience for the work we need done. Often, these candidates have gained their expertise because that’s what their current job is. And they may be very happy where they currently are.

These candidates aren’t looking for a new job. At least, not until they saw our open position. Suddenly, they’re intrigued.

Our job may be attractive because it gives that person a growth opportunity they wouldn’t get if they stayed where they currently are. The growth and challenges offered in our job look very appealing.

We call these folks passive candidates since they aren’t actively looking for a new job. Passive candidates are often the best-suited candidates, because the work they do every day is the work we need doing.

It’s likely a passive candidate doesn’t have a prepared UX portfolio ready. After all, they weren’t thinking about leaving their current job. Keeping a portfolio up to date hasn’t been high on their priority list.

When we insist they give us a portfolio as part of their job application, they may decide it’s not worth the effort to apply. For passive candidates, we have to remove any friction in the hiring process. They’re happy in their current job and will drop out of consideration at the slightest hint of inconvenience.

That would be a shame, because this candidate could be an ideal fit. We’ll never know, because we never had a chance to explore the job with them.

NDAs make portfolios more difficult

Active candidates may also have problems producing a UX portfolio for consideration. Even though they’re actively looking for a new job, it may be hard for them to show what they’ve done.

Many companies require every employee to sign a non-disclosure agreement when they start working. In those agreements, it’s common for the employer to refuse to give permission to show any of the work they’ve done.

If you can’t show work you’ve done, what do you put into your portfolio? This becomes a difficult problem for those candidates who have major work covered under non-disclosure.

(Pushing a candidate to violate their non-disclosure has real ethical issues. They made a promise and it’s not cool to ask them to break it, even when it’s inconvenient for your hiring process.)

Many UX jobs are hard to capture in a portfolio format

Even when a candidate has permission to show their work, for many UX professionals, there may not be an easy way to capture the essence of their achievements. The portfolio may be the wrong way for them to show their comparable experience.

UX portfolios are direct descendants of portfolio books used in graphic design and industrial design. In those cases, the portfolio was intended to show the designer’s body of work. Since the work was mostly visual, their portfolios could exist solely as pictures of each design they created.

In contrast, much UX work isn’t visual. It’s about communication and collaboration. Even when we create design artifacts, they are not very visually interesting.

For example, we may need to hire someone to manage our content strategy, starting with a content audit and then building up a content model of our future publications across multiple platforms. While there are many artifacts produced, they are mostly word processing documents and spreadsheets, with the occasional slide deck. Not the kind of stunning visuals that will dazzle someone looking through the portfolio.

Content strategy, information architecture, user research, and many types of interaction design are hard to capture in a portfolio that is mostly visual. (Exactly how do you show the designs of a voice user interface in a portfolio?) A list of web URLs in a content inventory won’t tell the candidate’s story about their work experience in any compelling way.

Collaboration and management can’t easily be shown

Most UX work is collaborative. For many UX jobs, we’re very interested in a candidate’s ability to collaborate.

Yet, a portfolio only shows an individual’s direct—often solo—contribution to a project. It’s not easy to represent a team effort within a UX portfolio, especially when trying to highlight the specific capability of the portfolio’s owner. How does a candidate show work that dozens of people contributed to, without laying claim to any work done by other people?

Similarly, what should a design manager put into their portfolio? They are directly responsible for the work of all the people who report to them, should they show the work of their team in their own portfolio?

If they don’t show the work of their direct reports, they might not have anything to put in the portfolio. Their comparable experience might be how they rallied team resources to produce great work. Yet, there’s nothing in that work for the candidate to point to and say, “I did that part.”

They may be our perfect new manager, applying their very relevant skills, knowledge, and experience at the challenges our team faces. Their portfolio can’t easily show us any of that.

It’s critical we don’t exclude an ideal candidate just because they couldn’t show us their work inside a UX portfolio. That’s an expensive mistake we can easily avoid.

Mistake #3: Not telling applicants what you’d like to see

Even though not all candidates will have portfolios, we can encourage those that have one ready to submit it. However, we should give them hints as to what we want to see in it.

After all, we’re on a hunt for specific comparable experience. We want to see the evidence that tells us the candidate has what’s needed for the job.

Collecting evidence is a collaboration between the interview team and the candidate. They work together so the candidate has every opportunity to share their relevant comparable experience.

Part of that collaboration starts with us saying what we’d like to see. In the job ad and wherever we ask candidates to apply, we’ll list out how we’ll assess if they’re a match for the position. For the applicants, this makes applying much easier, because they have an idea exactly what you’re looking for.

For example, here’s an excerpt from a team hiring looking for someone to manage and deliver a new multi-product design system:

We don’t require a portfolio, but we’d love to see one if you have it. In this position, you will be supporting the rollout of a design system.

We’d love to see any case studies you have about the design systems you’ve rolled out. We are particularly interested in the scale of the system (how many teams and products did it support) and the timeline of the work. What challenges did you encounter? How did you overcome them? What might you do differently next time, based on what you learned?

It’s ok if you don’t have a portfolio ready. Please apply without it. We’re excited to talk with you about your design system work, whether you have a portfolio or not.

Mistake #4: Eliminating a candidate when you don’t like what you see

A few years back, I was sitting next to a hiring manager as we were reviewing job applications for new positions on his team. As we brought up one candidate’s portfolio, he leaned forward and proclaimed “Oh my god. They’ve implemented their portfolio in WIX. That’s an immediate No.”

At first, I thought he was joking. He wasn’t.

He was seriously rejecting this candidate because of the tools they chose to implement their portfolio. (Maybe if the position was for a front-end designer, there could be an argument that the portfolio’s implementation is important to consider. But the objectives for this position didn’t require any coding. It shouldn’t have been a consideration.)

The purpose of any candidate’s UX portfolio is to reveal that candidate’s comparable experience. But an absence of relevant evidence doesn’t mean the candidate doesn’t have the skills, knowledge, and experience we’re seeking.

A good portfolio gives us the information and confidence we need to move a high-potential candidate to the front of our pipeline. That way we can consider them faster and possibly get them an offer sooner, since they’re demonstrating they have what we need for the job.

Our goal is to fill an open position. The faster we fill the position with a qualified candidate, the sooner we have a new team member contributing to our efforts.

Yet, a UX portfolio that is missing evidence shouldn’t reflect poorly on the candidate’s ability or value. And if they have work that isn’t relevant or they implement work in a way that isn’t what we think is right, we shouldn’t eliminate them from consideration.

Through the rest of the interview process, we can ask that candidate for more examples of their comparable experience. A portfolio will never provide enough evidence to tell us this is a candidate we should make the offer to. Similarly, it should, on its own, never disqualify a candidate from further consideration. At best, it just works as an accelerant, helping us quickly see the most promising candidates amongst all that applied.

A Perfect UX Strategy Planning Offsite

October 31, 2019

by: Jared M. Spool

The goal is simple: emerge from your team’s planning offsite meeting with a solid UX strategy for the new year. That strategy lays out what your team needs to do to drive your organization to deliver better-designed products and services.

With your new plan in hand, you’ll know exactly what you and your team will do differently the following 12 months. You’ll know what success looks like. You’ll know the next actions you need to take. You’ll have identified the questions you need answering so you can succeed.

Ideally, your product and development leadership peers were at this offsite. They took part in the planning process, partially because their perspectives are valuable insights.

But also because you need your peers’ buy-in. You can’t do this alone. You’ll need their help. When they participated in creating your UX strategy, they became bought-in to your success.

Your UX Strategy Planning Offsite is critical to driving change in your organization.

The formula for a successful offsite

It’s extremely hard to put together a team planning offsite that produces successful results. And it’s expensive if it fails. Taking all those people away from their day-to-day work better deliver results.

That’s why we created the Creating A UX Strategy Playbook workshop. It’s the perfect UX strategy planning offsite.

Everyone comes to a common understanding of the challenges your organization faces.
Everyone you bring to the planning offsite will be coming from their own place, with their own perspectives, agendas, and experiences. We use the common goal of delivering better-designed products and services to bring those different perspectives together.

Craft your ideal UX strategy under the leadership of an experienced facilitator.
Leading an offsite like this requires extensive planning and experience. Fortunately, our workshop leader, Jared Spool, has 40 years of experience working with organizations like yours. Under his guidance, you’ll get the strategic plan your organization needs.

Benefit from the experience of hundreds of successful UX design leaders.
You’re not the first team to face the challenges you have ahead of you. Many have been here before. We’ve compiled more than 130 strategies, successfully employed by UX design leaders just like you. You’ll pick out the strategies that best fit your needs.

This workshop is the ideal UX Strategy Planning Offsite for your team. It’s likely the most valuable two days you and your team could spend together.

Our 100% guarantee that you’ll succeed

We’re so confident the Creating A UX Strategy Playbook workshop is the perfect UX strategy planning workshop for your team, we’ll 100% guarantee it. Emerge from the workshop with an effective strategic plan or we’ll refund your money, 100%. That’s how confident we are.

We know this because hundreds of organizations before you have succeeded. Design leaders from organizations like The World Bank, GM, Expedia, St. Jude’s Hospital, Crate & Barrel, Google, Best Buy, Qantas Airlines, and AllState have all emerged with their UX strategic plans in hand. They’ve since executed those plans, with amazing progress as the result.

We have limited seating in our upcoming workshops. There are a few seats for our November Australia sessions. And several openings left in our December and February Chattanooga sessions.

Put together your perfect UX strategy offsite today by joining us at one of our upcoming Creating A UX Strategy Playbook workshops. Then, emerge with your strategic plan in your hands and start getting to work.

To Show the Value of UX, We Must Show the Work of UX

October 24, 2019

by: Jared M. Spool

I was once again in a design presentation meeting. The team, which had worked hard for weeks on their new user experience design, was introducing the new look and feel to their peers and stakeholders. It was good, solid work.

Their peers and stakeholders were not impressed. They weren’t disappointed either, just not wowed. There was an atmosphere in the room, almost saying, “You worked on this for months and this is all you have to show us?”

As the presentation fell flat, I couldn’t help but think about the final scene in the first Star Wars movie (A New Hope, Episode IV). You’ve probably seen this scene. It’s where the movie’s heroes, Luke, Leia, Han, and Chewie, along with droids C3PO and R2D2, are all standing on a big stage receiving medals and awards for saving the rebellion and destroying the Empire’s Death Star.

I’m pretty sure George Lucas, the movie’s director, never tried to explain the story of Star Wars by just showing that scene. Sure, that moment is where the characters’ efforts lead to. But, it’s not a good way to understand the importance of the work they put in to get there.

The ‘big reveal’ rarely works.

There’s a romantic idea that we can make a show of our finished work. We gather the team in the room, build up the suspense, and violà! The crowd will gasp as we show the amazing work we’ve done.

Of course, that’s not how it ever turns out. If we’ve done a great job at our designs, they won't look special. They’ll look clean and simple, as if they’d been there all along.

A great design won’t look like it took a lot of work. That’s not helpful if we want our peers and stakeholders to value UX design. It’s hard to value something that you don’t appreciate.

Show, don’t tell.

George Lucas got us excited about the story behind Star Wars by telling the entire adventure. That can work for an action movie.

That first Star Wars flick had a running time of 2 hours 5 minutes. It’s unlikely that our peers and stakeholders will patiently sit through a recreation of our design journey, even if we kept the run time at half of that.

The most successful UX design leaders have a different approach to win over the appreciation of their colleagues. They don’t wait until the end of the project to share the UX design. Instead, they show their work all the way through the design process.

Involving the entire team in the design process.

To show their team’s work, the UX design leaders include their peers and stakeholders in the design process. They don’t just wait until the end of their design process to show them their final work product. They use a variety of techniques to open up their process to others on the teams.

For example, design critiques are made more effective when individuals outside the design team participate. The discussion during the critique session, when done well, reveals the effort that went into the design itself. Frequent design critique sessions provide the extra benefit of showing the progress of the project.

Posting ongoing work on the walls keeps the process visible to everyone who passes by. They may not stop to read through each change, but they can see that changes happen frequently.

Taking advantage of our desire to solve problems.

People love a good puzzle to solve. We can take advantage of that, when we present design challenges as problems that need solving.

For example, design studio workshops open up the design process to non-designers. They get the opportunity to work through design challenges alongside the design team. They can see how many different approaches there are to solving a difficult problem and learn a few design techniques in the process.

Also, bringing non-designers along to user research sessions helps show how a single design solution may not be effective for all users. Seeing the variety of users the team needs to design for is often an eye-opener for those who never thought about it before.

Successful design leaders enhance their research by asking their peers to predict what users will do ahead of the research session. This has the benefit of reinforcing the difficulty of producing optimal design solutions for a wide audience.

We must show our work to be appreciated.

It’s not helpful when UX designers try to work in isolation, away from the rest of the team. They need to be out in the open with their process, showing the work as they go along.

There are UX designers who are resistant to this idea. They don’t want to invite the inevitable criticism of “unfinished” work.

But that just reinforces the mysticism of a closed-off design process. It doesn’t lend itself to showing the true value of our work.

If our goal is to drive our organizations to deliver better-designed products and services, we’ll need everyone we work with to appreciate the hard work that goes into a good design. And the only way we’ll get that appreciation is to show the work of UX.

Turning Quantitative Data into Strategic UX Metrics

October 17, 2019

by: Jared M. Spool

Our organization is swimming in data. And, if we knew what’s valuable to collect, we could gather much more.

Yet, how do we turn all that data into solid UX insights? Strategic insights that demonstrate the value of great user experiences. Insights that drive our organization to deliver better-designed products and services.

Deriving substantial value from our organization’s quantitative data is one of the most popular sections of our 2-day Creating A UX Strategy Playbook workshop. Every design leader who attends our workshop is hungry to know how they can take advantage of the mounds of data their organization is constantly producing.

Exploring the full-range of available UX metrics.

During our Creating A UX Strategy Playbook workshop, you'll pull apart a variety of approaches to UX metrics that successful design leaders have applied. You’ll discuss about how best to adapt available metrics for your team’s needs. And, you’ll identify the dangerous pitfalls that you’ll need to avoid.

I’ll introduce you to UX success metrics. These highly specialized metrics tell your teams exactly when you’ve achieved improved UX outcomes for your users and customers. By knowing where the finish line is, you can use the data to tell your teams and stakeholders how far you still have to go.

I’ll also show you storytelling metrics, which increases the deep awareness your teams have around the problems your users and customers face today. This deep awareness makes a clear argument why you’ll need more UX investment and resources.

You’ll also see how successful design leaders take advantage of reporting metrics. These are the metrics you’ll use to report your team’s progress. They spotlight the value of your team’s UX work, which, in turn, increases the executive desire to grow your UX efforts.

And we’ll show how we can use exploratory metrics to drive innovation through the organization. Using quantitative data strategically can uncover new features, products, and services, which will deliver better value to your customers and users.

Embedding effective data use into your UX strategy.

Of course, quantitative metrics, by themselves, can’t exist in a vacuum. You need to have a persuasive experience vision and a mature user research effort to back them up. That’s when they provide the most value.

We talk about all of these strategies to metrics and more in our Creating A UX Strategy Playbook workshop. And we‘ll do it in a way that your peers—the product management, development and marketing leaders of your organization—can understand.

Your peers will leave this workshop with a deep understanding of how UX increases the organization’s competitive value. And more importantly, because of your new UX Strategy Playbook, you and your peers will know exactly which changes everyone needs to start making in the organization.

The workshop is a game-changer for design leaders like you. Knowing how you’ll turn quantitative data into strategic UX metrics is at the center of those changes.

These workshops fill up quickly. Don’t delay.

You need to integrate your organization’s quantitative data efforts into a solid UX strategy. Sign up for our next Creating A UX Strategy Playbook workshop and start delivering well-designed products and services.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

The Myth Of the Grand Unified UX Metric

October 15, 2019

by Jared M. Spool

In 2003, The Harvard Business Review published an article by a consultant named Fred Reichheld, called The One Number You Need to Grow. In this article, Fred described how asking a single question, on a numeric scale, could predict customer loyalty and, subsequently, business success. He called his measure the Net Promoter Score (NPS).

Though lots of businesses still use it, it turns out that the Net Promoter Score doesn’t predict either loyalty or business success. By itself, the score proves to not be any more useful than following the horoscope in the daily newspaper.

Other measures have tried desperately to fill the void left by NPS. The System Usability Score (SUS), Customer Satisfaction (CSAT), and others all try to deliver a single number to tell us how we’re doing. None of them are any better than NPS.

No single metric will tell us how we’re doing.

The theory of a grand unified metric goes like this: By benchmarking competing companies on this single metric, we can get a relative idea of who is delivering the best experience for customers. Organizations pay consultants big bucks to get their products and services measured. The consultants deliver reports around a unified measurement, which companies review with a fine-tooth comb. They seek any indication on how they could boost their score, hoping to someday be in the lead.

Boosting a consultant-provided score seems like a great goal, until you realize it has no relationship to the experience the organization delivers to its customers and users. Improving the score becomes a game. A game not related to the important things that make the organization competitive in the market. Unlocking the secret to improving the score will not unlock a better user experience.

Unfortunately, the theory that a grand unified metric can tell us how well our products and services are doing is just a myth. No such metric actually exists.

There are many ways to measure success.

Imagine a bakery. It could sell the tastiest cupcakes and pastries. Or it could be the cheapest bakery in town. Or it could have the best atmosphere for a relaxing meetup with a friend or two.

It’s unlikely it would be all three. Why should it? There’s plenty of business for bakeries of all types.

The bakery owner striving to have the best atmosphere shouldn’t use the same measurement of success as a baker trying to offer the cheapest baked goods. The metric the bakery owner should use needs to be specific to the goals of the business, not generic across all businesses.

Every product and service experience needs unique metrics.

Organizations should strive to be different from their competitors. They work hard to offer the best value for their customers.

But that value is unique to that organization. It’s ironic when organizations—working hard to create their unique value proposition—want to have a common measure to rank themselves against their competition.

If their proposition is indeed unique, then so is their competitors’. Everyone is striving to end up in a different place. Using a single metric to determine who is the best would require every value proposition be identical, not different.

We need metrics that are unique to our own value proposition. We need to remember why our product or service makes the world a better place. Then, using that as a basis, we create UX Success Metrics.

Measuring our success will require that we strengthen our UX research game. We’ll need more sophisticated techniques for connecting the improvements we make in our designs to improvement in the business. We’ll do this by translating our findings into the language that our executives speak.

We can measure our improvement, but we need to do it on our terms. We shouldn’t try to divine what these consultant-driven metrics packages pretend to tell us. We should drive our organizations by what it really means to deliver well-designed products and services.

The Challenge of Identifying UX Success Metrics

October 10, 2019

by Jared M. Spool

A city’s IT department is building a new online parking-violation payment system. For the first time, instead of sending checks in the mail or paying at the City Clerk’s Office, people can pay their parking tickets through the city’s website or a mobile app. One question hung over the design team, how would they know if the new system is an improvement over the existing system?

In the design team’s discovery research, they met recent parking ticket recipients. The recipients talked through what it’s like getting the ticket and how they made sure it got paid.

In their research, many people said it was difficult to pay by mail. For some, this was the first time they’d handwritten a bank check in months. Just locating their checkbook took effort.

If they didn’t want to pay by check, they had to go to the City Clerk’s Office. While the office accepted credit card payments, the parking violators had to take time off of work to go in. It was very inconvenient (and, ironically, required they pay for more parking).

Because the tickets are difficult to pay, many parking violators missed the 30-day payment deadline. They’d get hit with a late-payment penalty. If they still didn’t pay, they’d put their car registration at risk. In the worst cases, they could be subject to a warrant and arrest. None of this was a good experience.

The team hopes the new system will solve these challenges. It’s a straightforward e-commerce solution. Other municipalities have already implemented similar systems. The team has many models to explore.

Measuring UX success starts with identifying the outcome.

The system will be expensive to build and maintain. The City Council wants assurances that the investment will be worth it. They asked for data to show that the new system is, in fact, an improvement over the existing system.

When measuring the effects of implementing a user experience, we need to look at the intended outcomes of the design. A UX outcome is the change we see in the world because we’ve done a great job implementing our design.

In the case of the ticket payment system, the design team’s intended outcome was helping people pay sooner. This would eliminate any late fees and the associated hassles that come from missing the 30-day payment deadline.

Multiple user roles mean multiple intended outcomes.

When designs have multiple user roles, there are likely different intended outcomes for each role. After all, we want to improve everyone’s lives with our designs.

For example, the new payment system will hopefully reduce the burden on the City Clerk’s Office. Right now, a substantial part of the office employee’s time is processing in-person and mailed-in payments. The online system should reduce that processing time.

Also, parking officers currently write tickets by hand. Their handwriting can be hard to read, especially in cold weather when they’re wearing gloves. These tickets are hard to read by the clerks.

The team identified all the changes they hoped their design would make. From these outcomes, they built their key measures.

Measuring the evidence of behavior change.

The medium of designers is behavior. — Robert Fabricant

We achieve our design’s outcomes when our users behave differently. As designers, we can only change a user’s behavior by changing our designs.

The city’s design team wants users to pay through their new system. They can measure success by the percentage of ticket recipients choosing to pay online, versus mailing in checks or showing up at the City Clerk’s Office. They can also track the number of people missing the 30-day payment deadline as it hypothetically decreases.

This means users have to know the new payment method exists. Those users need to access it easily. They need to complete the payment online without encountering obstacles.

In the end, the team and their design will succeed if they see an increase in the system’s usage. If the percentage of transactions using the system steadily increases, the design team can report to the City Council the system is working.

The team can also report improvements from the City Clerk’s Office. Do the office employees spend less time processing tickets, now that many of the transactions are handled online? Is time spent handling transcription errors reduced, because tickets are now digitally created instead of handwritten?

Transactions make UX success metrics easy to identify.

Measuring the improvements from the online parking-violation payment system is straightforward. The team can see how to measure outcomes because they can see each transaction.

While researching the existing payment system, the design team can see where users encountered friction during their transactions. If they can find something measurable in that friction, they can use that measure to track improvements.

For example, they can measure the time it takes clerks to transcribe handwritten tickets. And they can count the errors that resulted from hard-to-read handwriting. By tracking those measurements of friction, the team can set a target to aim for.

The team can also work with parking violators to learn the burdens of making payments through the old system. They can measure how much time it takes to travel to the clerk’s office or to locate their bank checkbook. They can measure the costs of late fees and penalties. These measures can be aggregated and reported.

Transactional systems are the easiest to measure, because a transaction is a clear change in the world. When working on transactional systems, teams only need to consider a few scenarios. And each scenario has a clear end-state.

When the end-state is clear, measuring the end-state is simple. This makes the UX success metrics easy to collect and report.

Non-transactional outcomes are harder to measure.

What happens when the transactions aren’t clear? UX success metrics become more difficult to pin down.

As the city’s IT department is working on the new parking-violation payment system, they’re also redesigning the city’s Zoning Board information system. The Zoning Board system contains all the minutes, decisions, and regulations that the zoning board has compiled over many years of existence.

The existing repository is a collection of PDFs organized by date. It’s clear that the organization and format of this information is suboptimal.

It’s also not clear what an improved system should look like. When the team started on the project, they didn’t understand how anyone used the repository of zoning information.

When we don’t know what our improved designs will be used for, it’s very difficult to understand what the outcomes are. What changes do we need to see in the world? Without this, we can’t put UX success metrics into place for our project.

Gaining deep awareness to identify UX success metrics.

Picking the right metric to track is important. The team can pick a variety of metrics to show how users are interacting with the system. The team could monitor the number of visitors, how long they spend on pages, or how many times they use the search functionality.

But, none of these metrics tell the team if the design is helpful to the users. And without an understanding of why the users need the system, they can’t determine if they’ve achieved their goals.

For the person who receives a parking ticket, we know their goal is to pay off the ticket and make it go away. Yet, for the person who comes to the Zoning Board information system, what do they need to achieve? What needs to change in their world for their interaction with the information system to be a success?

To learn this, the team needed to gain deep awareness about the people who use this system. They started by talking to the clerks in the Zoning Board office. Who was calling with questions? What questions were they asking? Was the information they needed in the existing PDFs?

Then the team contacted the people who were calling into the office. What information were they seeking? Why did they need that information? Once they had it, what would they do with it? What triggered the need for this information at this time?

All of that information generated a deep awareness of how people were using the information today. It also showed how the current PDF-based structure of the information was creating friction to their individual goals.

UX success metrics are iterative too.

In their research, the team found that many of the zoning board callers were interested in a specific property. They either wanted to know the existing zoning requirements for that property, or they had requested a change in zoning to be considered by the board. Those interested in changing a property’s zoning were often interested in the status of their request.

If the team made the system easier for these two goals, they’d reduce the number of calls coming into the Zoning Board office. This would free up the office staff to do other work.

This gave the team two sets of UX success metrics for the Zoning Board information system. One, they could track the number of searches for specific properties and zoning change requests. Two, they could track the number of calls the clerks received questions to specific properties or change requests.

As the system was implemented, they monitored the types of questions the clerks were receiving. When callers asked more sophisticated questions, the team considered improvements to the system. The incoming calls became the driver for improvements, with the reduction in those questions as a new UX success metric.

As we learn more about what our users need from our designs, we need to constantly revisit our UX success metrics. Over time, our metrics will grow to be more sophisticated in themselves.

Choosing UX success metrics can’t be one-and-done.

A UX success metric is a specific type of metric that tracks the outcomes our users want to achieve. Some outcomes, as in the case of the parking ticket payment system, are easy to determine from the start.

But many outcomes require us to up the maturity of our research capability. The metrics we create to track those outcomes need to adapt to what we learn in the research.

For many products and services, we can’t pick a set of metrics at the outset and say, “Ok, that’s how we’ll always measure success.” If we do that, we’ll lock ourselves into a simplified notion of success. That’s how we unintentionally leave a door open for competitors to steal our business from us.

Our metrics need to grow as our understanding of our users grows. And with every growth spurt, we’ll become one step closer to a design-mature organization.

Leading Your Organization's Experience Vision

October 3, 2019

by: Jared M. Spool

A solid Experience Vision is a critical user experience strategy that will drive your organization to deliver better-designed products and services.

If you’re not employing an experience vision, here’s what you’re missing:

Your experience vision is essential to your team’s success. If you haven’t created one yet, let us help you get there.

See you at a future workshop,
Jared Spool
Workshop Leader

Drive Innovative Designs Using Experience Visions

October 1, 2019

by: Jared M. Spool

In 1991, Apple launched their Powerbook 100, one of the first general-use laptop computers. It was hailed as a marvel of engineering—a full-featured computer the size of a notebook.

The Powerbook 100 was inspired by an internal project put together four years earlier: The Knowledge Navigator. The Knowledge Navigator wasn’t a real machine. Apple would never build or deliver one. It was just a concept showing what a team inside Apple thought computing technology might look like 23 years in the future.

Even though it wasn’t real, the Knowledge Navigator captured the imagination of the Powerbook 100 team. When the team faced a hard decision, they thought back to the Knowledge Navigator concept work. Given their choices, they asked themselves which choice would get them closer to building something like the Knowledge Navigator.

The future experience captured in a story.

The Knowledge Navigator concept is an example of what we call an experience vision. An experience vision is a story that demonstrates what a user’s experience would be like years in the future.

An experience vision doesn’t describe a new product or service. Instead, it shows how a user’s life would change because of the ideas embodied in the vision’s story.

Guiding the hard decisions.

When a team faces a hard design decision, there are questions around criteria they can ask to help them make their decision:

  • Which choice would be faster to develop?
  • Which choice would be cheaper to manufacture or deliver?
  • Which choice would be easier to get into the market?

These are all great criteria to use. However, the Powerbook 100 team’s decision-making criteria came from a different question:

  • Which choice would get the team closer to building something like a Knowledge Navigator?

The Powerbook team chose this question to guide their decision-making process. It focused their answers to benefit Apple and their customers, in the long run.

This question put Apple’s customers squarely in the center of the team’s decision-making process. The experience became a way to step beyond incremental-short term thinking.

Apple didn’t have the technical capability or knowhow to build a Knowledge Navigator in 1991. However, their teams could use it as a way to choose which technology to develop. They could take a baby step with every decision they made.

The experience vision gives direction across multiple products and releases.

After the Powerbook 100 came out, we saw Apple’s teams continue to take baby steps towards the experience vision with every new product. The Apple Newton, the MacBook product line, the iPod, and the iPhone all took steps in the direction of the Knowledge Navigator experience.

2010—the year the original Knowledge Navigator story took place—was the year Apple released the first iPad. The iPad was quite close to the ideas in the Knowledge Navigator.

Starting with the Powerbook 100, and heading all the way up to the release of the iPad, Apple continued to deliver the most innovative products. Looking back, it’s clear that every innovation was influenced by the Knowledge Navigator.

An experience vision gives a team direction. It puts the user’s experience in the center of every important decision. And it drives an organization to deliver innovative products and services every step of the way.

Gaining a Competitive Advantage with a Solid Experience Vision

September 24, 2019

by: Jared M. Spool

Let’s say your company manages to deliver a product or service that people really like, one that is unlike any other product or service out there. That’s a great feeling, but it won’t last long.

Moments after any successful new product or service is released, competitors emerge. They work to deliver products that carve away a piece of the emerging market. They’ll ship a competing design that is cheaper or better in some way. Customers will switch to their offered product. The competition will become fierce.

As UX designers, we get sucked into that competitive universe. No matter how much we resist, we’re pressured to change our designs to match what the competitors deliver.

When we’re in a competitive battle, we lose control of the design process. We’re told that feature parity—matching their product’s capabilities, feature for feature—is the top goal. “Customers won’t choose us if we don’t have what the competitors have.”

Competitive parity ultimately leads to experience rot.

Adding features and functionality solely because a competitor has it in their product or service, inevitably increases the complexity of our designs. That complexity hurts our users’ experience. It drives up support costs. It makes the product harder to learn.

It’s impossible to avoid: feature-for-feature parity ultimately leads to experience rot. When we continually add new features, we make our design more complex. And when we increase complexity we reduce the quality of the user experience.

Experience rot creates an opening for a competitor to step in and deliver a better experience to our customers. That’s the ironic thing: the harder we work to match our competitor’s capabilities, the more we hurt our own competitiveness.

Avoiding experience rot.

We can deliver market-leading products and services without becoming trapped in the competitive-parity rat race. To do that, we must understand how market competition plays out from the customer’s perspective.

The vast majority of the time, when customers have multiple products or services to choose from, they choose based on price or quality. Customers choose the product with the lowest price when they can’t see any differences otherwise.

Yet, customers don’t always choose on price. Customers, when given the right motivation, will choose a more expensive product or service because of a perceived benefit that comes from its quality.

Competing on price.

Becoming competitive in price means finding a way to lower the costs of development and delivery. The lower the costs are to the company, the lower the price.

When you have the lowest costs, you can lower the price below what it costs your competitors to sell the same thing. Walmart usually has the lowest prices because they use their volume to negotiate lower costs of every product they sell. This means, if Walmart wanted to, they could charge less than the costs of their competitors to sell the same products.

If you do that long enough, you put your competitors out of business. They can’t afford to match your price because they would lose money on every sale.

Competing on quality.

Competing on quality is different than competing on price. Competing on quality means you sell a product or service with qualities the customers find more desirable than what your competitors sell.

Competing on quality, for many years, has been the approach of luxury brands. People choose the luxury brand because it’s “worth it.” In those people’s minds, there’s some quality about the product or service that makes them feel better. That quality could be how the product is built, how the service is delivered, how it makes them feel, or even how it makes them look.

When people are choosing a product or service on quality, they aren’t looking at price as closely. If they feel it’s worth it, the customer will pay more.

Apple showed the world that a quality technology product was worth paying a higher price for millions of customers. Disney makes going to their theme parks worth it, even though they are far more expensive than any other competitor’s amusement parks.

Price has a limit that quality doesn’t.

The problem with lowering your costs is you eventually reach the floor. Costs can only go down to zero. At some point, you can’t force your costs any lower than what they currently are.

When competing on price, the product or service becomes a commodity, like toothpaste, potato chips, or laundry soap. In the customer’s mind, it doesn’t matter who they buy the product from They just want to buy it at the lowest price.

Increasing quality, on the other hand, has no ceiling. No matter how good a product or service is, it can always get better. If we can identify the qualities that our customers care about, we can win their purchase.

How car companies shifted their market from price to quality.

In the 60s and 70s, the American automotive industry was competing on price. They worked hard to lower the costs of making cars, so they could keep their prices low.

That lowering of costs had the effect of making poor quality cars. The cars would break down, dangerous to drive, and were expensive to keep running.

Manufacturers like Toyota, Honda, Volvo, and Volkswagen saw an opening. They delivered better-quality cars to the American market. Their cars were better built, more reliable, and safer.

Car shoppers started to switch from price to quality in the 80s. Even though American manufacturers were keeping prices down, customers were choosing more expensive vehicles because they perceived those cars had better quality.

Quality is about experiential change.

When we talk to customers about why they chose a more expensive product, they always describe their reason in terms of an experience they’ve had.

Their last car wasn’t reliable, and they wanted to pay more for a vehicle they could count on. Or they now have children, and they’re more concerned about their family’s safety. Or their job has changed, and they now need more storage space to carry equipment to various work sites.

The customers’ reasons follow a common formula: They tell a story about experiences they’ve had in the past, and then they tell a story about a future experience. The past experience had something the customers wanted to be changed, and the future experience describes what has changed about it.

This plays right into a UX designer’s secret weapon: we design experiences. Design is all about taking an experience that’s frustrating in some way and making it more delightful.

Experience Visions: What a more delightful future looks like.

An experience vision is a story we tell everyone in our organization. That story is about the experience of using our products and services in the future. It answers the question “What if we could make our design more delightful for our users?”

For our team, the experience vision acts as a flag in the sand that everyone is marching towards. The flag is far away. It will take us a long time to get there.

A clear experience vision gives everyone the same flag to march towards. No matter how long it will take us to get there, we’ll get there together. And because each of us can see it, we can tell when each of our baby steps takes us closer or farther away from the flag. The experience vision guides us in the right direction.

The experience vision embodies stories that demonstrate the reasons why customers will switch to our future product or service. It does that by telling a story that matches the same type of stories we heard when we asked customers why they chose more expensive products.

Based on researching what users need.

To create a compelling, competitive experience vision, we need to do our homework. Our team needs to build a deep awareness of what our users need from our products and services.

While researching and developing that deep awareness, we uncover where the current experience is frustrating and delighting our users. Where we’ve frustrated our users indicates our opportunities to improve the experience. Where the current product or service delights our users, we find important elements we need to preserve or expand upon in our future vision.

Go beyond just watching the users while they interact with our product or service. See the entirety of the experience. Learn what leads up to them interacting with our design. Ask what happens outside of our product or service. What do they do, once they are done with us?

Where do our users interact with co-workers, family members, or other people? Could our product or service help those other people, either directly or indirectly? Where do users interact with other products or services? Could integrating with those products or services make our users’ lives easier?

By getting a picture of the entire experience—not just the part that our product or service covers—we can see better ways to integrate into our users’ lives. It’s that deeper integration that offers opportunities for delivering something truly competitive.

Don’t pay attention to the competition’s products...

Many companies do a competitive analysis by studying the competitors’ products for the newest features. They’ll either access the products directly or use market analysts, such as Gartner or Forrester. These market analysts make money by selling detailed reports about what every competitor delivers in its products.

However, to build a solid experience vision, we want to shy away from studying the products of our competitors. Those competitors may just be guessing what customers need. Studying the features doesn’t tell us what users do with those features. It doesn’t tell us what users find frustrating about those features.

The competitors may not have done the research. They may not realize there are opportunities they completely missed.

It’s easy to do when you’re too are engaged in the game of feature parity. It’s a vicious downward spiral. If every company is only focused on reaching parity with their competitors, nobody is innovating or looking beyond the currently available features and functionality. Every product is working hard, only to look the same.

...Instead pay close attention to the competition’s customers.

Forming a deep awareness of the current competitor’s experience comes from studying the competition’s customers. That’s where the real competitive gold is found. When we meet with these potential customers, we can understand the nuance and subtlety of their experiences.

That understanding will reveal strong insights. Those insights could drive the competitor’s customers to switch to our product or service if we built something that truly embodied their needs.

We want to directly observe users and customers of our competitors’ designs. It’s from those observations that we’ll see places where the competitor has missed an opportunity. It’s a huge win when we find an opportunity that none of our competitors have addressed yet.

Also, when we watch our competitors’ users and customers, we see features and functionality our competitors have implemented well. We should note those instances closely. These insights can be useful in our experience vision.

Most importantly, we get the chance to ask these users and customers about what it is that makes the competitor’s products better. Why did they choose the competitor over ours?

We don’t want their users just to tell us why they chose a competitor. We also want them to show us. Directly observing users always yields the best insights for our experience vision.

We construct our competitive experience vision by looking at what we’ve learned from the current experience of both ours and our competitors’ users. We can map out the user journey, highlighting what’s frustrating and what’s delightful to our users.

Then we ask the question, “What would make for a delightful experience across the entire journey?” The answer provides us with an experience vision that increases the competitiveness of our product or service.

What true market leadership looks like.

The companies that chase their competitor’s features are always behind. They’re always trying to play catch-up to maintain parity.

When we do that, we are, at best, always guessing why the competitor thought a feature was a good idea. And we may never know if our guesses are correct. A company may only be copying a feature from another competitor just to maintain their own parity, not to meet their users’ actual needs. It’s an endless game that we can’t win.

Smart companies step away from playing the keep-up game with their competitors. They design their products and services to meet the true unmet needs of their customers. They solve customer problems that no other company is solving.

Organizations that are true market leaders don’t look at their competitors to stay ahead. Instead, they look deeply at their customers and users. That’s how they consistently deliver the best-designed products and services.

Grow The Understanding of Your Users' Experience With These 3 UX Tools

September 19, 2019

by: Jared M. Spool

Your UX team must always fight the insulation that builds up between folks who are making critical design decisions and the experience of your users. They need to be always surfacing a deep awareness of what it’s like to use your product or service.

Our go-to strategy for busting through the insulation and building deep awareness involves combining 3 straightforward UX tactics. We start with a solid discovery process, to generate the research that will form the basis of everyone’s awareness of the users. We then use journey maps to capture and understand what that research tells us. And finally, we show why this information is important, by generating a vision of what an improved user experience could be. By combining these together, we see a powerful and long-lasting change in how the organization makes important decisions.

Combining these tactics doesn’t come easily for even seasoned UX project leaders. Almost always, they’re suffering from a lack of expertise (and sometimes the confidence) to effectively frame the problems and lead their teams through the process.

That’s why we asked three UX experts, Dan Brown, Jim Kalbach, and Christine Perfetti, to walk us through exactly how to get the most out of each of these tactics. We’ve captured their advice in three online seminars, which you can easily share with your team.

Here’s what your team needs to know:

First, everyone needs to work together to understand the problem you’re trying to solve.

Dan Brown
Your team leaders have plenty of tools to choose from that articulate the challenges they’re facing. In Discovery: The First Step of the Design Process, Dan Brown takes your folks beyond the tools, explaining that the conversations between your team and influential stakeholders are far more important. They’ll talk through the work ahead and come up with that essential understanding of the problem.

Next, you’ll share what you’ve learned and infuse your organization’s culture with the user’s experience

Jim Kalbach
Jim Kalbach picks up where Dan leaves off, by using the creation of a journey map to catalyze the team’s understanding of your users. In Building Consensus by Mapping Experiences, you’ll see that there’s a magic that happens when you get the right people in the room, turning the discovery research into a narrative user journey. Suddenly, everyone is on the same page about what makes using your products or services frustrating, and what makes users delighted.

Then you’ll want to align cross-functional teams and stakeholders to a singular vision for your product

Christine Perfetti
The journey map tells us what it’s like to use the product today. But what could it look like tomorrow? Christine Perfetti walks through the steps to achieving team alignment on where to drive the future products and services in A User-centered Approach to Product Planning and Visioning. Your UX leaders will transform the design’s existing user experience into a compelling (and competitive) long-term vision.

Your team gets immediate access to Dan Brown, Jim Kalbach, and Christine Perfetti’s expertise when you subscribe to UIE’s All You Can Learn Library. For just $29 per month, you can start sharing these seminars (and the 363 others in the library) right away. (It’s easy to sign up, you can cancel without penalty, and it’s 100% guaranteed, so there’s no risk.)

Bust through the insulation. Develop a deep understanding of your users. Build a vision for well-designed products and services.

What are you waiting for? Start today. Subscribe to All You Can Learn.

The True Power of UX Goes Beyond Digital

September 16, 2019

by: Jared M. Spool

There’s a tendency to think that when we’re designing for a user’s experience, we’re only talking about applications, websites, and other digital products and services. Yet, UX design encompasses far more than digital design. It always has.

Last week, I was in Memphis, TN at St. Jude Children’s Research Hospital. I met with the UX team at the hospital’s fundraising and awareness organization, ALSAC. That team is responsible for the experience of people funding the hospital’s operation and maintenance. They’ve built out websites, applications, email campaigns, and any number of digital tools and services to make it easy to donate to St. Jude’s.

The UX team formed when ALSAC realized that building digital tools would be difficult. Before that, the organization hadn’t thought at all about designing donor experiences. It had never occurred to anyone to bring on a UX team.

Many organizations formed their first UX teams under the same circumstances. They hadn’t thought about user experience until they were struggling to deliver well-designed experiences.

That almost always happened as they were making their first forays into delivering digital products and services. This is why we meet people who think UX only is for digital, even though user experiences aren’t constrained to the digital product experience.

“As a donor, I want to make a donation.”

It’s easy to imagine how UX design will make a better donation process. Donating money is similar to online e-commerce or banking. After all, boiled down, it’s the process of transferring money from one bank or credit card account to another.

Yet, that’s a very limited view of the donor’s overall experience of making a contribution to St. Jude’s. A donation to St. Jude’s is much more than a payment transfer.

Making a donation is incredibly meaningful. For example, St. Jude’s focuses on child cancer and other life-threatening childhood diseases. It’s a research hospital and uses money that ALSAC collects to pay for the research.

St. Jude’s also uses money to assist the families of children. Families don’t have to pay for housing, travel, or food while to be there when a child is treated at St. Jude’s. That support helps families focus on their child.

Every donor is making a difference in people’s lives. While there’s a financial transaction underlying each donation, it’s a big mistake to see the design of the donor’s experience as only the moment of the transaction.

Experiences happen before and after the transaction.

St. Jude’s partners with local marathon events to raise money for the hospital. Runners who raise at least $250 in donations become a St. Jude Hero. Heroes who raise larger donations get rewards and benefits, including exclusive access to celebrity events and hotel stays during the marathon weekend.

The UX team has innumerable ways to craft great experiences for the Heroes running the race, the volunteers organizing the event, and the fundraising staff coordinating the volunteers. These marathon events take months of planning and attract thousands of participants.

There a large range of experiences before the first donation is collected. And the experience doesn’t end with the financial transaction. Every Hero wants to know how St. Jude’s used their donation. Plus, there are future fundraising events those donors might wish to attend, to continue supporting the hospital.

The entire experience, not just the digital bits.

To meet ALSAC’s mission of raising the necessary funds for St. Jude’s, the UX team must go beyond what the user experiences while interacting with digital products and services. Their design must include their audiences’ offline experiences too.

The UX research efforts must bring everyone at the organization a deep awareness of what each audience member’s experience is like today. When are those experiences frustrating and when are they delightful?

The UX content efforts must support every aspect of the experience, whether it’s online or not. The donors need tremendous support before and after they make their donations.

The UX design efforts must tie each audience member’s journey into a cohesive experience. It needs to feel connected from start to finish, making each donor feel valued and appreciated at every moment. The team couldn’t do this if they only focused on the digital components.

Nobody at St. Jude’s knew about user experience until they created their first online web site. Since then, they have needed to broaden their understanding of what UX is.

They had to expand their UX thinking to encompass the entire experience, from beginning to end. This broad view of UX is necessary to deliver well-designed products and services that meet the organization’s goals.

Deep Awareness of the Current Experience

September 10, 2019

by: Jared M. Spool

“Oh my, we DO make it difficult for our users, don’t we?” That’s what the Vice President of the team’s business division said as soon as the user research session ended.

The VP was stunned by how difficult it was for the user to on-board their product. It was the usual gamut of frustrating user experience issues.

The on-boarding process was complex. The user needed to enter information that they couldn’t easily get at that moment. There was jargon they didn’t understand. They were asked to make choices about features and options that weren’t explained.

What the VP expected to take about 5 minutes took more than 30 minutes. The user was completely frustrated and didn’t even want to try out the product once it was set up. “This is not a good experience!” the VP declared.

It was the first time the VP had ever sat and watched a user go through the on-boarding process. They had no idea it was like this for users. When the team told the VP that they’d seen many other users have similar problems, the VP sank into the chair.

The team then reported the product’s analytics showed most new users spent 30 or more minutes on-boarding. “This has to be our top priority for the next release!” the VP insisted.

The VP was now deeply aware of the current experience. And that changed everything.

The buildup of experience insulation.

UX professionals often complain that others in their organization don’t have empathy for the users and what the users go through. But how could they? When do they get exposed to the users’ current experience with the product or service? If they aren’t exposed, they can’t possibly form any empathy for those users.

When an organization is very small—I mean VERY small, as in 2 or 3 people—the executive team is very aware of their customers’ experiences. That’s because the executive team has direct contact with the customers every day. They have to just to survive.

If the customer is frustrated by something in the product or service, the executives know it right away. They make it a priority to fix, because survival depends on it. They have empathy for their users, because they are deeply aware of those users’ experiences.

It would be great if that could continue forever, but if the organization is successful, they’ll need to grow. They’ll add more people.

Some of those people will form the sales team. Others will handle customer support issues. Some will become developers and product managers. Others will become additional executives and key stakeholders.

With all these people, the original executive team is now distanced from their users. It’s as if, with every new employee, a thin layer of insulation forms between those executives and the customers. (And if the users aren’t the customer, there are layers of insulation forming there too.)

Once the organization has become an enterprise, the insulation is thick. And like good insulation, it prevents any awareness from penetrating. The executives, senior leadership, and the product team are now comfortably insulated from the users’ experience.

It’s not that our peers don’t have empathy for users. It’s the insulation that prevents them from exercising any potential empathy.

Busting through the insulation.

The first job of a UX leader becomes straightforward: Punch a hole through the insulation. Deliver a deep awareness of the current user experience. Let the executives, stakeholders, product managers, developers, and anyone else making key decisions experience what it’s like to be a user and build up their empathy.

Teams need to be aware of weak signals. These happen when customers complain to their salesperson or they ask for a new feature. Reports of customer calls to support are also weak signals.

Weak signals look like awareness. Unfortunately, they are shallow awareness at best. Design leaders do best when they direct research to explore these signals in more depth. If they can identify the underlying experience that triggered the complaints or requests, they can turn the weak signals into deep awareness.

It all starts with a serious user research program.

We’ve seen UX leaders fill their organizations with deep customer awareness that drives change. It’s not a fast process. It takes time.

They’ve all done it with a similar approach. They started by upgrading their user research capability. They got people into the field to see what their customers’ experience is like first hand.

And they couldn’t do this with only a select group of UX researchers. They had to bring product managers, developers, stakeholders, and even executives with them. These leaders had to make exposure to users a priority.

That all took time. Every UX leader we’ve met has told us they wanted to move that process much faster. They said it truly tested their patience.

That patience paid off, because, with a series of baby steps, more people were exposed to users. They were gaining deep customer awareness that drives change.

Making deep awareness a habit.

After upgrading the organization’s research capability, the next phase is to keep the awareness constant. It’s not easy in large organizations, where there’s a new crisis happening every minute that captures everyone’s attention.

To keep everyone aware of the experiences users were having, the UX leaders took several approaches. One common approach was to build customer awareness habits throughout the life cycle of team projects.

The beginning of new projects was a good place to start introducing these habits. Using a discovery phase that brought the entire team face-to-face with users sent a strong message about what their experiences were. Other techniques, such as starting projects with design sprints kept design and participating users in the forefront of people’s minds.

To build awareness habits throughout the duration of the project, UX leaders integrated advanced user research techniques, such as regular field visits for all team members, into the design and development process. They would show how teams who took the initiative to do this were producing better outcomes.

As they were learning about users experiences, the UX leaders would have teams build out journey maps and put together detailed scenarios. They’d make it habit to refer to these artifacts during any discussions of features or designs.

Deep awareness is the secret to growing design capability.

Everyone has empathy. (Well, except for sociopaths.) Which means the problem teams face isn’t developing empathy in their peers. The problem is how we can provide exposure opportunities to build that empathy.

We need to burst through the insulation that naturally builds up in our organizations. We need to create a deep awareness of what the current user experience is.

Once we have that, we can start painting a picture of what the future ideal experience could be. We can use experience visions to share the story of the experience we aspire to deliver. Executives, stakeholders, and product teams can compare that ideal experience to their deep awareness of the current experience. Here they build empathy and understanding, here is where the real magic happens.

It’s that difference that drives real change in the organization. The desire to improve frustrations and to make the product or service experience represent the real value we can bring to our customers and users. That’s how we drive our organizations to deliver better-designed products and services.

Lead your organization’s UX strategy.

To drive change in your organization, create a deep level of customer awareness to all levels of decision makers. The best way to do that is through a customized playbook strategy you make alongside your team during our 2-day Creating a UX Strategy Playbook workshop.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

UX Hiring is at the Core of Any Great UX Strategy

September 6, 2019

by: Jared M. Spool

As a UX leader, you have a prime directive within your organization: To increase your organization’s capability to deliver better-designed products and services. Every UX strategy you choose should achieve this goal.

Executing the right UX strategies will increase the value your UX team provides. Often, this increase in value will be rewarded with the opportunity to grow your team.

Growing your UX team also needs to follow this prime directive. Every new person you add to your UX team must increase your organization’s capability to deliver better-designed products and services.

Hiring must be every UX leader’s top priority

Too many UX leaders treat hiring as a side project. They see it as a distraction to their daily work.

Yet, adding the right people to your team is the best way to increase your organization’s overall design capacity. New people will sell the value of design throughout your organization. They’ll enable others to make better design decisions. And the customers and users will get better products and services.

Hiring has to be your top priority. You have to make it a priority even before you have an open position to fill.

You need to be thinking about what makes your next team addition valuable to the organization. You need to be building out your network of potential candidates to invite. You need a plan that shows how your new position makes the organization more competitive in the marketplace.

Make sure you’re hiring the best way possible

To ensure design leaders like you have the best possible hiring process, we’ve put together a UX Hiring Masterclass: Hiring The Best For Your UX Design Team. This online workshop walks you and your team through every step of the hiring process. Ensuring your hiring efforts will get you the best UX designers, researchers, content professionals, and managers.

In this seven-part workshop, you’ll learn how to identify exactly what will make an ideal addition to your team. We’ll walk you through the creation of the thank you note, to “sketch” the value of what your new team member could bring. You’ll learn how a performance profile ensures you have a clear picture of your ideal candidate and avoid serious hiring mistakes.

You’ll learn the best way to assess the UX skills, knowledge, and experience of every candidate. You’ll identify what you need to see from an ideal candidate. You’ll see how your team will make the most of every minute of every interview.

This online workshop is the perfect way to get your entire team on the same page. Together, we’ll make your hiring process effective and efficient. The price includes 35 detailed videos, practice exercises, and seven one-hour-long interactive coaching sessions with me.

You and your team will come away completely prepared to hire awesome new team members. There’s no better way to ensure you grow your organization’s capability to deliver better-designed products and services.

Find out more about the UX Hiring Masterclass: Hiring The Best For Your UX Design Team at HiringMasterclass.com.

The Thank You Note - A Sketching Tool For UX Hiring

September 4, 2019

by: Jared M. Spool

The first time we did it, it felt a bit weird. That’s because it is weird. After all, we’re writing a thank you note to an employee we haven’t hired yet. What makes this note weirder is we’re writing to thank them for their first year of accomplishments, which, of course, they haven’t accomplished yet.

It’s this set of future accomplishments that makes this such an effective hiring technique. We’re following the old design maxim of start with the end in mind and projecting out a full year’s worth of work for our next new yet-to-be-hired teammate.

We describe how those accomplishments benefited our team, our organization, our customers, and our users. We’re starting with the improvements we want to see, then deciding who we should hire to get those improvements. It seems logical, yet so many teams don’t do it this way.

Finding better-qualified UX candidates faster.

Many teams launch into the hiring process without doing an exercise like this. They don’t spend the time considering what their new hire will actually accomplish.

Those teams are very focused on getting someone hired. In many cases, they feel they’ll lose the open position if they don’t hire someone quickly. If the hiring process is too drawn out, they may miss good candidates.

Yet, when the team doesn’t take the time to identify what their new hires will accomplish, it creates severe hiring obstacles. Their job ads are either inaccurate or very general. Those ads won’t attract candidates who have the ideal expertise to accomplish what the team needs.

Job seekers won’t apply or will drop out of the process when they see a position that is poorly defined. People want to know what they’ll accomplish in their new job. Candidates get really excited about a position when the hiring team has clearly shown how their work will be beneficial.

The funny thing is most UX jobs are interesting. When teams take the time to describe what the candidate will accomplish if they’re selected for the job, the hiring process becomes much smoother. The best qualified candidates know how to surface their most relevant experience, which makes it much easier for the hiring team to find someone ideal for the position.

What the Thank You Note looks like.

Our thank you note is a sketch of what our position looks like. In design, we’re used to creating a rough sketch of a screen before we’d start coding. In the same way, we use the thank you note to sketch out our ideas for the new position.

For example, when we were helping a client hire a senior UX designer to lead a large design system project, here’s what our thank you note looked like: (Details changed to keep the company anonymous.)

Hi New Design Team Member,

Congratulations on reaching your 1 year anniversary. We’re so happy you joined us. You’ve made some awesome contributions over the past year.

We loved how you jumped right in and built a detailed UI component inventory. This gave us a complete picture of all the UI components we’re using across ACME Corp’s 30 products. It was a great start to showing the value of a design system. We could see how we’d save development costs by with a consistent UI.

It was also amazing how your UI component inventory got the various product teams on board. You provided solid evidence when you showed which components confused our product users, by working directly with the product research teams. Everyone can now see how a design system will make life better for customers.

You did a great job putting your design system delivery team together. It was brilliant to recruit front-end developers and designers from the product teams. That made sure those teams needs were represented in the system’s design and delivery.

The two pilot products you picked for the first version were excellent choices. Those teams are excited about the effort, even though they had real challenges we needed to overcome. It showed the rest of the organization how the design system roll-out could work.

Under your leadership, those two pilot teams’ will soon release new versions of their products using your new design system. Other teams are now excited to adopt the system for their upcoming releases. Recently, several teams built prototypes that came together in record time by using your design system.

Thank you for all you’ve done. We can’t wait to see what you do in year 2.

Thank you notes don’t have to be a literary masterpiece. They have one question to answer: How will our organization benefit by hiring this new person?

Showing how growing design helps the organization.

We love a short-and-sweet thank you note. It makes it easier to collect feedback from everyone who will work with the new hire.

Like a rough sketch of a screen design, the thank you note gives us a quick way to collect high-level feedback on what the new person will accomplish. Teammates and collaborators may suggest other accomplishments they’d like to see. They can do a sanity check that the new person will work on their highest priorities.

The feedback we get is great. The best feedback we’ve gotten came from a product manager: “You’ve been talking about this new position for months and I didn’t quite understand it until I read your future thank you note. Now I completely agree that we need someone on board right away to do exactly these things.”

We’ve found the thank you note is a fantastic tool to quickly show the benefits of growing our organization’s design capability. It demonstrates what each new hire will accomplish and how those accomplishments will benefit our team, our organization, our customers, and our users. It’s a vital tool for UX leadership to make a solid case for better design.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Hire better-qualified UX professionals faster.

You'll need to hire team members with the right skills, experience, and knowledge to build up your UX team's capability to deliver great designs. We can help you do just that.

We’ve packaged up our years of experience into an online workshop: Center Centre’s Hiring Masterclass. In this 7-part online workshop, you’ll learn how to craft performance profiles to define your new position, assessment criteria to ensure every interviewer knows what evidence to look for, and interview techniques to ensure candidates have a great experience. We guarantee this will get you quickly to job offers for ideal candidates.

Learn more about Center Centre’s Hiring Masterclass

Hiring UX Professionals: 3 Critical Mistakes to Avoid

August 28, 2019

As a UX leader, there’s an easy way to mess up an otherwise solid user experience strategy. All we have to do is hire UX professionals who do not have the skills, knowledge, and experience to do the job we need.

The inverse is also true. The best way to achieve our UX strategy goals is to hire UX professionals who have the right skills, knowledge, and experience that our team needs.

Hiring UX professionals is hard work. More importantly, it isn’t a topic we discuss often enough.

As a profession, we act as if everyone knows how to hire well. At Center Centre – UIE, our research shows many folks don’t.

Many UX leaders make serious mistakes while hiring. Mistakes that may push away the most qualified candidates while flooding our hiring process with people who don’t have the expertise our positions demand.

This increases the risk we’ll hire the wrong person, and take a long time to do so. These mistakes are often easy to avoid with a well-designed hiring process.

A tale of two interviews.

During our research, we met up with a seasoned UX design leader who had recently interviewed with a fast-growing startup. Before her interviews with the startup, she was attracted by the company’s initiative to build up their UX team.

Her first interview with the CEO went very well. They discussed how her experience creating and executing a UX strategy would be perfect for the position. The CEO was very receptive to some ideas she came up with. She left feeling quite energized and excited about the position.

She had a very different experience during her next interview with the Head of Product. The Head of Product told her that her work would primarily consist of producing wireframes and visual mockups. When she brought up the strategy work she’d discussed with the CEO, the Head of Product told her that wasn’t what the job would entail. The Head of Product wasn’t interested in her strategic ideas.

After the second interview, she withdrew from consideration. It was clear to her that the organization’s two leaders didn’t agree on what the job was. She had previous jobs like that. She felt she didn’t need the frustration that comes from not knowing what her job is.

The CEO and the Head of Product weren’t on the same page. It seems they hadn’t discussed upfront what their new hire would do once they arrived.

Many job seekers told us similar stories. It’s the number one reason people tell us they stop pursuing an opening.

Candidates often ask recruiters, hiring managers, and interviewers what their job would be if they were chosen. Often, nobody seems to know. Or everybody thinks they know, but has an answer that doesn’t agree with what others say it is. The candidate decides the potential job is not worth it and backs out.

UX Hiring Mistake #1: What work will the new hire do?

If it seems like nobody on the interviewing team has discussed this before, it’s because they haven’t. It’s extremely common for teams to start interviewing candidates without ever discussing the position amongst themselves.

When we’re working with UX leaders to build their UX teams, we start the hiring process using what we learned from Lou Adler’s Performance-based Hiring. Performance-based Hiring is a perfect approach, because it starts by defining the new position upfront. It feels natural to UX professionals because it’s a similar approach to what we do when we’re designing a product.

When using Performance-based Hiring, we start by creating a quick sketch of the new position. What will the new hire accomplish during their first year? What benefits will their work deliver their team? We often craft this in the form of a thank you note that we write our new hire, on their 1-year anniversary.

We can use the thank you note as a validity check. We circulate it amongst the hiring team and the people who will work with this new person, once hired. We ask: Is this what we need the new person to accomplish in their first year? Are these the right benefits from their work? Is it too much? Too little?

With that feedback in hand, we then write up a more detailed description, which Lou calls a performance profile. A performance profile is a job description on steroids. It’s a detailed list of every major objective that our team’s newly-hired member will accomplish during their first year.

We invite everyone involved in hiring this position to work on crafting and reviewing the performance profile. Since they have a hand in performance profile creation, they’ll give the same answer about the job is when a candidate asks.

Every position has different needs.

A UX team had three open positions for senior UX designers. Their initial inclination was to create a single job description for all three positions. After all, one senior UX designer is just like the others, right?

Not in this case. The accomplishments for each new designer during their first year would be dramatically different from each other.

The first senior UX designer would lead the integration of a new design system across the organization’s 30 products, working with product teams all over the globe. This senior designer would need extensive experience with design systems and have skills in persuasion and diplomacy, as some teams are not excited about migrating to the new design system.

The second senior UX designer would join a team to migrate their 15-year-old, 1,000-screen desktop application to mobile. They would be the only designer among 100 developers, so this would take incredible leadership skills.

The third senior UX designer would join another team whose market-leading product is facing their first strong competitor in a decade. The competitor is beating them by delivering a simpler, easier-to-use product. This team has never thought about UX before. The newly-hired senior designer will need to teach them everything, from research to interaction design.

Had the team used a single job description for each position, they could have easily hired the wrong people. Someone with the experience necessary to successfully roll out a sophisticated design system project wouldn’t likely also be deeply experienced in training teams to think about their users for the first time.

UX Hiring Mistake #2: Posting a generic position

Each position needs a unique description. We crafted a unique performance profiles for each one.

In each position’s profile, we wrote up the major objectives for the person who would eventually do the work. Because the work was so different, there was almost no overlap between the three positions. They were similar by the title of senior UX designers only, not by the work involved.

We wrote three different performance profiles. Then, we wrote three separate job ads. Because we had the written objectives, we could craft a different ad describing that position’s project details.

The ads did a great job of attracting highly-qualified applicants. Many of those applicants had the specific skills, experience, and knowledge that the position called for.

This made interviewing substantially easier. The team filled each position with someone very different, but perfect for their new job.

Who assesses the candidate assessors?

An interviewer’s most important job is to determine if a candidate has the skills, experience, and knowledge to do the job. Yet, during our research, we heard repeated stories of interviewers who didn’t seem to have any idea how to do that.

There were stories about candidates who were asked about experience that wasn’t mentioned in the job ad. For example some interviewing for a position advertised as a UX researcher were asking a candidate about their coding skills.

Candidates told us they were also asked to solve design problems that had nothing to do with the work. For a company whose product is a health practice management software, they were asked to design an elevator control panel for a building with 5,000 floors (nothing to do with healthcare software).

The candidates told us interviewers spent a lot of time on seemingly unimportant things while ignoring more relevant topics. For example, some interviewers would fixate on how a candidate used specific design tools. Or they’d have the candidate spend most of an interview describing an ideal design process. Yet, those same interviewers hardly discussed how the candidate had solved relevant design problems or performed comparable work.

In many organizations, interviews were highly repetitive. We heard about teams where each interviewer asked identical questions, covered the same ground, and, yet, missed hearing about large portions of the candidate’s work experience.

To make matters worse, after those interviews, many candidates were told they didn’t qualify for the job because they were missing requisite experience. Yet, in many cases, they did have good experience, but the interviewers never asked about it.

Unprepared interviewers make the hiring process longer and push away qualified candidates. Unfortunately, most teams do very little work to make sure every interviewer is prepared effectively.

UX Hiring Mistake #3: Interviewers aren’t prepared.

To prepare interviewers, we start with the position’s performance profile. Working through each objective, we carefully identify all the skills, experience, and knowledge we expect to look for in our candidates.

Each major objective in the performance profile is assigned to a specific interviewer. During their interview with each candidate, interviewers work to learn about the candidate’s comparable past experience. What evidence does the candidate have from their past work that shows they can do what is necessary for this job?

Each interviewer has a different set of questions. For example, let’s say we’re hiring the senior UX designer who will roll out the large design system project. One interviewer would own the position’s major objective of conducting a UI component inventory—the process of identifying all the user interface components used across all the products. (A massive job when your company has 30 mature products, each designed and developed without consideration of the others.)

To determine candidates’ comparable past experience developing UI component inventories, that interviewer would ask these questions during their interviews:

Tell me about a time you had to inventory all the components across many different products?

What was your inventory process like?

How many products did it involve?

How did you record your results?

How long did it take to inventory one product?

How long did it take to inventory all the products?

What was the most difficult part?

How did you overcome that difficulty?

Who else did you work with on the inventory?

If you had to do it again, what would you do differently?

... and so on.

Another interviewer would own the position’s major objective to coordinate the integration of the design system into the 30 products. They’d look for comparable past experience with these questions:

Tell me about a time you had to convince multiple product teams to adopt a design system?

Walk me through the timeline of what happened.

How many products were involved?

How did you get the first team do adopt the design system?

What lessons did you learn from that first team?

What did you differently in future teams because of what you learned?

Which team was the most difficult to work with?

What made them difficult?

How did you overcome their obstacles?

How long did the entire roll out take?

... and so on.

Candidates love questions like these because it feels 100% relevant to the position. They can see exactly what the organization is seeking in their new hire. And when the candidate has comparable experience, they get very excited to tell their story to someone who is genuinely interested!

By using the position’s performance profile as the preparation tool for the interview, interviewers make better use of their time with each candidate. The team learns more relevant information and they better identify highly-qualified candidates.

An intentionally-designed hiring process.

The three critical mistakes we’ve discussed here all stem from one root cause: The team hasn’t designed their hiring process well enough.

With performance-based hiring, we overcome these critical mistakes. We use each position’s performance profile to ensure every interviewer knows what they’re assessing the candidates on, how each position is different, and how to tell candidates what they’d do once hired.

Avoiding these three critical mistakes also attracts better-qualified candidates and ensures that the person hired will be a fantastic addition to the team. This is essential for UX leaders who need to build up their organization’s capability to deliver better-designed products and services.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Hire better-qualified UX professionals faster.

Building up your UX team’s capability to deliver great designs will mean you’ll need to hire team members with the right skills, experience, and knowledge. We can help you do just that.

We’ve packaged up our years of experience into an online workshop: Center Centre’s Hiring Masterclass. In this 7-part online workshop, you’ll learn how to craft performance profiles to define your new position, assessment criteria to ensure every interviewer knows what evidence to look for, and interview techniques to ensure candidates have a great experience. We guarantee this will get you quickly to job offers for ideal candidates.

Learn more about Center Centre’s Hiring Masterclass

5 Strategies for Increasing UX Design Literacy

August 22, 2019

It’s challenging work to deliver a well-designed product or service. It’s even more challenging to deliver great work when those around us struggle to understand what user experience design and research are.

The developers, product managers, stakeholders, and executives we work with influence our products and services. When they understand who our users are, what those users need, and how solid UX design and research contributes to the team’s success, we do our best work.

However, when those folks don’t understand what we do, our work becomes much more difficult. We have to review every design element. We have to argue for why certain functionality will provide a better user experience. We are brought into projects too late when critical decisions have already been decided.

As a UX design leader, you need to focus on increasing your team’s UX design and research literacy. You need to look beyond the day-to-day grind of tactical UX work and build a strategy that ensures delivering better-designed products and services.

You’ll come home from our Creating a UX Strategy Playbook workshop with a playbook designed to increase your team’s UX design and research literacy. We focus much of this 2-day, intensive workshop discussing the right literacy strategies that will fit your current situation.

Blending design understanding into day-to-day work.

Many of the 130 UX strategies we discuss are specifically focused on improving UX design and research literacy. Here are five strategies that many UX design leaders have chosen for their own teams’ playbook:

Strategy 3.02: Institute Putting Work on the Walls—All too often, UX design work is out of view of the rest of the team. By displaying team member’s work-in-progress in a public place, often accompanied by quick-and-dirty design reviews, everyone can see the thinking that went into your team’s design work.

Strategy 2.35: Institute Creative Mini Briefs—This strategy makes a small change to every meeting, by starting with the recitation of a short description of the design problem the team is solving and who they’re solving it for. A small ritual that reminds everyone to build for the users.

Strategy 3.08: Institute Regular Design Studios—A collaborative exercise that introduces team members to design’s problem-solving aspects. Colleagues get an inside look at the process of design, while giving it a try themselves. It’s a brilliant way to demonstrate that design is a team effort.

Strategy 3.07: Institute Regular Design Critique—When done well, there’s no better way to learn design practice’s subtlety and nuance. As each team member takes their turn presenting their work, the rest of the team picks up on a process that shows how ideas progress from concept to finished work.

Strategy 3.16: Institute Separating Critique from Design Reviews—Design reviews are about moving the design forward, whereas critique discusses the journey of getting to this point. Separating these two activities promotes team learning.

These are just a sample of the many successful UX strategies that design leaders choose from during our Creating a UX Strategy Playbook workshop.

Creating a culture of continuous learning.

A big piece of a UX design leader’s responsibility is making a strong contribution to a culture where everyone on the team is constantly learning. This isn’t building a classroom or a school. It’s a slow, methodical integration of design education into everyone’s work experience.

We built the Creating a UX Strategy Playbook workshop to give design leaders like you the tools to make that happen. You’ll come home from the workshop energized to drive your organization to the next level of design maturity.

Find more information at Playbook.uie.com.

Or contact us to bring the workshop into your organization.

The Powerful Ritual of Daily Design Review

August 15, 2019

Even though I expected it, I was stunned when I turned the corner and saw it. Along one wall of the 20-foot-long corridor we’d just entered, there were rows and rows of crudely attached screenshots.

Each screenshot was a screen from the project’s large enterprise application. Each row was a sequence of screens the user would experience.

Screens were taped on top of other screens. Every time a screen was updated, the developer would tape it on top of the previous version. Some screens had been updated 10 or 20 times, and the paper stack fluttered as people walked by.

The corridor was visually stunning. It was a living description of what it was like to use the large, complex application.

The daily design review meeting.

The screenshot corridor was a by-product of a daily design review meeting. One-by-one, as the meeting convened, the project’s front-end developers would approach the wall. They’d scan it to find the pile of older versions of the screen they’d been working on.

Once they find it, they’d tape up today’s version right on top. Then they’d look around to review what the other front-end developers had just added to the wall.

There were a hundred developers on this project, spread across ten scrum teams. Six of those teams were working on user-facing code. It was the front-end developers from those teams that came to this voluntary meeting each day.

Running the meeting was the only designer assigned to the project. “Ok, who wants to start?” the designer said.

One of the developers said, “I’ll go,” and walked over to describe their screen. Taking turns, the developers would stand by their new screens, describing the work they’d done since the last meeting.

They’d describe the interactions they added, and how those served the user stories they’d been working on. They’d describe the challenges they’d encountered and would ask the assembled group for advice on particular questions that had come up.

The developers start learning design skills.

The ritual of this design review meeting repeated each day. The designer would round up the designers from their work pods and start the 20-30 minute review.

At first, it was clear these front-end developers lacked any practical design expertise. Their screens were chaotic and function-driven. They didn’t really think about their users.

“On those first screens, it looked like the developers had just barfed the database schema onto the screen,” the designer told me. Related fields weren’t grouped together. There was little sense of a grid or alignment. All the problems you’d expect to see from developers who were never trained in user interface design.

Each day, after a developer would present their latest iteration, the designer would run a small critique session. What was working well about the screen? How might they improve it?

This was why the developers came to the meeting. They were craving constructive feedback and they got it in spades. The developers said they learned as much by looking at their peer’s designs as they did collecting feedback from their own.

The discussion taught them vocabulary and principles of design. What happens if we put the “done” buttons in the same bottom-right corner on every screen? What if we always placed labels to the left of each field? What if data fields were grouped by their relationship, instead of presenting the order they were listed in the database schema?

Over time, each developer started improving. Their screens were demonstrating the basic principles of UI design. Their critiques became more nuanced. These developers were learning design skills.

The hallway became a project-wide resource.

The screenshot corridor was a busy thoroughfare. It connected the lobby with a popular meeting area.

Along with the 100 developers and 1 designer, the project had 12 technical leads, 10 business analysts, 6 product managers, and 2 product owners. These folks often transversed the corridor. They saw the updates every day.

It was quite common for other meetings to end up in the corridor, looking at the screens on the wall. They became a resource to answer questions or discuss issues. Having something to point at become important.

On the opposite wall, other important project information began appearing. The system’s architecture diagrams showed up first. Then several long user journey maps, showing the sequence of complex interactions. These became important reference tools for everyone.

The hallway wasn’t just a place people passed through to get to their meetings. It was a corridor of education. It was instrumental in delivering a great application.

The educational value of daily rituals.

It was amazing to see the power that a daily routine could have. A daily 20 to 30 minute voluntary meeting, held in a public hallway, was changing the quality of UI designs throughout the project.

Everyone could see the progress they were making. They could see how their own screens were improving. They could see the smart ideas their co-workers were coming up with.

Nobody asked for permission to do this. The team's one designer just decided to make it happen. They put those first screens on the wall and the ritual began.

Often, this is how we see teams improve their design capability. They don’t do it through grand declarations of some new acronym-named design process. Teams improve their capability through small baby steps. Even if it is for only a few minutes, implementing small daily rituals that put design at the top of everyone’s agenda is a step in the right direction.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Imagine the Perfect UX Strategy for Your Organization

August 8, 2019

Imagine: You arrive at your office some morning. You’re carrying the perfect user experience strategy for your organization. You’ve worked hard on this strategy. It hits all the major points.

Your strategy will move top organizational priorities forward. And it’ll do so with the complete support of your UX team and the leadership.

The strategy you have with you that morning will show your leadership and other important stakeholders the true value of good design. It’ll be exciting to see everyone applying UX research insights into important decisions. Your organization will deliver better-designed products and services than it ever has before.

That’s exactly what will happen when you return to work after our Creating a UX Strategy Playbook workshop. You’ll walk right into the building, proudly carrying the UX strategy you came up with during the workshop and it’ll do all that.

Get leadership buy-in.

Imagine you’re not the only one coming to work with that strategy. There’s a team of you.

And not just any team of you. You brought critical stakeholders to the workshop. They are just as excited as you are to execute this strategy.

These folks who are leaders from your product, development, marketing, and support organizations didn’t quite know what to make of this workshop at first. They weren’t that knowledgable about design before they came. But now they get it.

During the two-day workshop, they worked with you, carefully selecting the right strategies that will most benefit your organization right now. They never realized before how much of a role UX design can play in every decision they make.

They now appreciate good design in a way they’ve never seen before. And they’re ready to work with you, as a power team, to make big changes in your organization.

You’re all more excited about what’s to come than you ever have been before. All because you and your power team spent those two days at our Creating a UX Strategy Playbook workshop.

Change your organization.

Imagine walking into your office, completely focused on how you’ll drive big changes across your organization. Changes you’ve never been empowered to make before. And, now you can because you’ve got the right UX strategies.

You and your power team will demonstrate the value of design. You’ll show what it can do to improve your customers’ and users’ lives. Customers will be so impressed with the products and services you deliver, it’ll propel your organization to be the next market leaders.

You’ll know exactly how to inform important decisions throughout the organization by extending your UX research capabilities. And your team’s work will ensure critical decisions aren’t cast in concrete until there’s solid research to support them.

Most importantly, you’ll see design skills start to grow across the organization. Folks who have never understood design are starting to make smart design decisions.

They’ll start making sketches and mockups of their ideas, which will be informed by actual user research. Suddenly, your most senior designers will have time and space to tackle the really hard problems that no-one (inside or outside of your organization) has ever tackled before.

Imagine all the good that comes from this.

You don’t have to imagine all this. You can sign yourself and the other leaders you work with for our next Creating a UX Strategy Playbook workshop.

We’ve got two scheduled for Chattanooga TN and two for Australia. Soon, we’ll be launching our European and UK 2020 dates.

It may sound cliché, but these workshops are career changing. You and your power team will not come back the same.

You don’t have to imagine your organization embracing UX design. You can have the UX strategies to make it happen.

I’ll see you at a workshop soon! Imagine how awesome that will be.

We keep these workshops small, at 24 or so attendees in each one. If you’re planning to come (and bring a small team with you), you’ll want to sign up soon.

UX Strategy is a Long Game, But Worth Every Moment

August 2, 2019

When I talk with UX design leaders about implementing UX strategies, the biggest surprise they have is how long it takes before they’ll see results. They’re shocked (and a little disappointed) when I tell them it’s likely they won’t see any real movement for months. It could even be years before they’re close to accomplishing their objectives.

In today’s world, we’re always trying to do things fast. The shift from waterfall to Agile pushed us to think in terms of sprints that only last a few weeks.

We used to take a year or more to ship a new release of a product. Now new releases go out quarterly, monthly, or even daily. (Some organizations release new features multiple times per day.) The notion that we’d take a year or more to implement a UX strategy can seem like forever against the backdrop of today’s fast-moving product and service delivery efforts.

Implementing a UX strategy takes time.

When we think about implementing a round of usability testing or producing wireframes for a design, we’re used to those activities taking a few weeks or maybe a month to do, if there’s a lot of work. Those are tactical UX activities. A project’s tactical UX activities are what we do to improve the design of a specific product or service.

UX strategy is different from UX tactics. UX strategy is how we improve the design of all the products and services. It’s about systemic change across the organization.

For example, if we’re introducing a strategy to drive more decisions from user research, we need to go beyond a single research study. Instead, we need to consider how continual research will influence every decision. Building a continual research capability is a big job.

UX strategy involves significant changes in our organization. Those changes will take time to come to fruition.

The importance of end goals, baselines, and champions

A good UX strategy has an end goal in mind. The end goal is how we’ll know when our strategy has been effective at making change in the organization. It answers the question, “If we do a good job of implementing this strategy, what good things will we see as a result?” This is the journey of our strategy.

Because implementing a UX strategy often involves changing an organization in subtle ways, it’s hard for design leaders to see the progress they have made.

Establishing a baseline of what the team or organization is doing today will give us perspective on the subtle changes that happen over time. We can stop at any point and ask the question, what are we doing now that we weren’t doing before we started our journey?

Along our journey, we’ll need support. That support can come from champions who will also benefit from the UX strategy. The best champions have different influence in the organization than us, giving us more ways to keep the organization on track as we implement the strategy.

It’s a game of patience and persistence.

It’s almost impossible to make big changes happen all at once. Instead, design leaders will need to break the efforts into baby steps.

For example, when a strategic goal is to get everyone to use research when making decisions for their product or service, we can start to meet that goal by providing one team with the research they need for an upcoming project. We then use that one team as a pilot to understand what future teams might need, allowing us to learn as we go about implementing our strategy.

It’s important to give ourselves the room to learn as we implement our strategic goals. Not every baby step will be successful. Sometimes we’ll face setbacks. Design leaders need the patience to deal with setbacks and they’ll need the persistence to learn from the failures and try again.

It’s a lot of work to implement a UX strategy. However, the benefits are clear when we do. Our organization is now ready to deliver better-designed products and services. That’s why we took on the challenge to implement one, to begin with.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

The Making of an Organization-Changing UX Strategy

July 31, 2019

The thing I spend the most time talking about these days is user experience strategy. In workshops, coaching calls, and discussions with UX design leaders, the conversation frequently revolves around building a great UX strategy.

A UX strategy is a type of business strategy that drives the organization to deliver better-designed products and services. It’s about mustering all UX resources an organization can bear with the primary goal of improving the lives of the organization’s customers, employees, and other users.

There are other types of business strategies. There are marketing strategies, sales strategies, financial strategies, and operational strategies. UX strategies attain value for the organization by improving the experiences of the users.

U.S. airlines, for example, have made many strategic improvements in recent years, but few of them have been UX-related. They’ve reduced costs by eliminating in-flight amenities, purchasing less expensive fuel options, and renegotiating union contracts that lower salaries and benefits of line employees. They’ve increased revenue by implementing baggage, priority boarding, and other customer fees. They’ve also raised average fares through restructured economy-class and business-class offerings.

All of these strategies helped the airlines reach record-breaking profits. None of them improved the experience for passengers or even most airline employees.

One could say they were all excellent strategies, in that they helped the businesses reach their goals. Yet, they were not UX strategies, because they did not result in better-designed products and services that improved the lives of users.

The essential 3 components for crafting a UX strategy.

The first component for crafting an organization-changing UX strategy is at the end. What is the improved experience for our users? Everyone who will approve, champion, and drive the strategic initiatives needs to know the specific outcome the UX strategy is seeking.

Knowing the specific outcome is something all business strategies need. What makes a UX strategy unique is that its outcome is an improvement to the users’ and customers’ experience, whereas other types of strategies are focused on changes like increasing sales or decreasing costs.

However, improving the users’ experience must provide some benefit to the organization, or it’s not a strategy worth pursuing.

These days, organizations are turning to UX strategies to improve their competitiveness. Customers who have better experiences will pay more and stay with the product or service longer.

The second component for crafting an organization-changing UX strategy is the organization’s increased benefit. What will change in the organization because we deliver better-designed products and services? Design leaders must connect the dots between improvements to the users’ experiences and benefits to the organization.

To change the organization, the UX strategy will need the third component: resources. How will the organization muster all the UX resources, knowledge, experience, tools, and techniques to deliver better-designed products and services?

Strategies are essential, ongoing efforts that are most effective when executed by the organization’s employees. Few UX strategies are achievable with outside consultancies. Hiring another company to execute your strategy on your behalf rarely pays big returns, yet often costs substantially more than building the in-house team.

It’s possible the organization already has all the skilled people they need. More likely, however, they’ll need to bring new skills in-house. Design leaders build skills by training existing teams in UX practices. They add more designers and researchers into day-to-day activities. Over time, design leaders ensure every new hire in the organization comes with UX design and research skills.

These are the three essential components of any UX strategy: the improvement to the users’ experience, the benefit delivered to the organization, and the resources required to achieve success.

The language of UX strategy is not a UX language.

The audience for a UX strategy is decision makers. These are the folks in the organization who will approve and support the strategy’s initiatives. If they don’t understand the strategy, it won’t happen.

New UX design leaders frequently believe that these decision makers need to understand how to speak about user experience. It makes sense, but it’s a mistake.

When design leaders attempt to teach decision makers about design, the effort fails immediately. The decision makers are often saddled with misconceptions, like design is something that is about making things pretty or done at the end of the process. They’ll resist learning to see design differently. If that’s the only approach, the conversation will end there and the strategy will go nowhere.

Smart design leaders realize decision makers already know how to make strategic business decisions. Instead of forcing them to understand design, UX design leaders need to learn how the organization’s business leaders think about strategy. They need to talk about their UX strategy in terms of how the decision makers already think. The language of a UX strategy needs to be the language of business strategy.

An organization-changing UX strategy faces challenges.

Let’s talk about what a UX strategy might look like for a major U.S. airline. In particular, let’s look at the experience travelers have when their flight is delayed or cancelled. This is a prime opportunity for improvement.

Let’s start our hypothetical situation saying the UX research team quickly identified this problem and the airline’s executive leadership understand that travelers complain about it. Yet, few people beyond the researchers know what it’s really like for many travelers or what could be done about it.

Techniques like increased exposure and tools like journey maps will spread an understanding of the current experience through the organization. Crafting and sharing an experience vision will give the airline’s executive leadership an understanding of what a dramatically improved traveler experience could be.

To connect this improved traveler experience to the needs of the business, the UX design leaders would share how the organization is currently paying for any frustration the inconvenienced travelers encounter. All frustration shows up in an organization’s bottom line.

In this case, customer service queues increase whenever a flight is cancelled. Passengers either wait in long lines or on hold, possibly missing other flights they could’ve taken. This creates confusion at the airport and frustration with the passengers.

Tying the improvement of the traveler’s experience to measurable business outcomes is a key component of this UX strategy. How might a better-designed customer service process for rebooking stranded passengers reduce hold times and long lines? A shorter process would reduce the need to have available agents ready to handle storms and mechanical failures. It would increase overall customer engagement that would, in turn, increase loyalty and word-of-mouth marketing.

What will it take to deliver the improved customer service experience for travelers? What skills do the teams working on customer service systems have to solve this problem?

A problem like this occurs across a variety of UX design resolutions. Do they have the skills to do the research? The design work? To measure the outcomes?

Will new resources be needed? Can the organization train the existing teams to handle these new efforts?

If the airline can overcome these challenges, they’ll deliver an improved experience for distraught travelers. While such a strategy will be hard to achieve, the benefits would be huge. That’s what makes a UX strategy compelling—it delivers big rewards for the hard work.

UX strategy becomes increasingly important as the organization matures.

A UX strategy has to be hard. If it were easy, we wouldn’t need a strategy for it. We’d just do it.

UX strategy isn’t something we need to think about when our UX design and research efforts are nascent. Once we’re ready to make organizational change, we need to think in terms of strategy.

Often, though, change happens much later than it should. And that creates more challenges when we try to introduce UX strategy into our organizations.

When the user experiences of our products and services have been neglected for a long time, we don’t a sophisticated UX strategy to get big gains. Our strategy can be as simple as hiring a few designers and letting them loose to clean up the messes, like Dr. Suess’s Thing1 and Thing2.

Unfortunately, this quickly devolves into reactive design. The UX designers are only reacting to designs put in front of them to clean up. They don’t get to drive the design from the beginning of the process.

Shifting to a proactive approach to design means thinking about changing the organization. This is where crafting and promoting UX strategies start to pay off.

An initiative to build ever bigger UX strategies helps the organization realize there’s an alternative to the other types of business strategies they’ve been employing. It gives executive leaders a new approach to increase competitiveness and attain critical business objectives.

UX strategies add a new tool to the business toolbox: the power of well-designed products and services.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Crafting your first UX strategy is challenging to do. Our intensive Creating a UX Strategy Playbook workshop, gives you a speed boost. In just two days, you’ll walk away with a solid plan for how you’ll connect the dots between great experiences for your customers and users and the needs of your organization.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

Integrating UX Metrics Into Your UX Strategy

July 25, 2019

UX metrics are an essential component of your organization’s user experience strategy. As a design leader, you need to track your progress, show where you’ll return big value, and identify opportunities for competitive advantage. The only way to do this is to integrate UX metrics into your overall UX strategy.

We spend much of our Creating a UX Strategy Playbook workshop talking about how to integrate UX metrics into a UX strategy. As a design leader attending the workshop, you’ll identify the most important measures to track. You’ll choose the best approach to collect and report what you’re seeing to the rest of your organization. Most importantly, you’ll learn effective ways to use these metrics to deliver better-designed products and services.

It starts with clearly knowing your UX goals.

UX metrics show your progress for delivering better designs. To show progress, you need to know where you’re going. The first thing you’ll do in the workshop is choose the right strategies for identifying your end goal.

We start the workshop with a discussion of your most important definition tool: an experience vision. An experience vision tells the story of what your ideal product or service’s user experience will be. You’ll tell the story in terms of the delightful benefits you’ll deliver to your customers and users. The story clearly shows how, by delivering these benefits, your organization becomes a market leader.

It’s from your experience vision that you’ll establish the target for your metrics. This is where, as a design leader, you’ll drive your organization to success. You’ll choose the best strategies for identifying the targets and communicating them for everyone to see. Once everyone in your organization is heading towards the same end goal, it’s easier for you to lead them in the right direction.

You’ll need strategies to measure your UX progress.

Much of the workshop is about collecting the right information and analyzing it. You’ll learn important tools, like how to upgrade your research capability with the Kano Model. The Kano Model clearly points out opportunities for improvements, often missed by your competitors, that will delight your customers.

You’ll select the right mix of subjective and objective measures to track the progress of your UX strategies. You’ll choose from an array of behavioral and attitudinal measures, giving you the best picture of what it’s like to be today’s customers and users of your products and services. These measures set the starting point for your organization's journey to your target experience.

Great metrics tell a story everyone can get behind. You’ll choose strategies to turn your metrics into fantastic stories and turn your design team into compelling storytellers. Metrics make stories irresistible, which is your essential lubricant for leading design in your organization.

A strategy workshop with measurement at its core.

When you return to work from the Creating a UX Strategy Playbook workshop, you’ll know exactly how to integrate UX metrics into your overall UX strategy. You’ll have established, critical targets to achieve. You’ll know how to communicate with your organization’s leadership about the progress of your initiatives. And you’ll clearly show the benefits that great design brings to your customers, your users, and your business.

That’s why you and your design team’s leadership need to be at our next Creating a UX Strategy Playbook workshop. This is how you’ll drive your organization to consistently deliver well-designed products and services.

A Fundamental Mind Shift For Usability Testing

July 18, 2019

A few days ago, I was watching a user experience expert deliver an interesting talk to a conference of UX professionals. (I do this quite a lot, as I’m always looking for new experts for our All You Can Learn UX video library and future events we might host.)

The presenter was doing an excellent job, making some solid points. I found myself nodding in agreement with every great idea I heard.

Suddenly, the presenter felt the need to impress upon the audience the importance of user research. They said, “You don’t need a big project. A small usability test is all you need. Studies have proven that, with only five to eight users, you’ll find 85% of all the problems in your design.”

My immediate thought: Noooooo! Really?!? It’s 2019. We don’t say this anymore. We never should’ve said this.

This idea, that five to eight users will reveal 85% of all usability problems, is an old myth. It’s not true. It’s never been true.

The origins of the five to eight user myth

In 1990, Bob Virzi published a paper, Streamlining the Design Process: Running Fewer Subjects, suggesting that for many designs, you could get away with running a usability test with 4 or 5 participants. He had shown a handful of studies where he had ten to fifteen users, but most of the problems showed up in the first four or five. He declared that, if you wanted to fix the obvious problems, that’s all you needed.

In 1993, Jakob Nielsen and Thomas Landauer built on Virzi’s suggestion and tried to refine the mathematical curve, in their seminal paper A Mathematical Model of the Finding of Usability Problems. Their goal was to find a formula that would tell you how many participants you might need to find 85% of your design’s problems.

Nielsen and Landauer analyzed five usability-testing studies and determined the maximum number of users you needed was eight. They didn’t analyze all usability test studies ever done in the world, they just analyzed five.

Yet, Virzi, Nielsen, and Landauer’s ideas for creating a sample-size prediction formula evolved. It became an untrue rule that you only ever needed five to eight users, no matter what the design was, who the users were, or any other factors.

There was no science saying this. But (almost) everybody believed it. The myth became quite popular.

As often happens, many researchers (including me) published papers to dispel this myth. Even Virzi, Nielsen, and Landauer went on to explain that you couldn’t jump from their findings to the claim that you’d find 85% of all problems.

Yet, the myth persisted. And still persists today. (Or at least, until a few days ago.)

Things have changed in the last 29 years

One of the usability studies that Nielsen and Landauer analyzed was of Microsoft Office, a 3-year-old product with about a million users. Today, a product with a million users would be considered small. Facebook says it has 2.5 billion users interact with its product every month.

Yet, even though the biggest products have grown 2,500 times the size in 1990, the myth hasn’t changed. The myth is still that you’ll only ever need five to eight users.

Now, some folks have morphed the original myth. They say it’s five to eight users per testing iteration.

OK. Let’s say you’re lucky enough to get ten iterations. Five to eight users for every ten iterations is still only fifty to eighty users total. This number won’t make a difference when you have hundreds of millions or billions of users.

A fundamental shift in how we think of user research

The big problem with the five to eight user myth isn’t its mathematical impossibility. It’s that it misrepresents the true value of user research.

User research, which usability testing is but one technique, isn’t about identifying all the usability problems in a design. Thinking about it that way reduces user research to being an extension of quality assurance—only finding the flaws we can fix.

The real value of user research comes from increasing our understanding of who our users are. The product or service team should better understand our users with every study, every interview, and every interaction they have. They should constantly increase their understanding of what those users need and the contexts the users work within.

Moving from reactive to proactive research

The best UX leaders understand research this way. They see that usability testing is the least mature UX research method.

Usability testing is, at best, a reactive technique. The developers build something, then we test to see what flaws they built into it. We iterate as they try to remove flaws, but we’re always reacting.

Most UX leaders realize they need to move to a more proactive approach. To do this, they must grow the UX design maturity of their organization.

Getting the organization hooked on meeting our users’ needs

We can say that usability testing, at best, is a gateway drug. But if we focus on only finding problems and not learning more about our users, we’ll never get our teams hooked on the biggest value of user research.

Instead, we’ll lock them into this mindset that user research is just a variation of QA testing. That it’s about finding bugs, not about delivering better-designed products that truly meet users needs, whatever those needs are.

We need to move away from the problem-finding mindset. The teams that know everything possible about the users are the ones that deliver the best-designed products and services. That’s the mindset change we need.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

As we raise our organization’s awareness of what well-designed products and services look like, we need to have solid strategies around how we collect the best feedback from our customers and users. In our 2-day, intensive Creating a UX Strategy Playbook workshop, I’ll work with you and your team to identify the best strategies for building a comprehensive user research approach, that shows where your products and services need to go to become (and stay) best-of-class.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

Unconventional Techniques for Better Insights from Satisfaction Surveys

July 17, 2019

“We want to hear from you.”

“How did we do?”

“Tell us how we’re doing.”

“How was your experience?”

Every week, it seems, we get a new batch of feedback surveys. Organizations want to know how we feel about the interactions we had with their products and services. They ask for “Just a quick moment of your time” to fill out a “brief” survey about the experience.

Until recently, design teams haven’t shown much interest in these types of surveys, as they mostly have been about marketing the product, not designing it. But, organizational interest in initiatives, such as Voice of the Customer, Customer Experience (CX), and now Customer Centricity has pushed design teams to pay more attention.

The interest comes with great intentions. The people behind the surveys earnestly want to know if the organization has lived up to its promises. They seek any information that can help them improve their designs.

Yet, the data they collect and the way they collect it may not give them what they’re hoping for. In the best case, surveys are seen for what they are and not given much credence within the organization. In the worst cases, serious and expensive decisions are made based on survey data, which drives the organization unknowingly in wrong directions. It’s important that we understand the challenges this data presents, how we can make the best use of it, and how to change what we collect to improve our data quality.

The difference between subjective and objective data.

At a recent conference, I heard a speaker explain to the audience that qualitative data (data collected through methods such as usability testing) was always subjective while quantitative (data from surveys) was always objective. Unfortunately, this commonly held belief isn’t quite true.

In a usability test, the observers might notice that a user was presented a particular error message four times. We’d call that objective data, because it doesn’t matter which observer collected it. Each observer would come to the same conclusion about how many times the error message showed up. There’d be no debate.

However, in that same test, the observers might come to differing conclusions of the user’s frustration level from the repeated error message. We’d call that data subjective, because there’s no objective criteria for establishing a sense of user’s frustration.

The session moderator could ask each participant to say out loud how frustrated they were, for example, on a scale of 1 to 5. Even though each observer would hear a participant say the number four, we’d still call that subjective data, because there’s no objective criteria that every participant uses. The next participant could also say “Four” even though they are frustrated for entirely different reasons.

What separates objective data from subjective data is whether we have an unambiguous set of criteria that allows everyone to classify data similarly. When watching someone buy a product online, we can usually all agree with the price they paid, because that number was clearly displayed on the screen and charged in the transaction.

However, we have no standard way of telling whether the shopping experience was pleasant or aggravating. That’s subjective.

Subjective data isn’t bad. But, we have to see it for what it really is: an opinion about what’s happened. It’s clearly not factual, unlike objective data. For decision making, that distinction makes a difference.

Do you “Like” doing business with us?

In essence, the organizations sending us those feedback surveys are trying to learn if we liked interacting with their products or services. If we did, might we want to do it again? If we didn’t, how might they improve the experience?

There are many different ways to ask if we liked something. Of course, they can ask a simple question like how did we do? Often times, they’ll choose more institution-sounding language, like how satisfied were you with your shopping experience?The worst is when they pick convoluted questions, like Net Promoter Score’s how likely are you to recommend us to a friend or colleague?

No matter how the question is asked, the folks asking are looking for essentially the same answer: did you like the interaction with us? Whether it’s on a 10-point (or in the case of NPS, 11-point) scale or just a yes-or-no answer, the idea is the same. Do our customers like doing business with us?

“Like,” by itself, is not helpful.

The problem is, it isn’t helpful just knowing if customers like us or not. It doesn’t tell us what to do differently. If everyone likes us, we don’t know what they like about us. If we make changes going forward, we might wreck the thing they really like about us.

If everyone tells us they don’t like us, we don’t know what our users are struggling with. We don’t know how to make their experience better. Without more information we’re at a loss on what to change and what not to change.

Putting the data on a scale doesn’t help. It only muddles the data. If, on a scale of -5 (don’t like) to +5 (like), we get an average score of -3.7, then we only know -3.7 is slightly more positive than an average score of -4.2. We still don’t have any data that tells us how to improve our average score.

And an average score is aggregated. When we don’t understand the individual scores, aggregated scores become just aggregated nonsense.

Aggregated scores do not speak to individual differences. There might be totally different underlying reasons why two customers didn’t like dealing with us. Numbers can’t give us any sense of that.

The benefit of matching up behavioral data.

What if we combine the question “whether a user likes us or not” with the data we have on how they use our product or service?” (We don’t want to ask the user if they’ve used it—that’s still subjective—instead use built-in analytics of actual usage data.) For example, an airline could match up customers’ opinions of the airline’s service with whether those customers have flown on any recent flights.

We could segment these two data elements into four groups:

Customers who’ve used the product and say they like us. These customers are interesting because using the product seems to make them happy. Conducting further research to learn what about the product makes them happy could help us explain the benefits to others.

Customers who’ve used the product but say they don’t like us. These might be customers who will switch to a competitor if we don’t fix whatever it is that they don’t like about us.

Customers who don’t use the product, but say they like us. Hmmm. There’s something about the potential of our product that these folks like. Further research might explain what’s preventing them from actually taking advantage of our offerings.

Customers who don’t use the product, and say they don’t like us. These customers have formed their impressions of us from something, but recent use isn’t it. What might it take to get them to try us? Would that make a difference in how they feel about us?

Segmenting this data is useful, but it usually results in us asking more questions than providing actionable answers. Only knowing if someone likes us and if they’ve used us doesn’t help us plan improvements.

Measuring the disappointment of loss.

Recently, we’ve come across a couple of exciting enhanced approaches to subjective satisfaction data. The first one comes from investor Sean Ellis and it’s what he calls his Product-Market Fit question.

Sean uses this question to measure online services that people might use frequently. It is a single question with four answers.

How disappointed would you be if was no longer available?

A. I’d be very disappointed.

B. I’d be somewhat disappointed

C. Meh. It wouldn’t bother me.

D. Doesn’t matter. I’m don’t use .

Sean says the people who answer A (very disappointed the service would no longer be available) are the group of most engaged customers. When you have a majority percentage of these, you’ve achieved what investors call “product-market fit.” The goal is to grow the people in Group A by making the service something they feel they’d rather not live without.

Sean’s use of four choices is an interesting alternative to a numeric scale. While we still don’t know why someone feels a certain way when they choose very disappointed versus only somewhat disappointed, we have a clearer way to talk about the findings. More research could reveal the underlying reasons behind each customer’s feelings, which could point the way to improvements.

Enhancing the question by collecting more data.

Rahul Vohra, CEO of email product Superhuman, took Sean’s question and enhanced it to give his team more information to work with. His enhancement is a short, four-question survey that starts with Sean’s disappointment question:

1. How disappointed would you be if you could no longer use Superhuman?

This question has the same answers as Sean’s. Rahul then added three open-ended qualitative questions:

2. What type of people do you think would most benefit from Superhuman?

3. What is the main benefit you receive from Superhuman?

4. How can we improve Superhuman for you?

Rahul’s additional three questions add more depth to Sean’s original question. Rahul segments the answers he gets from the respondent’s first answer to Sean’s question about disappointment.

People who said they’d be very disappointed if Superhuman disappeared are Group A folks. Their answer to the type of people who benefit is basically a description of themselves. Their description of the main benefit is the most compelling aspect of the product, telling Rahul what he needs to protect. The Group A respondents’ list of improvements is a nice-to-have list, but not necessary to keep the customer subscribed, as they’re already highly engaged with the product.

Rahul turns his focus to the folks who are in Group B by answering Sean’s question that they’d be somewhat disappointed if Superhuman was no longer available. When the Group B respondents describe the people who most benefit, they’re describing someone slightly different from themselves. Comparing the Group B answers to the Group A answers, Rahul sees who feels the product is not quite for them.

Similarly, when the Group B respondents talk about their main benefit, they’re talking about the things that most make a difference to them. And looking at the Group B list of improvements gives a clear shopping list for shifting these folks into Group A in the future.

Rahul looks for patterns amongst to the Group B respondents to learn which features to invest in. He can look for changes in responses over time, to see if what people are asking for is shifting. This is much more valuable than just having a numeric score from an average satisfaction number.

Observation is still the best way to learn.

There are improvements we can make to subjective satisfaction scores, like shifting towards something akin to Sean and Rahul’s approaches. However, we’ll always be limited by trying to do everything through surveys.

Observation gives us a chance to collect more objective data. We can see how users interact with our designs. We can match what we see directly against the subjective data we’ve collected.

When users say they don’t like something, we can ask them to show us what they don’t like about it, producing richer insights.

We’ll always get our biggest improvement by spending more time directly talking to our customers and observing how they use our products and services. This can’t be done by just a small group of researchers. The entire team, including the folks putting out surveys, need to be exposed directly to customers and users.

Imagine having the kind of data Rahul’s survey reveals alongside direct visits with those respondents. Teams could then regularly visit a dozen or so customers and look specifically for valuable subjective answers, uncovering richer insights. These insights then lead directly to solid data and could provide your design teams the answers they need to drive the delivery of better-designed products and services.

After all, that’s what we’re collecting the data for in the first place.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Averting an Impending UX Leadership Problem

July 12, 2019

Success has its price.

When organizations realize the value of delivering better-designed products and services, they invest in hiring more user experience professionals. UX teams get larger.

Larger UX teams increase the demand for managers. UX teams produce the best work under managers who understand both effective management and how to grow UX efforts inside the organization.

This combination of managers with solid UX experience and knowledge is hard to come by. Hiring one is extremely difficult in today’s market.

Managers are made, not born.

The alternative to hiring someone new is to promote people already on the team. This has the extra advantage of having managers who already understand how the organization works and the organization’s culture.

However, becoming an effective manager requires a set of not-so-easy skills. Like learning to do anything difficult, this takes time and coaching.

To create effective managers organizations need a set of strategies. That’s why, on the second day of our Creating a UX Strategy Playbook workshop, we focus on strategies specific to growing the capabilities of the team.

First, create Facilitated Leadership opportunities.

The path to creating future UX managers starts with employing several facilitated leadership opportunities for individual contributors. Facilitated leadership is when a team member steps up to lead a group in a working meeting or workshop to move design efforts forward.

There are more than 130 strategies available design leaders choose from in the workshop. In several strategies, we introduce opportunities for team members to learn facilitated leadership skills. These include Institute regular design studios (Strategy #3.08), Institute regular critiques (Strategy #3.07), and Institute a formal discovery phase for every project (Strategy #2.16).

Each of these strategies needs someone to lead the team through the corresponding activities. These activities are great starting points for a strong individual contributor to learn basic leadership skills. The repetitive nature of the activities allows for repeated practice, leading to continual learning and improvement.

Making UX Leadership into a promotion path.

In a more advanced strategy, Establish an intentional Design Leadership track (Strategy #3.36), the organization sends a strong signal that leadership is valuable. Along with growing UX skills, the organization creates incentives to foster better design leadership skills.

A strategy like this one makes mentoring and coaching for leadership more of a priority within the organization. It forces reflection on the culture of leadership that the organization wishes to grow.

Reducing the risk of moving into management.

We fell in love with a strategy we learned from Mike Davidson’s time as the VP of Design at Twitter, Make management positions a lateral move from designer positions (Strategy #3.38). Similar to many organizations, Mike had set up both management and individual contributor promotion paths. Mike’s twist was that, for each level, the managers and the equivalent individual contributors made equal salary and had equal seniority rank.

Many individual contributors tell us they’re fearful to step into a management role because of the possible pay cut if it doesn’t work out. By keeping salary and rank the same inside the team, the risk is mitigated, allowing someone to just try out management. As Mike put it, “It’s just a switch from designing products to designing people.”

Averting the UX leadership problem.

These strategies, right from our Creating a UX Strategy Playbook workshop, are a key for any organization seeking to avoid the problem that comes as a byproduct of successful adoption of UX design and research.

Research shows that teams succeed when they promote from within, instead of hiring outside management help. Smart UX leaders put together a strategy playbook to create solid design management opportunities inside their team.

Creating effective UX management is critical to delivering better-designed products and services. In our 2-day, intensive Creating a UX Strategy Playbook workshop, you and your team will identify compelling strategies for building and developing your team to play an important role throughout the organization.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

Our Simple Trick to More Effective UX Design Project Leadership

July 3, 2019

We stumbled across this trick a few years ago. Since we’ve started using it, it’s helped UX leaders keep their project teams more engaged, which produces better results from the team.

The trick comes from the folks at Gallup (the polling research company), who put out a fantastic management book written by Marcus Buckingham and Don Clifton called First Break All The Rules: What the World’s Greatest Managers Do Differently. The book is a great description of the patterns that make managers effective.

(One thing I really love about it is how well researched it is. The UX researcher in me grooved as much on their methods as on their findings.)

Their employee engagement measurement tool, the Q12 jumped out at us. The Q12 is a 12-question survey that any manager can use to assess their effectiveness.

The Gallup Q12 questions.

The authors started with 2,000 possible questions trying to find what would predict whether a manager would be highly effective with their team. They ended up with these 12 questions that best predicted manager effectiveness:

  1. Do you know what is expected of you at work?
  2. Do you have the equipment and materials to do your work right?
  3. At work, do you have the opportunity to do what you do best every day?
  4. In the last 7 days, have you received recognition or praise for doing good work?
  5. Does your supervisor, or someone at work, seem to care about you as a person?
  6. Is there someone at work who encourages your development?
  7. At work, do your opinions seem to count?
  8. Does the mission of your company make you feel your job is important?
  9. Are your fellow employees committed to doing quality work?
  10. Do you have a best friend at work?
  11. In the last 6 months, has someone at work talked to you about your progress?
  12. In the last year, have you had opportunities to learn and grow?

The Gallup folks intended companies to give the Q12 survey to people reporting directly to their managers. However, that’s not necessary.

Any manager can look through the list and pretty much guess what the answer will be, because they know whether they’ve done a good job on these things or not. Any questions the manager thinks won’t get a solid yes answer points to a place they can improve.

The trick: Using the Q12 for project leadership.

While the Gallup folks made the Q12 to assess managers, we’ve co-opted it for UX project leaders. It’s not uncommon for a UX professional to find themselves leading a major project or initiative, such as rolling out a design system or conducting in-depth customer research.

These projects often involve people who are from other teams. Those team members don’t report to the project’s leader. Yet, that project leader must ensure those team members are engaged and doing their best work. The Q12 helps them do that.

By walking through the questions for each team member, the project leader can quickly identify potential issues to discuss with the team member. The project leader can work to provide guidance and support to that team member.

Most of these questions aren’t difficult to resolve. It should be easy to help a team member know what’s expected of them and to try to help them get the right equipment and materials.

Some questions will need a bit of coordination with the team member’s manager, such as ensuring the team member has available time and opportunity to do their best work. And a question like “Do you have a best friend at work?” may be a tricky one to make happen. But, there’s often a way to pair people together to help friendships grow.

We’ve found the questions to be a great guide to bring a wayward project back on track. We also use them from a project’s start to get everyone on the same page and make sure we’re taking care of each team member’s needs. We’ve found the Q12 to be a helpful project leadership framework.

The Growing Demand For UX Managers

July 2, 2019

The hot UX job right now is User Experience Manager. It’s a sign that things are changing for the better. UX is growing in importance inside many organizations.

Organizations only need managers when they’ve been growing their design teams. They only grow their teams when they value design.

However, there’s a problem. There aren’t enough experienced UX managers to fill all open positions. Experienced UX managers are often happy where they are. It takes years for new managers to get the requisite experience to manage growing teams.

UX-Design-as-a-Service teams drive the demand.

It’s the teams at the UX Design as a Service stage of our UX maturity model that are driving this growing demand for UX managers. This stage happens when an executive within the organization believes UX is important enough to start making serious investments in people and teams.

The two stages before UX Design as a Service, UX Dark Ages and UX Spot Design,don’t warrant UX teams. In these stages, the organization has yet to realize the value of delivering well-designed products and services, so they aren’t investing in a team of designers and researchers.

In the later stages, Embedded UX Design and Infused UX Design, UX professionals are moving into individual product and service delivery teams. The demand for managers who specialize in UX teams stops growing, as individual team managers now take over the work.

This stage drives the demand we see for more UX managers, as more organizations are moving into this stage. Organizations are growing their UX teams to be large enough to warrant managers.

They’re finding that not just any experienced manager will do. They need managers with UX knowledge and experience. Thus, the demand for UX managers.

Managers make their teams effective.

A great manager focuses on the effectiveness of the people who report directly to them (often referred to as the manager’s direct reports). They do what it takes to ensure each team member working for them produces their best work every day.

They ensure each direct knows what’s expected of them. They get each direct the tools and materials needed to do their job. They help their direct reports understand how their daily work contributes to the overall mission of the organization.

A great manager also focuses on the development of their direct reports. They look for opportunities to grow. They provide feedback to each direct on what they do well and where they can improve. They regularly talk to the directs about their development progress.

The growth of UX teams demands management.

When an organization only has a couple of designers or researchers, special management doesn’t seem necessary. Hiring experienced designers and researchers who are good self-managers will do the trick for organizations whose UX teams are just starting out.

However, once a UX team grows beyond four people, the need for a manager starts to grow. Team members need coordination and help to manage their efforts.

Managers are most effective with eight or less direct reports. As a UX team grows beyond eight members, the organization will need a second manager to help out.

Once they grow the UX team past 24 or so members—where it’s large enough to require four managers—they’ll probably need to hire or promote someone into a manager-of-manager position. This is quite common these days. We regularly see UX teams with more than 40 team members.

UX Managers are a special breed of manager.

It’s tempting to put anyone with management experience in this position. Yet, as any UX professional who has worked under a manager who didn’t get UX can attest, this creates many stresses in the job.

A UX manager can provide a level of support for the UX team that a manager without UX experience and knowledge can’t. They focus on needs that are unique to UX teams.

A great UX manager will help the UX team move their design and research work to be more pro-active. They can coach their management peers on how and when to ask for UX resources to get the most out of the team’s capabilities.

A great UX manager will also coach the team’s individual contributors on how to surface the value of UX design and research in the organization. Being inside the organization’s management structure, they can identify where design and research can be most valuable, and feed that into how their direct reports position the team’s work.

Growing the UX team will always be a priority. UX teams are always too small for the work they need to accomplish. A UX manager can use their knowledge of UX work to identify where the team needs to grow their skills. They’ll use this for both hiring and the ongoing development of their direct reports.

UX Managers make UX Leaders.

UX Managers are different from UX Leaders. UX leaders push a vision forward, while UX managers focus on making the team effective. They are related roles in an organization, but they aren’t the same.

It’s possible that a UX manager can also be a UX leader. They can have a clear vision and spend a significant portion of their time promoting that vision.

However, many highly-effective UX managers prefer to grow leadership skills within their team. They use the role power that comes from their appointment as a manager within the organization to support the leadership that comes from individual contributors on their team.

For example, an individual contributor can be leading an effort to roll out a design system. The UX manager can use their own role power to support that team member’s initiative, giving it credence and recognition.

To make this work, the UX manager needs to be constantly growing the leadership skills of their direct reports. Leadership is a learned skill and critical for every UX professional to develop.

We need to make more UX Managers.

As we grow our teams, we need our individual contributors to start picking up basic management skills. Even without direct reports, these skills are useful for helping the teams they work with to be more effective.

Not everyone will want to become a manager. There should definitely be growth paths for individual contributors.

Yet, for those who wish to try their hand at designing effective people, management can be a great path. The shift to ensuring entire teams deliver well-designed products and services is quite rewarding and much needed in our field.

UX Strategy with Jared Spool

This article was originally published in our new UX Strategy with Jared Spool newsletter. If you’re passionate about driving your organization to deliver better-designed products and services, you’ll want to subscribe.
Subscribe here.

Having the most effective UX team is the key to increasing design leadership in your organization. In our 2-day, intensive Creating a UX Strategy Playbook workshop, you and your team will identify compelling strategies for building and developing your team to play an important role throughout the organization.

We offer this workshop in cities all over the world. Visit our website at Playbook.UIE.com for more details. We can also bring it to your organization. Contact us to learn how.

Announcing Our New UX Strategy with Jared Spool Newsletter

June 27, 2019

Hello Makers of Awesomeness,

We’re launching a free newsletter just for design leaders, like you.

You’ve probably noticed that now, more than ever, there’s more pressure for organizations to deliver well-designed products and services. We regularly hear from design leaders like yourself about the best strategies to position their organizations to become more design driven.

This has become a major focus of our work at Center Centre – UIE. As a result, we’ve started publishing a ton of tips on successful UX strategies.

Now, you can get all of the benefits of our in-depth research into what focuses organizations on their designs. If you’ve been enjoying our recent articles, we’ve got good news: We’ve created a new newsletter just about UX strategy.

We’re calling it UX Strategy with Jared Spool and (surprise!) it’ll have all the latest thinking from our research on the topic. And the best news of all? It’s free. You just have to sign up.

A brand new newsletter focused 100% on the strategies behind great user experiences.

This is a brand new newsletter, different from anything we’ve ever published before. Every week, you’ll get new tips, techniques, and wisdom about how to make a huge positive difference inside your organization.

Upcoming topics will include successful strategies that other design leaders have employed to:

  • Measure the value of design in their organization.
  • Attain alignment on a compelling vision that drove their product strategy.
  • Create a culture that includes UX design approaches in every aspect of the business.

We’ve got hundreds of topics to talk about, just like these. You won’t want to miss a single one.

The only way to get this newsletter is to sign up here.

We have all sorts of great things planned for the UX Strategy with Jared Spool newsletter subscribers, including first access to our latest research, special conference calls, and a new community to share your challenges and get answers to tough questions. By subscribing, you’ll find ways you can drive your organization to value design even more than it does today.

The next issue of the UX Strategy with Jared Spool newsletter is coming out in just a few days. Don’t miss it. Subscribe for free today.

See you there,

P.S. We won’t be adding anyone automatically. Nor will we be sharing your email address with anyone else, because your privacy is important to us. (That’s just good user experience.) The only way to get this newsletter is to sign up here.

An Iterative Approach to Scenarios and Personas

June 24, 2019

Great design anticipates the users’ needs. It matches what the user is trying to accomplish.

Not all people have the same needs, even if they desire the same outcome. The variations between users and how they go about achieving their objectives can be subtle and nuanced. Teams need to have a clear picture of those variations to design for users who require different things.

Scenarios and personas work best when they provide the team with a detailed understanding of who the users are and what those users need. The scenarios and personas function as a role-playing tool, showing designers where their design works well and where it could still use improvement.

The trap: The all-at-once approach.

A common trap that design teams run into is when they make their scenario and persona efforts as a single phase of the project. They spend whatever limited research budget they have all at once, trying to produce a single set of definitive documentation that describes their identified scenarios and personas.

This all-at-once approach does the opposite of the team’s intention. It creates a limited, static view of the users and their needs. That view is not supposed to change for the duration of the project.

Their static scenarios describe what the team believes the users need to accomplish. The static personas describe what the team believes makes one user different from another. The design team can use the documents they produced for the rest of the project.

At least, that’s the theory.

In practice, the team built out those scenarios and personas with limited research. The approach assumed they saw everything they needed to see from that one research effort.

We know that design is iterative. Yet, using this approach, the team doesn’t give themselves an opportunity to iterate over the scenarios and personas they've developed.

A plan for iterating on our scenarios and personas.

An alternative is to create the scenarios and personas iteratively. We can do this by integrating them into a steady stream of research throughout the project.

For many projects, we start with stakeholder interviews. That’s research we can start with. We take what we learn about our users and their needs from those interviews and craft the first draft of the scenario and persona descriptions.

When stakeholders give us requirements, we can reframe them as assumptions that need validation. We use that opportunity to launch a small research project to meet some users and investigate the stakeholders’ beliefs. We add what we learn to our scenario and persona descriptions.

As the design project progresses, we find more opportunities to meet and observe our users. Each time we uncover new insights about the users and how they interact with our design, we update our descriptions.

Even the process of recruiting participants for these ongoing research sessions is research in itself. As we talk to potential participants, we’ll find out what makes them similar or different to other users we’ve interacted with. Maybe they don’t fit the particular study we want to do? That’s telling us what we don’t want. We can add that into our descriptions.

The descriptions are only a souvenir.

As we do research throughout the project, we’re continually refining our understanding of the user. With this knowledge, we improve the description documents. They become an up-to-date resource, representing the insights we’ve learned throughout the project.

However, documents are problematic. They only contain a snapshot of what we’ve learned. They’re a souvenir of our research.

A souvenir serves as a reminder. When we look through a fun vacation’s souvenir booklet, it has the benefit of putting us back into the experience of that vacation.

But that only works if we were the ones who experienced the vacation. Looking at someone else’s souvenir booklet doesn't thrust us into their fun experience.

That’s why everyone on our team needs to have exposure to our users. They need to form their own experiences by meeting and observing the users. And they contribute their own insights to the descriptions, making the souvenir valuable to them.

Building scenarios and personas is an ongoing process.

Most products and services we work on live beyond their first release. There are feature enhancements and subsequent improvements.

Continual research will tell us how our users have adapted to the design. We’ll see them use the design in ways we never expected. We’ll see differences between users we hadn’t seen before. Once again, we update our descriptions.

Those description documents represent the cumulative knowledge and insights we’ve acquired about our users’ scenarios and personas over the life of the product or service. Every update helps us develop a deeper understanding of what we need to build.

We use this forever-growing knowledge to create great designs. By investing in continual research, we learn what it takes to deliver well-designed products and services to our users.

Making Personas Truly Valuable by Making Them Scenario-based

June 19, 2019

Personas are a fantastic tool for designers. They can guide important user experience decisions throughout the design process.

Many teams take an over-simplified approach, crafting personas that don’t offer any meaningful details to help with the design process. The documents they create look nice. They make good posters. Then everybody ignores them. These personas aren’t valuable.

After this experience, many teams give up on the idea of personas. That could be because they’re trying to make one set of personas for everything they do. We have a different approach that proves to make personas much more valuable.

When personas are valuable, they guide the team’s critical design decisions. These personas serve as a catalyst to having important design discussions. Because they’re based on scenarios, they ensure the team catches critical user paths through the design. Scenario-based personas offer more depth for user stories, so our developers build out better quality functionality.

We find personas based on roles are too vague.

For the last few months, our team has been working on a job board application, where companies can post their job openings and people can apply for the open positions. It would have been easy for us to fall into the common trap of defining our personas into user roles. The job board has two obvious roles: job posters and job seekers.

While ‘seeking a new job’ and ‘posting an open position’ are distinct activities in the application, they aren’t dictated by user roles. The same person could do both over time. Someone who has been posting jobs may also seek a change in their own career. At that point, they’d also become a job seeker.

Personas don’t help us when we define them on roles. Roles are too imprecise and ill-defined to make useful.

It’s clear we need functionality for someone when they’re posting a job and different functionality when someone is seeking a job. Beyond that, having personas of a job poster or a job seeker wouldn’t help us make any decisions. That’s where scenario-based personas come in.

We start with researched scenarios.

Before we started our research with the people who wanted to advertise their open positions, we hypothesized there were basically two overarching scenarios:

Scenario #1: Job poster with existing job description.
Job poster has a description they’ve posted in several other places (including their own company’s career page). They would like exposure to the audience of our job board. They’d like our job board to promote the description they already have.

Scenario #2: Job poster has brand new position with no existing description.
Job poster just received approval to hire a new team member. They haven’t posted the job anywhere yet and therefore haven’t written it up. They’d like to get applicants right away. They believe our job board firmly targets exactly the type of people that would make great candidates. They’d like to post the first job description on our site right away.

We were right in that both scenarios exist. However, our research showed the second scenario happened infrequently. As a result, our team changed up our delivery plans, deciding to focus on the first scenario: posters with existing descriptions.

We look for variations on how people approach our scenario.

Often, we can get by using only scenarios. Scenarios give us all the detail we need to build out the functionality. In these instances, every user who finds themselves in the scenario would approach it basically the same way.

However, in some projects, in-depth research shows us variations in how different people tackle the same scenario. That was certainly the case with job board posters.

We found multiple approaches to posting a job depending on who the job poster was. Here are some variations we found:

Hiring manager with only one position and not working with HR: This hiring manager has only the one position to advertise. They also have control of the hiring process, with no involvement from their HR recruitment department.

Hiring manager with multiple positions: This hiring manager is building out their team with multiple simultaneous openings. Some of the openings may be very similar positions (and may share the same job title), but will describe slightly different job objectives and requirements.

Hiring manager working with HR recruiter: This hiring manager is working with a recruiter from HR, who will screen applicants and answer the applicant’s preliminary questions about the position.

HR recruiter posting the position: This is a recruiter who is simultaneously recruiting multiple open positions within the organization. This recruiter posts the open position instead of the hiring manager, possibly on the hiring manager’s recommendation.

Each scenario-based persona will approach the design differently.

It was from our research that we learned how each persona was different from the others. We saw many people who were like our first persona: the one-position hiring manager who wasn’t working with HR. This was our simplest persona. They just need a way to copy and paste the description text into the job posting form.

The first hiring manager we met who had multiple positions to post was different from our first personas. They wanted to move between drafts of the job postings. They needed to make sure each position had the right information. We need to help them efficiently enter their posts without duplicating their efforts each time.

We also learned hiring managers who work with an HR recruiter need a way to share the job posting draft. They’d like the recruiter to give them feedback. This persona had different needs than our previous two personas.

Finally, the recruiters we met were very different from all the hiring managers. The recruiters worked with dozens of boards and were very interested in capabilities to track which boards produce the best applicants. They also needed to understand why they should choose this board and which types of positions. None of our hiring manager personas showed any interest in these capabilities.

By identifying each persona and noting their different needs, we can make sure we’re not missing any key functionality. We’re more likely to anticipate all of our users’ needs this way.

Our scenario-based personas emerged from our research.

To identify our personas, we paid attention to what we were learning from our research. We started the research by interviewing hiring managers, asking them to walk us through their hiring process.

We learned about their autonomy and their relationship with HR. We learned about the order that things happened in the hiring process. We learned who usually crafts the job description. We learned about their frustrations with attracting the best applicants.

It was in these interviews that we caught our first glimpses of the different personas. We learned more about them by using interview-based tasks as we conducted usability tests on our prototypes.

After each research session, we’d flesh out the persona descriptions a bit more. The more people we researched, the richer our understanding of each persona became.

These weren’t personas we created to figure out who to research. They were personas that emerged from the variations we saw once we started our research. We’ve found this to be a much easier way to get to more accurate and nuanced personas.

These personas are most useful for specific scenarios.

These four personas turned out to only be useful to our team for that particular scenario. For a different scenario (paying for the posting), we needed different personas (people who wanted invoices versus paying with a credit card). And we didn’t need any personas for the scenarios of turning off the job posting (because the position is no longer open) or extending the posting (because it hasn’t been filled before the post’s expiration date).

In the course of building something like our job board application, we could have a dozen or more scenarios. Personas would only matter to us for approximately half of our scenarios.

The personas for one scenario will unlikely influence the functionality of the other scenarios. We’ve found personas are most valuable when they’re specific to a single scenario. This makes describing the personas substantially easier. We only describe a persona’s specific attributes that will influence the functionality differently from other personas.

Bridging a gap between scenarios and user stories.

Many teams use user stories that look like As a [user], I need to [action] so [an outcome occurs]. With our scenarios and the personas from those scenarios, we can easily fill in all the pieces.

For example, using one of the personas I listed above, we can craft the user story of As a hiring manager working with HR, I need to share a draft of my job posting so my HR recruiter can add in details I’ve left out. Having both the personas and the scenarios to use as background information, creating rich user stories like these become simpler. They also give the developers more insight on where to take the functionality to make it work for the user.

We’ve found these scenario-based personas work very well with other UX techniques, such as Jeff Patton’s Story Mapping, Indi Young’s Mental Models, and Jeff Gothelf’s Lean UX. Scenario-based personas become a lightweight tool to ensure we’re covering all our bases and building the right design.

The Best UX Strategies Behind Becoming a Customer-Driven Organization

June 14, 2019

As a UX design leader, you’re in the perfect spot to lead your organization’s initiative to become customer-driven. And we’ve put together the perfect workshop to help you do just that.

Organizations everywhere are working to transform themselves to become more customer centered. Design teams like yours are perfectly positioned to drive these transformation efforts.

You and your team have a good start on the necessary know-how to conduct user research and identify what customers truly need. You’ve started developing the most effective tools for communicating customer insights information across your organization. And you have begun building the essential skills to bring everyone into the process of thinking about customers first.

To complete the transformation of a customer-centric organization, you’ll need a great UX strategy. That’s why we created our Creating a UX Strategy Playbook workshop workshop.

When you attend this workshop, we work together to identify the best ways of putting customers into the center of every decision. Because your organization has unique strengths and challenges, we’ll carefully choose the perfect strategies to meet your current situation.

We’ll first focus on UX strategies that will work best across your organization:

  • Create an experience vision to demonstrate what a customer-driven organization is capable of delivering.
  • Map the value your team delivers directly to your organization’s top business priorities.
  • Identify essential hidden champions to give you air cover and support for making hard changes in your organization.

Next, we’ll dig into the most effective UX strategies for bringing the customer into the center of every decision:

  • Map out how to get more out of your user research, increasing demand for customer insights.
  • Integrate a customer-first approach with the product roadmap, to ensure every release delivers value.
  • Measure how effectively your products and services are meeting customer needs.

Finally, we’ll choose the strategies you’ll use to spread customer-first design skills across the organization:

  • Increase the most important customer-centric design capabilities across your organization.
  • Develop a culture that drives the desire to uncover new customer insights and integrate them into everyday product and service development.
  • Identify the best individuals to lead the next generation of critical design initiatives for delivering excellent products.

Every moment of this 2-day intensive workshop is focused on you and your team. You’ll leave inspired to make big changes across your organization.

“The Playbook workshop was really helpful for me and my team. Your workshops and conferences always leave me feeling inspired to go home and make a little awesomeness, and I just wanted to express my gratitude once again.” — Chad Weiss, Aptima

You’ll build an action plan for driving a customer-first culture. Bring your team’s leaders and your peers from product management and development. Together, you’ll construct a playbook that will change how your organization works.

This is a workshop you don’t want to miss.

Register today for the Creating a UX Strategy Playbook workshop.

Chattanooga, TN
August 7-8, 2019 (only 6 spots left)
October 2-3, 2019

Manchester, UK
September 24-25, 2019

Sydney, Australia
November 21-22, 2019

Melbourne, Australia
November 18-19, 2019

Customers Request Solutions. We Need to Understand Their Problems.

June 11, 2019

“They need a way to export data.” That’s what the salesperson told the product manager. “It’s a big sale. We’ll lose it if we don’t put a data export feature in.”

On the surface, it sounds like a reasonable request. But there’s a complication.

The team can’t do a great job with the information they have. They could implement a data export feature in several different ways—each very different. If the designers just guess what the customer wants, it’s very likely they’ll build the wrong functionality. That would be a costly mistake.

The salesman came to the meeting with a customer’s solution. To be successful, the team needs to understand the problem behind that solution.

Human nature kicks in.

It’s human nature to start with a solution. When any of us walk into a store, we bring with us a shopping list of solutions. Not the problems we want to solve.

Starting with a solution is a concise way to communicate what we think we need. It’s expedient, but it leaves out important information.

Why did that customer tell the salesman they needed to export data? There are at least three possible reasons:

  • Maybe they needed a secure backup.
  • Maybe they wanted to move the data to another instantiation of the application.
  • Maybe they wanted to bring the data into another vendor’s application, to manipulate it somehow.

(There could be more possible reasons, but let’s stick with these three for now.) Each of these reasons is radically different. A well-designed solution would be very different depending on which of these is what the customer actually needs.

The problem changes how we implement the solution.

The first alternative problem assumes the customer needs a backup solution. If the team were to build a backup capability, exporting the data is only half the problem. They’d also need a way to restore the data. That’s a bit of work.

Whereas, if the customer really wants to move the data to another instantiation, that’s a completely different problem to solve. Do they need all the data moved, or just a subset? Is it just the raw data, or do they need to move any tailored capabilities? That’s a different bit of work from the backup solution.

And if they are bringing the data into another vendor’s application, what functionality does the third-party application provide that the team’s application doesn’t? Maybe it’s better to build the missing functionality? (Or is it possible that functionality already exists, but the complexity of the team’s design prevents the customer from realizing that?)

Once we realize there are multiple problems, it’s clear we need to do more research.

Starting with the best outcomes.

One approach to getting to the right solution is to start with the outcome. To start, the team can ask a critical question: If we implement the data export capability perfectly, how will that make our user’s life better?”

Research could tell us that the customer now gets to sleep soundly, confident that they could easily recover from a catastrophic technology failure. That would indicate that backup is why people need to export data.

But it also creates a few more questions: How might the design make it easy to do make backups and restore them? How might it demonstrate that the data backup process is working smoothly and is ready to recover at any point?

But what if the research says the outcome would make it easy to duplicate best practices across the organization? That’s where we might want a way to duplicate data across multiple instantiations. How might we give the user an easy way to deliver data to other groups for their own use?

Maybe the user needs to report some type of progress, as indicated by the changes in the data, to their superiors. That would be why they want to move the data into an application like Excel. What are they doing with that data? Are they making charts for presentations? How might we make it easier for them to communicate that information effectively?

Outcomes > Problems to be solved > Solutions.

Outcomes are the improvement our users see because we’ve done a great job with our design. By starting here, we’re starting with the end in mind.

Once we identify the desired outcome, the problems to be solved are all the things that currently prevent the user from attaining that outcome. These are the obstacles our design needs to overcome.

The solutions then represent how we’ll overcome those obstacles. There’s a small chance that the solution the customer has first suggested is the right one. It’s more likely there are better solutions out there, waiting for us to discover them, once we know the outcomes and problems to be solved.

Shifting to outcomes gets us to the best solution.

As designers, our job is to improve our users’ lives. We need to identify what it will take to make that happen. That means looking past the solution our customers first ask for.

When we do this, we shift our work from being a design request “order takers” who only work off the customer’s shopping list. Instead, we end up with solutions that truly meet the needs of the user. This is how we deliver the best-designed products and services.

Customer Centricity - The Management Fad We Can Hop On

June 4, 2019

If your executive team isn’t talking already about Customer Centricity, they will be soon. It’s the latest in management fads to make the rounds.

Customer Centricity is exactly what it sounds like: using customer insights to steer every decision made in your business. Its proponents promise organizations will see great benefits, increasing profits and cementing market leadership. This is why it’s become a popular topic in the top business magazines and at executive leadership events.

Proponents claim that organizations who invest in Customer Centricity are 60% more profitable, double the return on shareholder equity, and double their pre-tax returns on assets, sales growth, and market share, when compared to their less customer-centric counterparts. Who wouldn’t want that for their organization?

The latest in a long line of management strategies.

Packaged management strategies, such as Customer Centricity, fall in and out of favor like the latest weight-loss diet. These strategies appeal mostly to executives who seek to explain why other organizations are seeing great success while their own organization struggles. They desire a package of proven strategies they can rally their troops around, hoping to see a dramatic improvement in meeting their customer’s needs.

Customer Centricity is currently the latest in a long line of pre-packaged management strategies. Its predecessors include Design Thinking, Jobs to be Done, Customer Experience Transformation, Digital Transformation, Six Sigma, ISO 9000, and Total Quality Management. Customer Centricity is also the management strategy that’s the most compatible to what we’re trying to do with our organization’s user experience initiatives.

In recent years, several of the pre-packaged management strategies have inched our organizations closer to focusing on delivering great user experiences. Until Customer Centricity, they haven’t quite gotten there.

Starting back in 2014, Forrester Research promoted their strategy of transforming marketing departments to be Customer Experience focused. While it helped the pre-sales efforts pay more attention to customers, it wasn’t easy to integrate with post-sales product delivery work.

In 2016, Harvard Business School professor Clayton Christensen popularized Jobs to be Done. By asking “what job is our customer hiring us for?”, Jobs to be Done forced organizations to pay more attention to their customers than they ever had before. However, neither Clayton nor the consultants selling Jobs to be Done made any acknowledgment of the research necessary to discover the customer’s jobs. Without the research, most organizations struggled to scale the strategy.

In 2017, IDEO’s David Kelley started popularizing Design Thinking. This has caught on with many executive teams and organizations have made big investments in team training. Yet, there’s very little to show for it, primarily because the strategy doesn’t go beyond the initial idea generation phase. Its high-level approach doesn’t help with the low-level details necessary to deliver a great product or service.

Customer Centricity aligns with UX design maturity.

Unlike its pre-packaged management strategy predecessors, Customer Centricity’s core philosophy is to empower every individual in the organization to focus directly on the customer. It aligns directly with how UX design leaders work to improve the UX design maturity of their organization.

The ultimate goal of UX design leaders is to transform every team to become UX-design infused. Not only are there UX designers involved in every major initiative, but every member of each team needs to have the expertise to make smart design decisions.

When the executive leadership employs a customer-centric approach, they’re guiding the organization to become more design mature. As UX design leaders, we can use this to our advantage in a way we never could with previous pre-package management strategies.

Mapping our work to Customer Centricity.

A solid introduction to Customer Centricity is Denise Lee Yohn’s excellent Harvard Business Review article, 6 Ways to Build A Customer-Centric Culture. In her article, Denise lays out six specific actions organizations must undertake to become truly customer-centric. We can map our UX design leadership work directly into these strategies.

Operationalize customer empathy.

Denise tells executives they need to go beyond lip service about customer needs and make sure every employee is fully aware of where the pain points are for customers. Only when employees understand what customers need can they start to deliver products and services that meet those needs.

When UX teams surface and communicate their knowledge of the customer experience, they inform the entire organization. Customer journey maps, service blueprints, and other tools that promote the user’s experience provide deep insights into what it’s like for a customer today.

Hire for customer orientation.

Denise recommends every employee, including all new hires, make the customer and their needs a priority. Customer-centric organizations ensure their hiring process delivers new employees who are aligned to customer-centric thinking.

Making customer needs a priority when hiring will get the right people into the organization. However, they’ll still need to learn what the rest of the organization already knows about the customers. UX teams speed onboarding by providing UX training materials and workshops to introduce every new employee to the users and their needs.

Democratize customer insights.

Denise correctly points out that every employee must understand the most important insights we’ve learned about our customers and what they need. Not only must they understand where the customer’s experience needs improvement, but it’s also important that everyone understand how we plan to address it.

A UX Experience Vision is a powerful tool for showing what a better experience looks like. It tells the story of what it’s like to be a customer in the near future (such as five years from now). This communicates to everyone where we’re trying to go based on the insights we’ve identified. As the UX team crafts and shares that vision throughout the organization, everyone can understand what work is left to be done and how they can contribute to it.

Facilitate direct interaction with customers.

In Denise’s article, she emphasizes every employee must see how their work directly affects the customer’s user experience, even those who work in back-office functions that don’t normally interact with customers. Reading reports or watching the occasional highlight video of a frustrated user don’t communicate this well. Instead, we need employees to observe the customer directly interact with our organization’s products and services.

UX teams already have a tool for this: increasing exposure hours. There’s no better way to learn what makes the user experience frustrating than to see it first hand, while it’s happening.

This isn’t just for using an app or a website. Our customers become frustrated by our customer service and sales processes too. We need to expose every co-worker to the entire life journey of our customers.

Link employee culture to customer outcomes.

Denise also recommends metrics be put into place to ensure people see how their behavior and work leads to achieving the goals in the customer’s experience. Teams need to measure both customer-facing interactions and back-office operations.

The UX team is perfectly positioned to come up with the right measures. By identifying and studying the desired outcomes in the customer’s experience, teams can identify the best measures to track. By going beyond the numbers and studying the behaviors that lead to the metrics, the team delivers new insights for further improvements.

Tie compensation to the customer.

This is Denise’s strongest action. An update to the organization’s compensation model sends the bold message that this isn’t just a passing fad.

Knowing Customer Centricity is coming, design leaders should identify critical UX measures to use as the basis for organization incentive programs. This puts the UX effort at the center of the Customer Centricity initiative. It will make everyone in the organization solidly aware of the customer’s experience, while putting the UX leadership in the position of guiding the organization to the next level.

Making UX the core of a Customer Centricity initiative.

Customer Centricity is a management fad that’s worth hitching our wagon to. Like its predecessors, it’s defined vaguely enough that there’s much play in the nitty-gritty details of how the organization puts it into action.

That opens the door for attentive UX leadership to use their team’s skills and expertise to drive the initiative from within. Under the Customer Centricity flag will be an organizational machine made up of great UX practices and strategies. The UX leadership can then drive the entire organization, with the strong support of the executives who have “discovered” this new management strategy, to deliver better-designed products and services.

Baking Innovation Into Your Design Process

May 28, 2019

For many organizations, innovation has become a top priority. If your organization wants to deliver better products and services, you’ll need to move beyond only matching your competitor’s functionality. You’ll need to solve problems for your customers and users that no competitor is currently solving.

To deliver innovation, your organization doesn’t need to build a special innovation team to invent new technologies or patent new service processes. We’ve got all the arrows in our quiver. We only need to use them effectively.

Research the customer’s problems nobody else is solving.

As our organization matures our user research efforts, we will start shifting the research from investigating solutions (Are we building our designs the right way?) to investigating problems (Are we building the right designs?). This shift is essential for identifying where innovations will benefit the customers and users.

For example, when online payment processor Stripe launched their first product, it solved an important problem for small and medium-sized businesses. For the first time, It was easy to build a website that handled financial transactions.

In those days, the business didn’t have alternatives if they didn’t want to use a platform like Ebay or Etsy. It was hard for a small chain of restaurants to build an online ordering platform. Or, for a training company to build a way to let its students register and pay for courses.

Stripe’s teams focused their research on what caused friction in the work of their users—the developers of websites for those small and medium businesses. Their research uncovered new challenges those businesses wanted to overcome, like handle recurring payments and multiple currencies.

It was in the users’ pain that the Stripe product teams realized they could offer an advantage. None of Stripe’s competitors were solving these problems. This is how Stripe innovated and became the industry leader.

Populate the product roadmap with customer’s problems.

True innovation is hidden deep within the problems that our users are currently experiencing. Armed with our research of the problems, we plan out our roadmap of future product releases.

Grouping the problems into related themes, we identify where they should go on our product roadmap. A themes-driven roadmap shifts the entire team from outputs to outcomes.

Our team moves beyond producing features which sound good, but nobody may need. Instead, we’ll ensure each release will solve problems we know our customers are facing.

A themes approach to roadmaps is an essential approach to innovation. It keeps the team focused on the customer’s problems, providing a forcing function to stay grounded in what will change the marketplace.

Innovative solutions come out of deep understanding.

The Kano model gives us insights on where to start. We look for expectations the users have that we’ve missed. Often these have an easy fix, yet because no-one has done the research, neither us nor our competitors have ever addressed them.

We also look for inexpensive ways to exceed our users’ expectations. By focusing on addressing their needs and reducing friction, we can identify improvements that make the users’ experience smoother.

Fix enough of these problems and our products and services become more coherent and thoughtful to the user. Our users, like Stripe’s developer customers, will have a better experience and achieve their desired outcomes.

True innovation isn’t about a new invention. True innovation is about delivering new value. When our customers and users receive a friction-free, delightful experience, they get more value from our products and services.

We don’t need to start a specially-skilled innovation lab to make this happen. We need only to pay closer attention to our customers than our competitors are. (And, right now, chances are they’re not paying any attention to those customers.)

We’ll be first to market with designs that fit our customers like a glove. We achieve that by baking sound innovative practices into our day-to-day design process.

How Corporate Innovation Labs End Up Preventing Innovation

May 21, 2019

We stepped off the elevator on the 34th floor of the bank’s headquarters, one floor below where the bank’s CEO sits. We walked across the hall, where the Senior Vice President of Experience Design swiped us into the secure area.

Waiting for us was the Director of the bank’s innovation team and several key members of his team. They were standing in a large room, filled with what looked like interactive museum exhibits.

The exhibits, it turned out, were interactive installments demonstrating the innovation lab’s future vision of banking. One by one, we walked up to each exhibit where a member of the lab’s design team told us how the new technology would make a better future banking experience.

Of course, the bank’s logo was on each exhibit piece. The message was clear: this bank would own the banking experience of the future.

This all happened about five years ago. Since then, many of the innovations we saw that day have come to fruition. However, none of them were introduced or delivered by that bank.

“We’re a startup inside our massive company.”

Around the same time, we were invited to the headquarters of a major commercial software producer. We met with the Vice President of Innovation and his team.

Sitting at the conference room table, the Vice President presented us with a box, a little bigger than a cigar box. It was labeled “Startup Kit.” This was the innovation team’s new experiment.

Inside the kit, we were told, were all the makings of a startup. There were sticky notes, a copy of Eric Reis’s Lean Startup, a deck of inspirational cards with helpful startup tips, and a pre-paid bank card with a balance of $1,000.

Employees could request to leave their current assignment and join the innovation lab’s in-house startup incubator. If they were selected, they’d receive one of these kits. That made them the “CEO” of their own startup, inside the company.

With it, they were told to do whatever they needed to create a brand new startup, including spending the bank card’s money as they saw fit. They had full autonomy. They didn’t even need to keep receipts.

Each new startup CEO had six months to create their startup and present it to the innovation lab’s committee. If the committee liked what they saw, they’d fund the second stage of the startup. If they didn’t, they’d go back to their old job, doing what they’d always done.

While the VP boasted of several promising startups in the early phases of this experiment, none of them have produced more than some interesting features and extensions to the existing product offerings.

To be competitive, companies must innovate.

Innovation labs and in-house startups have recently garnered much attention in the business management world. High-priced management consultants often promote them as a great way to guarantee the organization will dominate their own market, much the way companies like Tesla, Apple, and AirBnB dominate today.

Unfortunately, efforts to build successful innovation labs and in-house startups often fall flat. The labs can manage to produce a few ideas, but we rarely see them introduced into the market. The few times we do see their ideas come to fruition, it’s rarely from the company’s innovation efforts. Instead, it’s most often a competitor who end up bringing the ideas to market and benefiting from introducing the innovation.

It’s not for lack of trying. These companies invest millions in these efforts, staffing the team with the best of the best. The all-star teams are granted carte blanc to do what’s needed, often bypassing the organization’s traditional permission and bureaucracies infrastructure. They’re permitted to move fast.

Given all these advantages, why do these efforts regularly fail? It’s because they’ve missed two essential components.

Disney didn’t use an innovation team to innovate.

In 2014, Disney launched one of their most ambitious projects: The Disney Magic Band.With a billion dollar investment over seven years, this was a huge bet.

The result was a magical bracelet, which gives the wearer full access to everything in Disney’s parks. Guests can use their bracelet at the entry gate. It opens their hotel room doors. They can wave it at restaurants to pay for their meals. They can use it to FastPass wait times for popular rides.

While the Magic Band was underdeveloped, Disney’s team, like the bank’s innovation lab, built a working demo area. They commandeered a soundstage in the backlot of their Orlando studies and filled it with a working version of how every aspect of the band would work.

But, unlike the bank’s innovation lab, this wasn’t built with a special team. It was built by the same team that had day-to-day responsibility over the user experience of the parks. While they were working to make incremental improvements in the current park, they were also working on their new technological innovation.

Disney produced their wonderfully successful innovation without a dedicated innovation lab. They didn’t sequester “the best of the best” for seven years to produce this marvel. They used their regular production teams to deliver an innovation that has changed their entire industry.

Intuit discovered a game-changing opportunity.

In 2016, personal and small-business financial software maker, Intuit, released a niche product that became a huge revenue maker: Quicken Rental Property Manager. Like Disney, they didn’t build a special innovation team or create an in-house incubator to do it. They discovered the opportunity through old-fashioned user research.

A few years earlier, a couple of product managers were out visiting customers, observing how they use the company’s flagship Quicken product. These customers were individuals using Quicken to track their daily finances, creating budgets, and tracking expenses

During the customer visits, the product managers noticed a pattern they hadn’t seen before. Many of their users had a side hustle of owning one or more rental properties. For these customers, these properties were bringing in a steady revenue stream of rent, on top of their regular income.

Many of these customers were using Quicken to track the finances of these rental properties. Quicken wasn’t designed for this purpose and, to make it work, these customers had to jump through some serious hoops.

The customers were making it work. Across the Internet, rental property manager support forums helped tremendously, sharing tricks and techniques for making Quicken work for this niche purpose.

While Intuit had Quickbooks, a financial management product for small businesses, these part-time rental managers found the product’s functionality to be overkill. They didn’t need most of the functionality of Quickbooks, but needed more than what Quicken was providing.

The Quicken product managers took their research and went about building a new product. No special innovation team required. Just the tried-and-true method of identifying a problem and solving for it.

Innovation comes from those closest to the products.

On the surface, it may look like the bank’s innovation lab was the same as Disney’s Magic Band, and the software maker’s in-house startup program was similar to Intuit’s Retail Management team. Looking under the covers, we see two important differences.

The bank had a separate team who owned the job of producing innovations. This sent the message to the rest of the bank, especially those working on delivering products every day, that they weren’t supposed to produce innovations.

Yet, it’s these production workers who are closest to the problems that challenge the users. They know what constraints they’d have to overcome to make these ideas real.

A specially-staffed innovation team won’t have in-depth experience about how the product works. There are those who say that’s a good thing—that it won’t “bias” or “constrain” the ideas of the innovation team. However, our research suggests those the benefit of understanding the product and users far outweighs naiveté that comes with the “blue ocean” approach.

Disney had their members of their product design team involved in the Magic Band design from the start, even though it would be years before that effort showed any value. Their input about the subtlety and nuance of park experiences were invaluable insights to the project. When it came time to start executing, that team knew exactly what needed to be done.

Innovation comes from those who do the research.

The software maker enticed their smart, entrepreneurial employees to join their internal startup incubator. They’d hoped that the employees would come to the table with rich ideas because they were already familiar with the products and the users.

Yet, that isn’t what happened. The software maker just recreated, in a somewhat expensive form, another variant of “let’s all sit in the room and brainstorm innovations.”

Yes, they took a lean approach by turning those brainstormed ideas into hypotheses to test. Unfortunately, the hypotheses rarely proved to be close to something customers wanted and the company never got the runaway hit they’d hoped for.

Intuit did what Intuit has always been good at: getting into the field and meeting their customers and users where they are. The product managers weren’t looking for innovation when they started their research.

Instead, their open approach to field research and their desire to get constant exposure to their users, provided them valuable insights and patterns. They explored the users’ needs and challenges. They learned what would make a truly innovative product. And they knew what to do to deliver it.

Make every product team an innovation team.

Expensive innovation labs or internal startup incubators won’t get your organization the innovation it needs to become a leader in the marketplace. Instead, you need to use the resources that are already at your disposal.

Make every product team an innovation team. Send them in the field to conduct some deep hanging out with customers and users. Train them to look for ways to imagine what their product or service could be without its current constraints. Give them the time and resources to sort fleshing out those ideas.

Every product team has everything it needs to be an innovation team. We only need to empower them to see that’s their job.

Is ‘Delight’ the Best UX Design Intention?

May 9, 2019

In a fairly ordinary hotel, by the side of the swimming pool, on a wall that would otherwise go unnoticed, there’s a bright red telephone. But the phone isn’t what makes this distinctive. It’s the sign mounted above the bright-red phone.

It’s labeled “Popsicle Hotline.”

True story. The Magic Castle Hotel in Los Angeles has nice rooms, but they aren’t special. The beds are comfortable, but not in any special way. Even the outdoor pool area is like hundreds of other hotel pools. Except for the bright-red Popsicle Hotline phone mounted on the wall.

Picking up the phone engages the magic. A voice answers “Popsicle Hotline. How may I help you?” You tell the voice you’d like a popsicle. There’s a small discussion about the flavor.

Then a moment later, a hotel employee, dressed up in a tux and white gloves, appears by the pool with a silver tray. On the silver tray is your popsicle. You retrieve your popsicle and thank the employee, who promptly disappears back from whence they came.

How do hotel guests describe their experience with the Popsicle Hotline? One word: delightful.

Is delight always the right design intention?

Delightful seems to be the perfect word for a Popsicle Hotline. We think of design as the rendering of intent. Delighting poolside guests with a tux-clad employee presenting a popsicle on a silver tray was their intention. They rendered it wonderfully.

But should designers always aim for delight as their intention? There are many designers who say ‘no.’ They are quick to bring up scenarios where they believe delight isn’t the right scenario. They suggest that delight is an inappropriate intention for serious outcomes, such as paying your taxes or planning a funeral.

Respectfully, we disagree. We think, even in the most serious of outcomes, delight is always the right goal to aim for. Here’s why.

What’s the proper opposite of frustration?

We’ve all experienced designs that frustrate their users. We wonder, did the designers really intend this? Of course not. If we assume best intentions, those designers must be unaware that their design decisions left their users frustrated.

Yet, if it wasn’t their intention to frustrate their users, what was their intention? What is the opposite of frustration?

We believe the opposite intention of frustration is delight. As designers, our goal is to make designs less frustrating and, in the process of achieving that, we’ll make the design more delightful.

The Magic Castle Hotel’s designers certainly did that with the Popsicle Hotline. They made the poolside experience more delightful.

The role of expectations.

Ordering a popsicle is different than planning a funeral. Planning a funeral shouldn’t be a frustrating experience, but should it be a delightful experience? For the people involved, it’s a time of sorrow and loss. Should we try to delight them?

To answer this, we first need to look at what makes a design frustrating. Users become frustrated with a design when they can’t do what they want. Something in the design is preventing them from moving forward with their goal. That friction is what’s frustrating about it. Remove the friction, and the design becomes less frustrating.

A design becomes frustrating when the designers have missed an expectation.If an app has more steps than the user expects, the user becomes frustrated. If it asks for information they didn’t expect it to ask for, they become frustrated. If it doesn’t get them the outcome they expected, they become frustrated.

As our users work through our design, we can see where we’ve met their expectations and where we haven’t. In the places where we missed their expectations, we frustrate them. We make the design more usable by meeting their expectations.

Delightful = Exceeded Expectations

The Magic Castle Hotel met their guest’s expectations. Guests weren’t frustrated, but their experience wasn’t remarkable—until they encountered the Popsicle Hotline.

What made the Popsicle Hotline a delightful experience was that it exceeded their expectations. They expected an average hotel pool experience. Tux-wearing employees presenting free popsicles on a silver platter wasn’t at all what the guests expected.

Frustrations arise when the experience is worse than the user expects. Delight happens when the experience is better than the user expects.

The balance between frustration and delight.

The balance between frustration and delight is also true for planning a funeral or paying taxes. If we don’t design the experience well, we’ll miss the user’s expectations and frustrate them.

However, if we look for opportunities to exceed our user’s expectations, we can end up delighting them. If they’re planning a funeral, our design—no matter how delightful—certainly won’t make their loss go away. If they’re paying their taxes, it won’t reduce their pain from giving the government more money.

It’s very possible their expectations of these things are very low. Maybe they had bad experiences in the past. Or maybe they don’t know what to expect.

Intuit’s TurboTax designers created a free app, called SnapTax. The app scans a photo of a U.S. W-2 or 1099 employer form and uses that information to file the user’s taxes electronically. It reduces the time the user needs to prepare taxes from hours down to minutes. If the user expected it to take a long time with a jillion complicated steps, paying taxes with SnapTax is a delightful experience.

Funeral planning involves many decisions and having to spread difficult news to friends, family, and acquaintances. Helping the person planning the funeral get the word out, while minimizing the decisions involved would be delightful if it exceeded their expectations for the planning process.

Making our design more delightful is the best intention.

The Popsicle Hotline is a great way to make someone smile. We may not get a smile from our user when they’re scanning their W-2 form with SnapTax or making fewer decisions while planning a loved one’s funeral. Yet, they may still think of the process as delightful.

That’s because delight comes in many forms. It’s much more subtle and nuanced than many designers think. It can be silly, like the Popsicle Hotline. Or it can be fast, assuring, and comforting, like SnapTax.

With solid research, we can identify what our users are expecting from our designs. We can watch them interact with our designs. We can see where we’re frustrating them by missing expectations.

And we can look for opportunities to exceed expectations. By eliminating frustrations we’re pushing our design closer to meeting expectations. Push a little farther, and we’re in the territory of delight.

That’s how we’ll deliver delightful products and services to our customers and users. And maybe, just maybe, we can evoke a smile too.

Getting Executives to Understand the Value of UX Design

May 2, 2019

Leading up is hard. How do we get those above us—the people who give us the support, time, and resources we need to deliver great designs—to understand the value of great UX design?

Maybe we have a boss that understands how our work contributes value to the organization. But, does their boss? Or their boss’s boss?

They say they understand the value of design, but they prioritize other things ahead of our design work. They tell us we can’t do proper research or thoughtfully iterate because there’s no time. They emphasize shipping fast, hitting that critical deadline, or adding features that just show up in competitors’ products. They tell us design is important, but other things are more important.

This is the top challenge facing every UX design leader who attends our Creating a UX Strategy Playbook workshop. They tell us they want to move this needle.

These UX design leaders know they need the executive and key stakeholders to support their team’s work. They need UX design to become an important priority in their organization.

Fortunately, that’s exactly what we’ve designed our workshop to do. They’re in the right place.

How do UX design leaders successfully show value?

As we designed our Creating a UX Strategy Playbook workshop, we identified and collected the successful strategies employed by hundreds of UX design leaders. These leaders had unlocked the secrets in making UX design a top priority amongst their organization’s executives. We built the entire workshop around these successful strategies.

We start the workshop with the strategies around creating and socializing an experience vision. Successful UX design leaders use experience visions to capture the imagination of their executives.

The vision shows what their products or services could be like for customers and users. It shows how the organization can create dramatically increased customer value. The vision shows what great UX design can deliver.

Next up: The executive team’s current objectives. We focus on strategies that translate the experience vision into current business priorities that executives are currently focused on.

Are they looking to increase revenue? Build market share? Become competitive market leaders? We identify the UX design strategies that will deliver products and services that meet these executive goals.

Showing where value is currently lost.

We learned through our research that just showing an experience vision may not be enough to get the key stakeholders on board. UX design leaders often have to go further.

In the workshop’s first afternoon, we take apart the successful strategies we identified for socializing and sharing what it’s like for today’s customers and users throughout the organization. Where does our current design frustrate and impede users from getting value from the organization’s products and services?

Often, UX design leaders need to surface and socialize how their current designs hold their organization back. Executives and stakeholders—often insulated from the customer’s actual experiences—don’t realize how far away from the vision they currently are.

The leaders attending the workshop choose proven strategies that will work in their own organization. They select the strategies that expose stakeholders and executives to the current user experience. They learn how to prioritize the product roadmap to ensure the team delivers the most value with every future release.

Producing more value through better design.

During the workshop’s second day, we turn to successful strategies that increase the product team’s UX design capabilities. When the entire team has the right skills and knowledge, they produce better-designed products and services.

Our UX design leaders select the best strategies to turn their design team members into persuasive UX design leaders, who will evangelize and champion design with the rest of their product team. They’ll look to build a culture of continuous learning throughout the organization.

Building an action plan for success.

We learned in our research that successful UX design leaders don’t wait until their executives figure out the value of UX design on their own. Instead, they put together a plan with several key strategies to ensure their stakeholders will provide them the support they need. Attendees spend the afternoon of the second day building a custom action plan and putting together their own UX Strategy Playbook.

They identify the first steps they’ll take the moment they return to the office. With their Playbook in hand, they leave the Creating a UX Strategy Playbook workshop with everything their organization needs to deliver well-designed products and services.

The best workshop for UX Design Leaders like you.

We’ve packed this workshop with an intensive 2-day agenda designed to give you everything you need to tackle your toughest challenges. If you need more executive support to successfully lead design in your organization, you’ll want to sign up for this workshop.

We cap each workshop off at about 24 attendees. This gives me plenty of time to work directly with you on the ideal strategy for your team. Learn how your team can deliver better-designed products and services.

(Value ÷ Effort) x Confidence = Priority

April 26, 2019

When faced with a collection of potential features, design ideas, or research projects to prioritize, how do you move forward? Choosing which design effort the team will work on is especially difficult when every stakeholder, executive, and team member has a different opinion or favorite item they’d like to see tackled first.

I’ve seen a lot of prioritization schemes in my career. The one I favor most was taught to me by product manager extraordinaire, Bruce McCarthy.

What makes Bruce’s formula so great isn’t only that it delivers a straight-forward approach to identifying top priorities. It’s the collaborative method we get to those top priorities. Implementing the formula rewards teams that use their UX research strategically.

I love this. It gives me tingles just thinking about it.

Bruce’s simple formula looks like this:

(Value ÷ Effort) x Confidence = Priority

What Bruce’s formula says is this: we want to prioritize work that offers large value while taking a small amount of effort, assuming we’re confident in both our estimates of value and effort. With this formula, we can put what might otherwise seem like apples and oranges (or worse, apples and orangutans) on a single scale, where the highest results are what we should work on first.

How might we calculate Value?

To fill out Bruce’s formula, we need to arrive at a number for the first variable, Value. This number represents how much value we’ll produce when this item is delivered. As UX design leaders, we, of course, want to start with value to our users. Will this item provide a great solution to a challenging problem our users are facing? Does it get us closer to our vision of the ideal user experience? Or, will it be something they don’t really care about?

The beauty of Bruce’s formula is we can make this as simple or detailed as we’d like. A simple way to represent Value is 1, 2, or 3, for low, medium, or high. If we think the item is a critical solution to a big problem, we give it a 3. If it’s something users won’t care too much about, we give it a 1.

If we want to get more rigorous, we could estimate cost savings or how much revenue we might generate from implementing this idea. We could add what we believe is the value to the business.

Whatever we arrive at will be fine, as long as we arrive at every item’s Value using the same process. The rule is simple: the higher the number, the more valuable this item is.

How might we calculate Effort?

Next up, how much Effort might this take? Here, we can start with the effort to implement.

We can use a similar 1, 2, or 3 scale, representing whether it will be easy, medium-difficulty, or really hard to implement. Alternatively, we could use a more rigorous calculation such as the number of people multiplied by the number of weeks to complete the project. We could even use the dollars the organization will spend on it.

For more detail, we can add in other costs, such as how much effort it will take for our users to switch over. (This is especially important in products where new functionality is disruptive to habits our users have already formed.)

If we’re implementing this item to attract new customers, we can add in the effort to sell. Plus, we shouldn’t forget the effort to support the feature once it is released.

Like Value, we can adapt the amount of detail we consider for Effort any way we want, as long as, the higher the number, the more effort we believe this will take.

Dividing Value by Effort gives us a quick look at how the items rank. A design idea that provides a great solution (Value = 3) and will have an easy implementation (Effort = 1) resolves to 3÷1 or 3. Meanwhile, another idea that has a medium value (2) and medium effort (2) will resolve to 2÷2 or 1. The design idea with a 3 is a higher priority than the one that came out a 1.

How might we calculate Confidence?

(Value ÷ Effort) is a great start, but where are all these numbers coming from? That’s where Confidence comes in.

Bruce wisely puts this on a scale from zero to one. If the Value and Effort numbers are a complete guess, we’d give them a zero. If we’re absolutely sure we know the Value and Effort are correct, then we’ll give them a 1.

We might use this scale for each variable:

  • Complete guess = 0.0
  • We’ve found a little evidence = 0.25
  • We’re fairly sure = 0.5
  • We’ve done a ton of research and are very sure we’re right = 0.75
  • We’re absolutely, incontrovertibly sure = 1.0

We can rate our confidence in both Value and Effort separately. If we’ve talked with a ton of customers who all told us basically the same thing, we can give Value-Confidence a 0.75. If we’ve worked with developers on a technical proof of concept that showed it can be done but didn’t explore edge cases, we can give Effort-Confidence a 0.5. By averaging them, we get (0.75 + 0.5) ÷ 2 or a Confidence of 0.625.

Using Bruce’s whole formula, we can see how this plays out.

(Value ÷ Effort) x Confidence = Priority

(3 ÷ 1) x 0.625 = 1.875

1.875 is our calculated priority for this design item. By itself, it’s a meaningless number. However, when we calculate other design item priorities the same way, we can see what we should work on first.

The biggest benefit? The discussion while rating.

It’s great that Bruce’s formula gives us a clear calculation to determine our highest priority items. However, what I love most is how it gets everyone talking about what should go into calculating Value, Effort, and Confidence.

We involve stakeholders, executives, and other key team members in coming up with each number. The numbers can mean whatever we want them to mean. Yet, to fill out the formula, we have to have an essential discussion about what these numbers mean.

We discuss the evidence we’ve collected for Value, hopefully from research we’ve conducted with our users. We discuss the evidence we’ve collected for Effort, hopefully from experimentation, iteration, and prototyping projects, that give us real insight into what it will take to deliver. We discuss our Confidence from how much evidence we have, versus how much we’ve had to guess.

Bonus: The reward from solid research.

The Confidence number penalizes us when we’ve wrongly guessed the value or effort. It rewards teams that invest in research to collect data that becomes the basis of our confidence. We’re not happy with a low Confidence number? Ok, let’s do more research and boost it.

Any process that pushes our teams to appreciate the contribution of research is a winner in my book. Bruce’s formula does just that.

This is how we make research a strategic ingredient in delivering better-designed products and services. (Ooh! There are those tingles again.)

The Need to Think and Talk like an Executive

April 24, 2019

Here’s a hard truth user experience design leaders find themselves learning: No one will buy into your UX design ideas if they can’t see how those ideas matter to them.

This is especially true for your organization’s leadership. They need to see how all those great UX design ideas will push forward their top priority, helping the organization. If they can’t see it, they won’t get behind your great ideas.

Within an organization, a design leader can only do so much on their own. At some point, getting executive buy-in becomes a necessity. Design leaders will then need to win over their executives by showing them how their UX design ideas make the organization stronger.

Three strategies; but only one works at scale.

We see many design leaders encounter the challenge of getting the executive buy-in they need. There are three basic strategies they can employ to overcome this challenge.

Strategy 1: Don’t ask permission. Instead, beg forgiveness.

This is often the first strategy design leaders try. Just push forward and try to build their great design without any organization leaders noticing.

This approach works just fine when the design team is small and capable of running under the radar. Even as the team grows larger, this will work only for small UX design initiatives.

However, as the team tackles bigger UX design challenges, it’ll become more difficult to always work in stealth-mode. Without the support of the executives, the team’s efforts will likely become stalled.

Strategy 2: Become design evangelists.

When the first strategy doesn’t work, design leaders often turn to a second. They try to educate their executives on what design is and how it helps. These design leaders reach for statistics-filled powerpoint decks on how design has helped other organizations, hoping to persuade the executives that their own organization is behind everyone else.

Sadly, this strategy rarely works. The executives are quick to argue that “it’s different here” and “we’ve done just fine without design until now.” The team is once again without the executive buy-in they need.

Strategy 3: Translate design outcomes into the executive’s priorities.

Left with no other viable alternatives, design leaders turn to this approach. Instead of teaching executives about the value of design, the design leaders have to reframe their team’s initiatives by showing how it helps the organization.

This is the only strategy that can scale. It requires design leaders to face an uncomfortable truth. They have to start thinking and talking like executives.

The good news is it’s not that hard. It’s so easy that even executives can do it.

Money is the language executives bring to the table.

The key to thinking and talking like an executive is money. Not having it. But using it to describe what the value of the design is and how it will pay off for the organization.

Money is the common language across an organization’s operations. Dollars (or euros, pounds, yen, rupees, or any other currency) are a way for executives to explain where they want to focus efforts and what they hope to get from those efforts.

This is true, whether we’re talking about a commercial business, a university, a non-profit, or a government agency. In every organization, no matter what type of organization it is, every department needs people, equipment, materials, or other resources. We can measure those resources in dollars. Similarly, those departments deliver new customers, better efficiency, or some other value back to the organization, which we can also measure in dollars.

Does the Marketing department want to sell more product? They’ll need money for a campaign. The amount of money they spend on that campaign has to be less than the amount of money the campaign will gain, or it’s not worth doing.

Does Manufacturing want to become more efficient? They’ll need money for new equipment and processes. The money they save for the organization from the efficiencies has to be more than the money they’ll spend on the equipment and process revamp. If it’s not, it’s not worth doing.

The same is true for UX design. UX design costs money. We have to pay designers. We need to do research. The money we spend on research, design, and production has to be less than the money the organization will gain because we’ve implemented that design. If it’s not, it’s not worth doing.

This is a simplified notion of a return on investment. It seems obvious when we say it this way. Yet, it’s exactly what an executive needs to get behind an idea.

Money is the language executives bring to the table. If we want a seat at that table, we need to speak that language.

Profit has gotten a bad reputation.

These days, capitalism takes a beating. Unfortunately, its reputation for destroying our great society has been somewhat earned by a few people taking advantage of a lot of other people.

A bystander injured in the war on capitalism is the concept of profits. The idea that an organization works hard to make a profit tends to be the poster child of the anti-capitalists and signifies everything that’s wrong with today’s world. Their message is that the world would be a better place if we didn’t always focus on making a profit.

As design leaders, we need to look past that. Not because we need to support capitalism and all the trouble it brings. But because, at the center of how we get our work done, we need profits to support our business.

The formula for profit is simple: revenue minus expense. The organization needs more money coming in than it spends.

If it has less money coming in than going out, it’s losing money and that’s not sustainable. Over time, the organization will no longer afford to function and will go away.

We need our organizations to survive. Therefore, we need profits.

Do we want to grow our UX design team? Do we want to pay for more research? That money needs to come from profits.

Profits pay for growth. They often pay for that growth before increased returns come from that growth. If we want to hire new designers, we must pay for them with the profits we’ve already made. That’s true even if hiring those new designers will eventually bring in more revenue once they come up to speed.

(Startups, who don’t have profits yet, use investment money to fund their growth instead. Years later, they’ll pay their investors back with the profits they earned because of their investment.)

As design leaders, we’re responsible for ensuring our organization has the profit to support the growth we need to deliver better-designed products and services.

The five questions every design leader must answer.

Design can contribute to profit in five basic ways. We can think of these as questions:

How might our UX design initiative…
…increase overall revenues?
…decrease operational costs?
…increase revenues from new business?
…increase revenues from existing business?
…increase shareholder value?

These five questions are what executives ask of each initiative their organization undertakes. When marketing wants to launch a campaign, they ask these questions. When manufacturing wants to retool, they ask the same questions. We need to have answers ready for these questions to showcase the value of our UX design initiatives.

It’s very possibly our initiative may only address one of these questions, like decreasing operational costs. Or maybe it’s two of them, like increasing revenues from new business, which also increases overall revenues. If we can answer all five, well, we’ve hit the jackpot.

It’s important that we can answer at least one of these questions about our UX design initiative. If we can’t, what value is the initiative bringing to the organization?

How might UX design increase overall revenues?

When design increases sales, that’s a direct revenue increase. That new product we’re launching that’ll take over the world? That’s an easy one.

However, sometimes we get revenues from indirect sources. For example, Paypal has a free service that lets its users send money to or receive money from someone else. If the service is free, Paypal isn’t making any direct revenue from it.

Instead, Paypal generates indirect revenue off of interest from the transfers. I might send you $100 using my Paypal account. To do that, I have to first move $100 into Paypal’s bank account. Once I send it to you, it might take you a day or two (or a year or two) before you transfer it from Paypal’s bank account into your bank account.

In the meantime, the money is just sitting there, in Paypal’s bank account. That money earns interest. There’s not a lot of interest for $100 for one or two days. But if millions of people send millions of dollars each day, that interest starts to add up. Every time Paypal’s design team plans a new initiative to make transferring money easier, they are growing Paypal’s indirect revenues.

We want to look closely at our team’s UX design initiatives. Could they increase direct revenues? How about increasing indirect revenues? Is this where the investment in our design returns value to our organization?

Keep in mind, not all organizations are businesses that sell things. Nonprofits and universities bring in revenue through donations, tuition, and grants. Government agencies bring in revenue through taxes and legislative funding. UX design initiatives that increase the visibility of the organization’s good work or makes revenue collection easier, increases an organization’s overall revenue.

How might UX design decrease operational costs?

Decreasing operational cost is often the easiest place for design leaders to start. Poor user experiences cost organizations money. When we find costs associated with our poor UX, we can decrease operational costs.

If the product or services current design is frustrating, the users might rack up support costs. If our own employees are using inefficient tools, that’s racking up efficiency costs. If our developers are producing new features that nobody ends up using, we’re racking up development costs.

All these costs could be reduced with a better user experience. Our design initiatives can decrease operational costs.

How might UX design increase revenue from new business?

A key tool for organizational growth is reaching new audiences. When executives talk about growing their market share, this is what they’re referring to.

Many products or services become so complicated that new users can’t make sense of it. Only the users who grew up with it can make it work. This prevents new users from participating.

If our UX design initiatives make it easier for new users to give us money, then we have a solid answer for how we’ll increase revenue from new business. By speaking to the obstacles new users have today, we can show how we’ll grow revenue from this potentially large audience.

How might UX design increase revenue from existing business?

While growing market share is essential, it’s costly. We have to find the new users and convince them our product or service is what they need. We need to get them to give up whatever they’re currently doing and use our solution instead. Just identifying who these potential new users are is a costly endeavor.

If our UX design initiatives can convince our existing users to give us more revenue, that’s much less expensive. We already know who those folks are. In many cases, we know a lot about what they need from our product or service.

For example, products where customers pay on a subscription basis can see fewer cancellations if they improve their user experience by making it easier for their product to deliver its value. Customers of an online music service are more likely to stay subscribers if they can easily access to the music they love.

Renewals, upgrades, and purchases of follow-on products and services can be the lifeblood of some organizations. Eliminating the poor design that turns existing customers away, while creating enticing follow-on products or upgrades is a great way for design teams to add to the organization’s bottom line.

How might UX design increase shareholder value?

In recent years, shareholders have gotten a bad name, making people think of Wall Street-style greed and short-term quarterly-results thinking. However, for most organizations, the vast majority of their shareholders are long term investors, like pension funds and insurance annuities. These are investors who are not looking for short term returns.

These shareholder investors are looking for a long-term return on their investment. They think in terms of decades. They want the organization to still be here a decade from now.

(This isn’t only true of commercial businesses. The backers of nonprofits and the funders behind government programs are thinking long term too.)

Up until this point, we’ve talked about returns that our UX design initiatives will produce within a couple of years. Shareholder value creates returns of much longer periods. Can our UX design initiative help our organization fend off its competition? Can it make our organization more sustainable over the next decade? How does the initiative help with our organization’s long-term plans?

This question forces the design leader to think in terms of long-term value. Is there a way our great UX design ideas can help us build a better, more solid organization?

We need to think and talk like an executive.

Over the last few decades, we’ve seen how smart UX design drives organizations to deliver better products and services. This is no longer just a theory. It’s been proven time and time again.

What else has been proven? It won’t happen by accident. It needs a strong design leader to make it happen inside their organization.

That design leader won’t make it happen if they try to work on it without executive support. And training their executives on the whys and hows of design never works.

The only way that design leaders will communicate the value of their team’s UX design initiatives is to talk to the executives in a language they already understand. To make this happen, design leaders need to think and talk like an executive.

The place to start is with these five questions. Once we know how UX design might benefit the organization, in terms of value that executives understand, we can communicate it clearly.

That will get us the executive support we need. And that support will, in turn, drive the entire organization to deliver better-designed products and services.

The Strategies Behind Effective User Research

April 19, 2019

The key for teams to deliver more innovative, well-designed products and services is clear. We can describe the key with one word: exposure.

The more our team members are exposed to the users of our designs, the better our designs become. When team members don’t have enough exposure, they make poorer design decisions. Those poor decisions lead to designs that frustrate our users.

Frustrated users will jump at the opportunity to use a better-designed product or service. To be competitive, we want our products and services to be the ones our users jump to use.

To make this happen, we need a deep understanding of how our designs frustrate our users and where our designs can be improved. To get that deep understanding, everyone on our team must be exposed to our users while they’re using our product.

Everyone needs exposure

Everyone involved in making and influencing design decisions need this exposure. It’s not just the designers. We must expose our developers, product managers, stakeholders, and other influencers who guide the decisions we make to our users. Even that executive who regularly swoops in and poops all over our design (a process known as the seagull maneuver) needs exposure.

When someone influential doesn’t have enough exposure, the decisions they make are not based on what the users need. They are based on opinions.

At best, those decisions are based on what they themselves might need. At worst, the decisions are based on guesses. Unfortunately, it’s unlikely those decisions are the right decisions.

The maturity of our user research efforts determines the number of avenues we can use for exposing our team members to our users. As our user research efforts become more mature, there are more ways to see what our users need from us.

Strategies to increase exposure

During our 2-day Creating a UX Strategy Playbook workshop, an entire afternoon is dedicated to exploring the strategies organizations successfully employ to increase user exposure on their teams. Design leaders at the workshop explore dozens of strategies, to identify the ones most likely to work in their organization.

Here’s a small sample of the strategies specific to increase exposure. How many of these strategies could your team be doing better?

Strategy 1.03: Initiate a usability testing program - While many teams already have established usability testing efforts, there are still many who don’t do this regularly. See how decisions have an immediate effect on how users interact with your designs.

Strategy 2.02: Institute a field visit program - Get into the user’s environment to see how the work they do and how your design makes a difference.

Strategy 2.03: Socialize exposure - Make sure everyone in the organization sees how increased exposure improves the design of products and services.

Strategy 2.20: Institute identifying customer problems using the Kano model in regular field study synthesis - Focus the team’s research analysis on reducing complexity, meeting expectations, and creating delightful experiences.

During the workshop, we’ll explore many other strategies specifically geared toward increasing the exposure of team members. Here are a few more:

Strategy 2.16: Institute a formal discovery phase for every project
Strategy 2.29: Institute including executives and key influencers on field visits
Strategy 3.19: Integrate multi-variant tests with qualitative research to learn why variants work
Strategy 3.39: Institute program for everyone to answer support emails and calls

These are just a few of the 130 strategies we explore in the Creating a UX Strategy Playbook workshop. During the workshop, you’ll identify which strategies are most effective for your team. You’ll assemble an action plan in the form of a playbook that details exactly which strategies will work best.

If you want to deliver more innovative, well-designed products and services, this is the workshop for you. You can read more about the strategies and how the workshop works at Playbook.UIE.com.

We limit every workshop to 24 participants. Because design leaders often bring their peers from development and product management to help choose their best strategies, the workshop fills up quite quickly. Register today.

A Favorite User Research Trick

April 12, 2019

“So, what do you think?”

That’s the question I posed to the executive stakeholder as we came out of an informative research session.

“It was about what I had expected,” the exec replied. How could that be? The participant in the session just exposed major challenges I knew none of us had considered before. How could that be something the executive expected.

This kept happening. We’d go into sessions that uncovered remarkable findings and the executives who observed would emerge claiming it was exactly as they expected. We listed all of the things we learned while the stakeholder struggled to acknowledge there was anything they didn’t expect to hear.

Asking for expectations up front

I made a change to my routine. While the observers were gathering before the next session, I described everything we knew about the participant we were about to meet. Then I asked each observer, “What do you think we’ll see in this session?” I walked through each of the research questions we’d plan to investigate and asked what they thought we’d learn from the participant.

I saved the executive for last. They had just heard the wide variety of guesses everyone was making and could now safely add their own to the list.

And guess what? The session didn’t go as anyone expected, even the executive.

When we emerged, I asked the exec what they’d thought of the session. “Wow, that was a huge surprise. It wasn’t at all what I had expected.” They went on to list all the things they had learned from the participant. Success!

Overcoming bad training

In many organizations, executives are trained to never show surprise. It’s part of the organization’s culture of pretending everything is always under control. Executives are supposed to be the ones in charge, they’re expected to know what the outcome will always be.

Of course, executives don’t always know. Nobody can always know. And the entire point of user research, whether it be user interviews, usability testing, field studies, or some other method, it to inform us of the things we couldn’t possibly know otherwise.

Every so often, someone gets it right!

I’m surprised when someone accurately predicts what we’ll learn. It’s happened a few times.

I keep an eye on that person. If in subsequent sessions, they continue to predict what we’ll learn from the participants, we’ll want to take advantage of their insights. They’re obviously in touch with the users in some magical way.

Having someone with this knowledge and experience on the team is truly valuable. We can trust them as a Subject Matter Expert. They’ll be a valuable resource.

Of course, we’ll continue to ask them to make predictions, to learn where the boundaries of their knowledge and experience extend. Everyone has their limits.

Part of our regular research protocol now

I now ask “What do you think we’ll see in this session?” before every session I conduct. And I rarely get ”it was about what I expected” as an answer because we have documentation showing it wasn’t at all what they expected.

I’ve found this to be a useful technique for helping every observer head into each research ready to experience a broader understanding of who the users are and what they need. This is key if we’re to deliver better-designed products and services.

How a Team Matures Its User Research Integration

April 10, 2019

The order came down from high up (or wherever orders come down from): We need to implement an export data function in the app. That’s all we knew. Except there was a rumor of a big deal being held up until someone got their export data function.

The stage of our team’s user research maturity will determine how we’ll handle the user research for the export data function request. The more mature a team’s integration is, they more data and insights they have to make smart design decisions.

Stage 0: No user research integration at all

Starting out, our team hasn’t built up any user research capability yet. The developers go ahead and implement an export data feature based on what they think the requirements are, making guesses for anything not specified. They design something the way they themselves would like to use it. (A technique we call self design.)

It isn’t until the feature is delivered and users start using it that we get any feedback at all. What feedback we get likely comes from support calls or sales engineers, reporting back what they’re hearing from the customer.

The feedback is likely distorted and incomplete, so any recommendations or fixes that come from it aren’t effective. The most likely scenario is the feature stays in its initial design until some future feature requires a change.

Stage 1: Basic usability testing

Our team now conducts usability tests on new features. Once the developers give us something to put in front of folks, we gather up several users and ask them to give it a try.

When the participants show up, we jump right into a session. We give them some tasks to perform, based on what we imagine how our users will employ the export data function.

As they try to export the fake data we’ve created for them, we capture all the places where the interface confuses them or prevents them from accomplishing the task. When we’re done, we write a report.

Like Stage 0, our developers first took a crack at building what they thought would be a good response to the requirements. We used what they built for our test. Our testing sessions tell them if they were close or not.

Of course, we need to wait until there’s code written and stable enough to test. And there’s a good chance that there’s a hard deadline to ship the feature soon. That means we have to rush to get all the testing done that we’d like.

When the developers’ initial design didn’t work well for the users, there’s a big discussion about whether we ship what we’ve got anyways. (We do.)

Stage 1.5: Usability test tasks come from support

Our team starts working closely with the support and customer success teams. We hear directly from them about what our users are trying to do with the export data function. More importantly, we hear where it’s not working well.

As we conduct more usability tests on the functionality, we use this information to help us craft our tasks. We focus our research on problems users contacted support about, to ensure we better meet their expectations.

Stage 2: Interview-based task design

We upped our usability testing game. Instead of crafting test tasks based on how we imagine users will use the export data function, we use interview-based tasks instead.

Now, when recruiting participants, we screen them to ensure they’re likely to use the export data function in our design. Upon their arrival, we start the usability testing session with an interview. During that interview, we probe to understand how they might use the export data function. We work with them to jointly create a test task, which we then ask them to complete.

Even though no two users will use the same tasks, we learn much more about the export data function and what our users are trying to do. If we can do this testing early enough in the feature’s development, we can influence a better fit for the design.

Stage 3: Basic field research

Time to experiment with getting out of the building and heading to where the customers are. We are not trading in our usability testing program for this new field study work. That’s still happening. By doing both, we make our insights richer by better understanding the contexts around features like export data.

We’ve broken through the corporate politics that try to separate us from real users in their own environment. Now we can see where and how our users work with our design.

When we arrive for a field study, our research participants show us what they’re currently up to. Because the export data function is not something our users frequently need, the chances are slim that we’ll see them use it. However, we may see many upstream or downstream activities.

Researching in the “wild” lets us see more of what our users’ lives and work environments are like. We can feed this into the tasks and environments we design for our continuing laboratory studies. Even though our exposure to the export data function usage is limited, we’re learning a ton about our users overall.

Stage 4: Focused field research

We’ve upgraded our field research know-how to identify and recruit those field study participants who will use the export data function when we visit. Now we see what leads up to exporting the data, and what they use the exported data for.

Because we can focus in on the right users at the right moment, we can see a broader sample of issues that arise. We’re seeing more subtlety and nuance in how people use our design than we’ve ever seen before. In turn, this helps us identify what works best for our users.

Stage 5: Longitudinal studies

We now continually study the end-to-end experience of our users. We don’t wait to be told from above that there’s a need for the export data function. We know about it before they tell us. Our research told us there was a need before the customers mentioned it to the sales folks.

Our research techniques have become more nuanced. We improve our ethnographic methods with some deep hanging out with our users and customers. We experiment with storytelling listening techniques, such as collective story harvesting and World Café. We exercise our data science skills, deriving meaning from by crafting custom telemetry from our designs.

All this advanced research informs our entire team, feeding insights to prioritize their work. It provides a shared understanding so other team members are clear on the intention of the design. The better they understand the design’s intention, the more likely they’ll create something that matches it.

Stage 6: Strategic user research

Up until this point, our research efforts primarily focused on the current functionality. Yet, with our deep knowledge and understanding of the full user experience, we now play a strategic role throughout the organization.

Our research has become instrumental in picking strategic priorities for the product as a whole. The ethnographic field techniques are showing us where we can create a competitive advantage, not just from holes in our own experience, but from gaps competitors haven’t identified either. These strategic insights become the basis of the themes on our product’s roadmap.

Our research also feeds into the overall vision of a product’s experience, helping us understand exactly what work is left for our teams to do.

It’s team maturity, not organization maturity

These are the individual stages each of our organization’s teams go through. Each team goes through this process at their own rate.

Even if you’re a researcher that’s assigned to multiple teams, you’ve probably noticed your teams each have a different pace of increasing the user research integration into their work. Reducing friction for growing their research capability is the best way to help them speed it up. For example, you could build a centralized capability for recruiting, making it easier for teams to select participants for studies on short notice. (Studies are always on shorter notice than we’d like.)

Because every team is at a different stage of maturity, there’s no real advantage to assess the overall organization’s maturity. It’s better to track the progress of individual teams and identify what might nudge them to the next stage.

Beyond technical skills

At every new stage, our initial focus is on the new technical skills we must master to be good at our jobs. Yet, it doesn’t stop when we’ve mastered certain techniques.

We also must learn how to make our research valuable to the teams we work with. They need to feel our research is invaluable to their work.

We want to discover what piece of research will be so beneficial that our teammates will demand more. We need to learn what will make them so hungry for our research, they feel they can’t live without it.

Research can’t be a separate function

Outsourcing your research is like outsourcing your vacation. It gets the activity done, but it doesn’t realize the value. If only your researchers are doing the research, you’re doing it wrong.

For research to be truly valuable, everyone on the team has to be part of it. Everyone should be a part of the planning and have a say in who our participants will be and what we want to learn from them.

Every member of the team needs to observe the research and be part of the synthesis of the outcomes. They need to feel ownership in understanding the problems users have and potential solutions.

We can’t achieve this if we’re the intermediary between the rest of the team and the users. They need direct and constant exposure to the people they’re designing and developing for.

We need to teach them how to truly see their users and learn how to make great design decisions as a result. We’ll know we’ve succeeded when the team comes to better design recommendations than we would ever have made ourselves.

Researchers need to be research leaders

For the team’s user research integration to mature, a major role for the team’s researchers is to constantly be growing the team’s research capabilities. It’s our job to be thinking about how we’ll get to the next stage, while, simultaneously, we focus on how to better work at the current stage. We can’t skip a stage. Each is necessary a step to the next one.

We need to champion a culture of continuous learning—not only for ourselves—but for our teammates too. Every day, we need to celebrate what we’ve learned about our users, those users’ needs and challenges, and the techniques that helped us uncover them.

Much of a successful research practice is building relationships. Relationships with the gatekeepers to the customers, the customer success team, the customers, and their users. We need to earn their trust and respect their own needs. This, after all, are the key traits of a great leader.

User research is about growing and learning. Every day, we get better at what we do and our teams learn more about the people they’re designing for. This is how our organization will deliver better-designed products and services.

Solid User Research is a critically important capability to become a design-led organization. In our 2-day, intensive Creating a UX Strategy Playbook workshop, I’ll work directly with you and your team leaders to craft your ideal strategy to ensure your teams have the best UX research skills and experience.

We cap each workshop off at about 24 attendees. This gives Jared plenty of time to work directly with you on the ideal strategy for your team. Learn how your team can deliver better-designed products and services.

The Truth About UX/UI Designers

March 29, 2019

UX/UI Designers are real. They aren’t a mythical creature, as many are quick to suggest. It’s a real design position filled by real designers, many of whom are capable of great work.

The UX/UI designer works on both the design’s user experience and the user interface. In the right position, they’ll create easy-to-use, effective, and delightful designs. As a collaborative team member, they’ll bring applications and websites to life. Hiring a UX/UI designer is very attractive to small teams, especially when there’s only one available design opening.

Once on board, they specify the overall flow and feel of the design, while getting into the specifics of every interaction. The UX/UI Designer’s expertise contributes to the design’s information architecture, visual design, and interaction design. Some UX/UI designers can even write preliminary front-end code to demonstrate their intention with the design.

If this sounds too good to be true, you’re in good company. There are lots of designers who contend that no such designer exists. They believe nobody can do all those things.

The truth is they are wrong. There are UX/UI designers in the world. Good ones, too.


Any designer is only as capable as the skills, knowledge, and experience they’ve accrued over their career. However, there’s no hard-and-fast rule about which skills, knowledge, and experience they can acquire.

If we think of experience design as five levels of resolution: eco-system design, organization-wide design, application/site-wide design, screen design, and conversation design. To successfully design in each resolution, the designer needs the requisite skills, knowledge, and experience to get the most out of that resolution’s specific tools, methods, and principles.

A UI designer focuses on what’s on each page or screen of a design. They draw on their expertise to know how to layout the information on the screen. They design effective forms and dialogs to guide users to efficiently and effectively interact with application or web site.

A UX designer employs different expertise, looking at the entire application or website works as a whole. They design the navigation, the overall interaction model, and how the user accomplishes their overall goal.

A UX/UI designer has the skills, knowledge, and expertise to work at both the application/site-wide resolution and the screen resolution. They can zoom into the screen resolution when that’s what’s required, then zoom back out to the application/site-wide resolution to work on the bigger picture.

Expertise is Not a Zero-Sum Game

There’s a common belief that anyone who tries to do both UX and UI design won’t produce quality work The old mantra “Jack of all trades. Master of none.”is often recited in these instances.

This thinking assumes that learning is a zero-sum game. That if you’re a UX designer, then you couldn’t possibly also do UI design work well. You’d never have enough time or opportunity to learn the necessary skills to master both effectively. This just isn’t true.

Think of it this way: It’s quite possible to be both a highly-skilled UX designer and an excellent ukulele player. (In fact, there are several excellent ukulele-playing designers in our community.) Putting in all the hard work to master the ukulele doesn’t make your design skills deteriorate. Why would learning UI skills suddenly deteriorate your UX skills?

When skills overlap, there’s added benefit. There’s not a whole lot of overlap in the skills needed to master both the ukulele and UX design. However, there’s a fairly large overlap in the skills needed to master both UX design and UI design. Mastering what’s necessary at an additional level of design resolution will make you a better designer, not a worse one.

There’s nothing special about UX and UI skills. We could easily be talking about service design skills or chatbot design skills.

Skills are something anyone can learn. Put in the effort, get lots of practice, and find a good teacher and mentor. You’ll successfully learn all of the skills you need.

Designers with the right motivation and find themselves in the right opportunity can put in the hard work to master both UX and UI skills. You frequently see this with hardworking designers in organizations where they’re essentially a design-team-of-one. They have no option other than to build up their UX and UI skills together.

The Challenges of Hiring UX/UI Designers

It’ll take time to master both UX and UI design. When you’re looking to hire someone, you’re looking for someone who has been working in design for a while.

Not every designer has developed both of these skill sets. The pool to recruit candidates from is much smaller than when you’re seeking a UX designer or UI designer. The smaller pool will make hiring more difficult.

While UX/UI designers are in growing demand, there are not many available. The laws of economics dictates that they should demand a higher salary than their more plentiful counterparts. It may even be higher than if you hire both a UX and a UI designer separately.

This all means looking for a UX/UI designer will take longer and cost more. If you’re in an geographic area where there are very few people with both UX and UI skills or your salary budget is too small, a UX/UI designer may be outside your reach.

A Growing Number of UX/UI Designer

Every year, more designers are acquiring the expertise they need to tackle both UX and UI work. As teams become smaller and more agile, there are more opportunities for designers to expand their capabilities. This will steadily increase the number of available designers capable of doing both UX and UI work.

Teams currently staffed with both UX designers and UI designers would benefit by providing growth opportunities to acquire their complementary skills. By expanding everyone’s skills, the team itself becomes more agile. This is an effective way to deliver better designs faster.

Zooming In and Out of UX Design Resolutions

March 26, 2019

In 1968, world-renowned designers, Ray and Charles Eames, created a 7-minute short film called Powers Of Ten. The film starts with an overhead shot of a couple taking a picnic in the park. A narrator explains we’re seeing a 10+00 meter view.

Through an amazing progression, the camera starts to pull back, showing us views from 10+01 meters, then 10+02, 10+03, and so on, until we’re looking at the Milky Way galaxy at a resolution of 10+21 meters. The camera then reverses direction, zooming back in, until we see cells, DNA, molecules, atoms, and finally electrons at a resolution of 10-14 meters. The movie is mesmerizing and a technical wonder for its time, especially considering that this was before the advent of computer-generated animation.

Ray and Charles Eames Power of TenRay and Charles Eames Power of Ten. Courtesy and © 1977, 2019 Eames Office, LLC (eamesoffice.com)

Every time the camera zooms to a new power of ten, we’re treated to a completely different view of the world we live in. The camera never shifts its view horizontally or vertically. It’s always focused on the same point. Yet, what we see never looks the same twice.

The resolution of each zoom level has changed, by a factor of ten. Each pixel now shows us different information, at a different visual resolution.

At the 10+00 meter view, we can clearly see the blanket. Yet, at 10+05, the blanket has completely disappeared from view and we’re now looking at the city of Chicago and Lake Michigan. The blanket’s been encoded into a single pixel in that view of the city.

Starting with Screen Experiences

We can think of user experience design also as a series of resolutions. They aren’t as precise as the Eames’s Powers of Ten. However, each resolution is pretty distinct on its own.

Back in the 1970s, before we called anything UX, those of us who worked on building easy-to-use systems focused primarily on the screens. The computers of that age were primarily mainframes and minicomputers. Users would enter data through dumb terminals, often referred to as “green screens.”

We wanted to make sure each screen was efficient, effective, and usable. We studied instances where mistakes commonly happened. We iterated over the screen’s design, to ensure that the operators could enter data quickly and comfortably. Users were often trained, so making the system self-evident was less of a priority.

Next Up: Application and Site-Wide Experiences

Unbeknownst to us, we were working at a low level of resolution. It would take us more than a decade before we’d zoom out to a new resolution.

When personal computers came about, the dumb terminals went away. The designs we created now had more than a single screen. They formed applications and websites that our users had to navigate.

The screens were still there, but now we had to help our users. It’s far less likely they received any training. This required that we change the way we worked from the screen resolution.

We now had to think about the design of menus, wizards, and profiles. Concepts, such as progressive enhancement, helped us keep the overall flow moving and the level of detail tailored to users’ needs. Our designs had to become intuitive and obvious as to what to do next.

Zooming Out to Organization-Wide Experiences

When mobile devices became more prevalent, our users found themselves often interacting with multiple applications or web sites as part of their total experience with our organization. We could no longer focus on just the single application or site. We had to think about experiences that spanned multiple applications and multiple sites, along non-digital touchpoints, like our salespeople, guest services, or support centers.

In what we now call Service Design, we moved to a resolution that expands the users’ experiences across a greater time and distance. The digital components of the experience still need design at the application/site and screen levels, but the challenges we’re tackling at the organization-wide level are very different.

At this level, we’re dealing with different organizational departments and their business needs. We’re coordinating the user experiences, not just for a single customer, but for all of our customers, users, employees, and partners.

Each Resolution Demands Different Tools and Methods

Much of the Powers of Ten film is about how the park looks from space. The images shown fall into the world of astronomy.

Astronomers have a range of telescopes they use. These include small tripod-mounted telescopes for home use, observatory-sized telescopes, big radio telescopes, and even space-based telescopes like the Hubble.

Each of these telescopes does a different job. As they get larger and more sophisticated, the telescopes can look deeper into space, picking up details that others can’t see. What the astronomers can see changes based on the power of the telescope.

In UX design, our tools and methods also need to change, depending on which resolution we zoom into. For screen-level UX design work, we created tools like usability testing and form design heuristics, to help us see problems at the screen resolution.

For application/site-wide UX design, we created sitemaps and wireframes. These tools aren’t as useful for screen resolution work, but they’re perfect for application/site-wide work.

For organization-wide UX design, we created design systems, service blueprints, and customer journey maps. Again, these are only of minimal value when we’re working at the lower resolutions.

Like the astronomers, we need to adjust and change our tools when we want to work at a different resolution. These different tools require new methods and techniques. The change in scale requires us to think differently about what we’re building.

Challenges Change at Different Resolutions

In addition to changing tools, the challenges we face also change. Let’s say we wanted to work on reducing pollution from human waste.

The Powers of Ten film starts with a couple having a park picnic at the 10+00 meter view. At that resolution, the big pollution challenge is dealing with litter. We might consider how many waste cans are placed in the park and how often they should be emptied.

When the Powers of Ten camera backs out to the 10+05 meter view, we’re now looking at the entire city of Chicago. There’s still a pollution challenge, but at this scale, we need to think about it differently. We would work on city-wide waste and landfill management. We would address how much garbage a city like Chicago generates and how we’ll manage its collection and disposal. It’s a very different problem than how many waste cans go into the park.

At the 10+07 meter view, we’re now looking at all of North America. The pollution challenge will focus almost entirely on climate change issues. And when we pull back to 10+08 meter view, we can now see the entire planet and the objects floating around it. Now we need to contend with the growing problem of space junk.

UX Design Challenges Also Change

No matter which challenge we would pick, the nature of the problem and potential solutions will change depending on the resolution level. This is just as true with design resolutions.

When we’re focused on a single screen, we’re paying attention to whether our users can enter the data efficiently without making mistakes. We want to assure that any information presented is easy to understand and matches what the user needs to achieve their objective.

When we zoom out to the application/site-wide level, we’re ensuring the flow between screens is logical. We want to reduce the number of steps and make it easy to navigate.

And when we are working at the organization-wide level, we’re focused on coherence amongst interactions throughout the entire customer journey. We want to find ways to make the changes from one touchpoint to the next seamless.

Each change in resolution requires a different set of skills. They are all still UX design skills, but because the problems and tools change, the skills necessary to solve those problems and operate those tools will change.

Designing in an Ecosystem

In their film, the Eames showed us 36 resolutions by simply zooming the camera out and then back in. So far, we’ve talked about 3 UX design resolutions. Might there be more?

Out beyond the organization-wide resolution, there seem to be design challenges created when no single organization is in charge. This is different from most service design problems, where a final authority can use their role power to make a decision. For example, a large electric utility company working to improve the customer’s journey has a single CEO who can be the decider on whether a UX investment should be made.

Yet, what happens when we don’t have a single point of authority, such as a CEO, who can make the decision? What if we need to get different organizations to work together, with no single authority in charge?

For lack of a better name, we’ve been calling this the ecosystem-wide resolution. It’s a resolution we’ve only started seeing a few years ago.

The Internet of Things is an ecosystem that’s emerged. We now have smart light bulbs, microwave ovens, and thermostats and each vendor of those things makes its own control application. That means, if a homeowner has three light bulbs, each from different manufacturers, they need to know which app controls which bulb.

How might we design a coherent control system when we don’t have any authority over what other manufacturers make? This is a fundamentally different problem from working under a single point of authority at the organization-wide resolution. We need to develop skills in persuasion that we’ve not needed before.

Designing When There are No Screens

After the Powers Of Ten film zooms out to the galaxy resolution, it quickly zooms back into the picnic scene. The film continues zooming in, showing the person’s skin cells.

Is there a resolution that smaller than screens? We think this is where new work being done in voice and chat might come in.

Voice and chat deal with words, not screens. In some ways, it’s just a new interpretation of the command line interfaces from days of yore. But there’s a new twist, we’re now applying artificial intelligence and machine learning to it.

Again, our challenges for creating great designs at the Voice/Chat resolution are different from designs at the screen resolution or the application/site-wide resolution. The tools need to be changed here too.The old tools from our existing resolutions do not prove to be as useful.

Resolutions Change How We Think About Our Teams

The Eames film showed us there was a connection between what we think of as outer space, our planet, cells, and atomic science. These aren’t discrete sciences, but interrelated disciplines. You can’t work in one without understanding the others.

We didn’t really understand that applications and websites were different from screens until we’d gotten a handle on designing for screens. At that point, we realized we still had hard problems to solve. Yet, the tools and techniques we’d created for screens weren’t helping us with those hard problems. We had to develop new ones.

Now, as new resolutions appear, we can see that we need to develop our skills and techniques to handle them. We can be prepared for the switch.

Having teams ready to handle the new resolutions gives us a competitive jump over those organizations that aren’t thinking that way. We may not know what those new resolutions will require from us, but just knowing they’re there helps us get an advantage. We can use this knowledge to deliver better-designed products and services.

Build Up Your Team’s UX Design Capability.

March 22, 2019

We’ve found what makes great design leaders different from the rest. Great design leaders put substantial effort into inspiring, coaching, and developing the skills of the teams they’re leading. In the process, they build a culture of continuous learning, which in turn, continuously builds up their organization’s UX design capability.

The more UX design capability the organization has, the more likely they’ll deliver well-designed products and services. It’s a win-win situation. Teams become more capable and the organization delivers better user experiences.

Strategies for Building UX Design Capacity

For example, we noticed that many design leaders employ a strategy of constantly monitoring the UX competencies of each of their UX team members. By keeping close tabs on what each team member’s strengths and weaknesses are, design leaders can tailor opportunities for each team member to grow.

Some strategies are simple, like having team members put their work on the wall. They then institute regular critique sessions, which allows team members to review each other’s work, and share their process and influences. When the more seasoned UX designers on the team are constantly sharing their work, the less-skilled team member can reflect on how they’ll improve their own process and techniques.

Engaging in activities like open design studios, helps team members new to design, see a process that generates new ideas and explores alternatives to different design solutions. Because practice and reflection is built into every design studio, it creates is a fantastic opportunity for designers to grow. Plus, they are fun!

Building Skill Growth into Day-to-Day Work

One aspect of our research we found really interesting, is that we don’t see design leaders hosting training workshops or employing the infamous brown-bag lunches as successful strategies. These out-of-context training attempts rarely provide benefits to team members.

Instead, successful design leaders are adept at building skill growing activities directly into everyone’s daily routine. They look for opportunities to add practice and reflection into their team’s work-in-progress.

This creates an environment of experiential learning, which is proven to be faster and more effective than conventional classroom-style training. Team members see opportunities to apply their new skills directly to the work they’re neck deep in. They get a chance to practice new skills and reflect on how they might improve. Everyone gets better.

Where Do Most Folks Learn UX Skills?

March 15, 2019

In our Creating A UX Strategy Playbook workshop, we do an exercise I absolutely love. It’s easy and fun. You can try it with your own team.

I start by asking everyone in the room to write down a list of five to eight things they’ve accomplished at work over the last week on a blank page. Any major accomplishment they’re proud of works. This usually takes a few minutes, as they go through their calendar and try to remember what they’ve done.

Once they have their list, I ask them to write a number from zero to a hundred next to each accomplishment. The number represents how well school prepared them to complete that accomplishment.

If the things they learned in school completely prepared them for the work involved, they give that accomplishment a shiny 100. If school didn’t prepare them for any aspect of that work, they give it a big zero. Or they estimate some number in between.

What Did School Prepare Us For?

After they give a number to every accomplishment, I ask them to stand up. Once everyone is standing, I tell anyone whose highest accomplishment is a 10 or less, to sit back down. I’m always surprised when one-third of the room immediately sits down. For these folks, school didn’t prepare them for anything they’d accomplished that week.

I then say anyone whose highest number is a 20 or less can sit down. Then a 30, 40, and 50. Usually, by this time, two-thirds of the room is now sitting down.

I continue with a 60, 70, and 80. At this point, there’s usually one or two people left standing. Maybe 4. Rarely more.

I’ll ask them what their highest number was and what the accomplishment was. Often, what helped them with their accomplishment was some advanced course they happened to take. Maybe they learned how to create a user research moderation script, a particular statistical method, or a method for designing a set of icons.

Finally, I’ll ask them what the second highest number was on their list. More often than not, it’s zero. Out of all their accomplishments that week, school only helped them with one.

If We Didn’t Learn At School, Where Did We Learn UX Design?

We learn most of the skills and knowledge we need every day at work. Even for those of us who went to a school that taught UX design, most of what we need can’t be taught through formal education.

So much of what we need is specific to the organization we work in, the people we work with, and the products and services we work on. We need to learn who the users are and what they need from our designs. We need to learn how to best deliver that work.

When someone new joins our team, they need to learn what we already know. When we bring in colleagues from other parts of our organization, we need them to come up to speed on how we got here. Everyone needs to know our process and how we perform our specific UX design techniques.

What we think of as ‘textbook skills’ aren’t the most important or critical parts of our work. It’s everything we learn after we finish school that determines what we’re capable of accomplishing.

Is Our Workplace Designed to Help Us Learn on the Job?

Most of what we learn is picked up on the job. How well have we designed our workplace to support learning?

Design is the rendering of intent. If our intention is to have the best skilled and knowledgeable teams, have we done a good job of rendering that intention?

We’re seeing more design leaders take an intentional approach to creating a culture of continuous learning. They hold design critiques, create mentorship opportunities, and make sure design work is visible and “on the wall” so others can see each designer’s underlying process.

UX designers find accomplishing work is easier when everyone they work with has developed their own design expertise. When our developers, product managers, and stakeholders have a better understanding of what makes a good design good (and what makes bad designs bad), they’re more likely to appreciate our design work and can even help make better decisions themselves.

As our teams grow, design leaders need to ensure everyone can contribute effectively. This means everyone will need to grow the necessary expertise to make those contributions.

Where will everyone gain that UX design expertise? On the job. It’s up to us to make sure we’ve designed the best workplace to make that happen.

Building a culture of continuous learning will empower your team to deliver the best products and services possible. Your team will learn new skills and better practices, making your organization more design mature. Create an action plan to boost your team’s design skills and expertise at our Creating a UX Strategy Playbook workshop.

These workshops fill up quickly. We limit the space so Jared Spool can personally spend time with each team that attends. If you’d like to get Jared’s insight on build your team of self-described unicorns, you’ll want to reserve your spot right away.

Driving Product Teams To Become More Design Mature

March 12, 2019

As our organization’s user experience design leaders, our responsibility goes beyond the UX designers, researchers, and content professionals we work with. We’re also responsible for designs our organization’s product and service teams deliver. If we want to see those teams deliver better-designed products and services, we need them to attain the skills, knowledge, and experience to get there.

In an ideal world, we’d assign a couple of UX folks to be full-time members of those product and service teams. These UX folks would work alongside the developers, product managers, and other team members. They’d keep the needs of the users top of mind, ensuring every aspect of the product or service delivers a great experience.

However, in the real world, teams would squander those resources. Most teams we work with aren’t ready to have full-time UX folks assigned to their projects.

That means, as design leaders, our real job is readying those teams to deliver great designs at a more effective level. We must increase the design maturity of those product and service teams.

The Five Stages of UX Design Maturity

Through our research, we’ve identified five common stages that product and service teams go through, as they become more UX design mature:

Stage 1: Dark Ages – The team is entirely focused on meeting the business and technology challenges, without considering the user’s experience at all.

Stage 2: Spot UX Design – An emerging design leader within the team struggles to deliver products and services with improved user experiences.

Stage 3: UX Design As A Service – Executive support to form and grow a centralized UX design team comes to the organization.

Stage 4: Embedded UX Design – Teams bring on their own UX design capability, separate from the centralized UX design team, to deliver enhanced user experiences.

Stage 5: Infused UX Design – Non-design members of the team have developed sufficient UX design expertise to, alongside the team’s UX designers, deliver market-leading user experiences.

We find there’s a tendency for design leaders to want to assign a design maturity to their entire organization. They’ll tell us, “Our company is somewhere between UX Design As A Service and Embedded UX Design.”

It’s not useful to think of maturity this way because each team inside the organization will be at their own maturity stage. For example, in a medium-sized organization, it’s not unusual to have a team or two make it all the way to Embedded UX Design, while many other teams are in the UX Design As A Service stage, and still some other teams at the Dark Ages stage. Some teams are producing great products while others have no idea that user experience is something they need to think about.

By knowing which stage a team is at, a design leader can tailor how the organization’s UX designers provide the best assistance. The designers can meet the team where it’s at, enabling the team to deliver the best designs.

Design During The Dark Ages

When a team is in the Dark Ages stage, they are consumed by shipping something that technically works and meets its business objectives. If they’re thinking of users at all (and often they’re not), they’re thinking: If users want it, they’ll figure it out.

A team at the Dark Ages stage needs a gentle introduction to user experience. The team members need to realize there are people out there who have to use what their team is delivering.

Exposing team members to real users can often be a positive awakening. Seeing how users interact with their design helps them realize their decisions have consequences. The team members may not know what to do to improve the design yet, but just knowing something can (and should) be done is an important step.

Trying to rush is the biggest trap a design leader can encounter with a team at the Dark Ages stage. If a design leader comes rushing in playing the UX Police with standards to follow and procedures to adhere to, they’ll alienate the team who will shut them down.

It’s important for the design leader to realize the team will transition on their own schedule. The best thing to do is to help those team members realize they’re making design decisions.

Those design decisions have consequences. By making smarter design decisions, they can get improved outcomes. That awareness is what helps a team in the Dark Ages progress to the next stage.

Arriving At Spot UX Design

Teams arriving at this second stage try, for the first time, to deliver a product with a better user experience than what they’ve delivered in the past. This is the first time the team has shown an interest in their users.

Smart design leaders can take advantage of their team’s desire to improve their user experience. Design leaders can show how iteration with user feedback can improve a design over time.

Because the team has never previously paid attention to any design issues, there are usually glaring issues that are easy to fix. Teams find basic UX design principles very helpful at this stage.

One commonly effective technique at this stage is to restate the team’s business goals in terms of user experience goals. For example, if the team has chosen an objective to increase new account sign-ups, the design leader can show problems users have during the sign-up process. Connecting how an improved UX can help the team attain their business goal shows the team how UX is a tool they should add to their business toolbox.

Like dealing with teams in the Dark Ages, it’s tempting to try to accelerate the team through the Spot UX Design stage. Design leaders need to balance the team progressing at their own rate against introducing basic UX design concepts.

For organizations that haven’t formed a centralized UX design team yet, the next step is to rally executive support to make an investment in UX design. If a centralized UX design team already exists, the design leader’s challenge is to find the resources to move the team beyond Spot UX Design.

Creating An Internal Design Agency

The UX Design As A Service stage begins when an executive invests in creating a centralized, internal design team. That team then supplies UX design resources to the product and service teams.

UX Design As A Service teams always find themselves resource constrained. There are more product and service teams that need help than the centralized team can service. The UX design leadership must decide which teams will get the most assistance.

As new product and service teams emerge from the Spot UX Design stage, further executive support will be required to grow the centralized team. The more design leadership demonstrates how the business wins with better design, the more support they’ll garner from the executive team. That support will generate more resources to give to new teams.

The biggest struggle at this stage for many design leaders is shifting from a reactive approach to design to a proactive approach. The leaders train the product teams to bring them into their design process earlier. Proactive design teams get input on how everyone understands the problems, instead of just executing a pre-ordained (and often substandard) solutions.

Ironically, a major milestone during the UX Design As A Service stage is when a product or service team becomes frustrated with the centralized design team. When that team feels they aren’t getting enough design resources, they’ll start asking for their own designers. At this point, this team is ready to move to the next stage.

Embedded Designers: A 24/7 Design Resource

In the Embedded UX Design stage, the product or service team hires their own UX professionals. These folks report directly into the team’s own management. They are no longer available for work on other products or services.

Embedded UX professionals deliver the team long term continuity. Whereas before, when using centralized design resources, they constantly had to train every new designer assigned to their product. Now, an embedded designer eliminates that frequent, disruptive training.

The embedded designer now can design across multiple releases and versions. They can research and develop a deep domain knowledge about the products and the challenges users face.

The trickiest part of this stage is keeping any embedded UX professionals in the loop with the centralized team. (The centralized team won’t go away, as they have other, less mature teams to continue supporting.) The embedded folks need to hear what’s happening elsewhere in the organization, to create coherence between all of the organization’s products and services.

The embedded UX professionals will work closely with the developers and product managers on the product team. This close working relationship will expose their UX skills, knowledge, and experience to the rest of the team. Over time, that exposure will lead to final maturity stage.

Infused UX: When Non-Designers Design

What triggers this final stage is when the non-designers on the team start making good quality UX design decisions. Those decisions result in outcomes that are now much better than before.

UX design is a learned skill and developers and product managers can learn it. By spending close time with their team’s embedded UX professionals, they start to pick up the basics. Over time, they become design fluent themselves.

This provides real benefits for the organization. The designers no longer need to approve or oversee every design decision. Designers no longer need to specify ever design detail in exacting precision. Good design happens no matter who is making the decisions.

It takes a long time to get to this point, but the benefits are clear. The products and services the team now produces are head-and-shoulders better than anything the team has produced before.

Organizations Benefit When Teams Mature

The evidence in the marketplace is clear. Organizations become more competitive when they deliver better-designed products and services.

To improve the design quality of those products and services, individual teams need to increase their own design maturity. Design leaders play an important role, but that role changes as the teams transition from one stage to the next.

Design leaders need to understand where a given team currently is in their journey. Using that information, they can tailor how they support the team.

It takes a long time to transition teams to the next level of maturity. Yet, when they do, the entire organization benefits.

UX Strategy: Amplify Your UX and CX Insights

March 8, 2019

Experience is at the core of an organization’s brand. It’s the experience that dictates how our customers and users think about us as an organization. Deliver a great experience and customers sing our praises from the rooftops. Deliver a poor experience and they’ll tell everyone they know how badly we treated them.

Our organization’s products and service teams depend on both our UX and CX efforts to ensure we deliver a great experience. Yet, without a thoughtful, well-tuned strategy to make it happen, the UX and CX folks might as well be yelling into the void.

Amplify Your UX and CX Insights With A Well-Honed Strategy

The best way to craft a strategy that will amplify your UX and CX insights is to benefit from the successes of others. Over the years, we’ve compiled more than 130 proven UX strategies and built them into a 2-day workshop.

When you and your UX/CX leadership attend our Creating a UX Strategy Playbook workshop, you’ll review every strategy. You’ll select the strategies that have the most potential to move the needles of your key initiatives. You’ll identify the most beneficial strategies for your team to put into action right away.

Strategies for Promoting Every Aspect of Experience Design

Over the two days, we’ll focus on strategies to:

  • Communicate an experience vision that builds alignment and support on how great our products and services could be.
  • Win over key executives and stakeholders and gain their backing to execute important strategies.
  • Inform your product roadmap with strategic research that gets to the core of the problems customers need solving.
  • Install metrics that will demonstrate where teams are making improvements and isolate where there’s still work to be done.
  • Identify where teams need to improve their UX design skills to tackle the more complicated challenges.
  • Build up a solid design leadership capability, to carry the vision forward and give product and service teams the support they need.

This is the Strategy Workshop Your Organization Needs

As you leave the workshop, you’ll know exactly what needs to happen next. You’ll have a solid action plan for improving the products and services your organization delivers. And you’ll have a leadership team that’s ready to make it happen.

It took us more than a decade to design this workshop. We’ve condensed incredible insight into 2 days of roll-up-your-sleeves strategy building.

It’s hard work, yet you’ll leave completely energized. This is the workshop your organization needs. The feeling of empowerment and confidence to bring your organization to the next level is something you won’t get anywhere else.

Register Today.

These workshops fill up quickly. We limit the space so that Jared Spool can personally spend time with each team that attends. If you’d like to have Jared apply his vast experience on your organization’s strategy challenges, you’ll want to reserve your spot right away.

Sometimes A User is Just a User

March 1, 2019

Every few lunar cycles, we come across another post decrying how UX professionals should never use the term user to describe the people we’re designing for. The authors assert the term is too generic, dehumanizing, and possibly offensive. ”Users are people who are addicted to drugs!” they exclaim.

In one such post we recently encountered, the author said they’ve switched to always using customer instead of user. They want to ensure everyone on the team knows that the people who use their designs have paid for the design.

In our practice, we have a basic principle: Use the term that helps our colleagues best relate to the people whose lives we want to improve. That could be a customer. It could be a doctor. And, sometimes, the best term is just a user.

Not All Users are Customers

Customer is a great term when a person, in fact, makes a purchase decision. But that’s not always the case.

Take, for example, a roadside assistance application that comes as a benefit of an automobile insurance policy. The users of that application could be the customers of the insurance company. At some point, the purchaser of the policy may indeed be in need of roadside assistance.

However, it could also be one of the purchaser’s family members. Often multiple household members share a vehicle. Not all of them are the customer. Only the purchaser is.

This is an instance where user is a better term than customer, because not all users make purchasing decisions. The distinction between a policy purchaser and a non-purchaser household member doesn’t factor into the design choices the design team needs to make. The few times customer would matter is in an instance when the application demands a policy number, which only the policy purchaser may have access to.

Not all Customers are Users

We researched people using roadside assistance. In that research, we found an interesting use case: A parent who purchases roadside assistance coverage for their college-attending child. The parent wants the peace of mind that their child will be well cared for.

In this common use case, the purchaser isn’t covered by the policy, because they live in a different state from the student. Only the student can use the application.

Customer is a meaningful term here, but it only applies to the parent, who isn’t using the application. In this case, user is still the best term for the person who uses the app to take advantage of the roadside assistance benefit.

When There are Better Terms than User

For the roadside assistance application, we could use the term driver, assuming we believe only drivers use the application. If there’s a chance that the passenger of the vehicle might be the person invoking the service, then it won’t apply.

Again, our goal is to help everyone on the team relate to the people we’re designing for. We want to choose terms that give us the best clarity.

In a recent project involving a medical ultrasound diagnostic device, we found ourselves rarely using users because it didn’t help us make our users relatable. Instead, we chose to get specific about who was using the device.

Most of the time, a trained ultrasound technician operates the diagnostic device. However, it’s designed for a nurse or a doctor to also operate it. In some cases, the patient or their caregiver would want to interpret the images on the display. (For example, when a couple is looking at their unborn child.)

For the device’s design team, user isn’t a useful term because each of these people will use the device in a different fashion. The design team needs details about the role each person plays in the diagnostic session. (This is an instance where personas can be useful.)

Shared Understanding is the Goal

User isn’t always the right term to describe our users. Yet, sometimes it is.

Ironically, we need to think of our design team as our users. What will help them understand who they’re creating the product or service for? If there’s a better word than user, then we’ll certainly use it.

But, we don’t want to make things more complicated than they need to be. Getting our teams on the same page is hard enough. We shouldn’t let our language get in our way.

UX and CX: Same Language; Different Dialects

February 26, 2019

The Difference is in Their Origin Stories

Some people will tell you that the difference between the customer experience and the user experience is whether we’re talking pre-sales or post-sales. These people believe the CX is what happens before the product or service is purchased. The UX is everything that happens after the purchase.

Other people will tell you that UX is a subset of CX. These people believe the UX only includes when users are interacting with a digital product or service. The CX is the overarching experience, including any non-digital activities users engage in.

And still other people will tell you that CX is a subset of UX. These people believe CX only embodies the experience paying customers have, while UX includes everyone, whether they made the purchase decision or not.

If senior leadership believes one of these differences, they’ll use that belief structure to dispense responsibilities throughout the organization’s CX and UX teams. However, none of these beliefs seem to determine what makes successful CX and UX teams.

We’ve looked closely at high-performance CX and UX teams in dozens of organizations. What we learned was they uniformly work towards an identical goal. They all want the organization to deliver the best experience for anyone who interacts with their organization’s products or services.

The difference between the CX and UX team is not their mission, but their origin. Because of that difference, they achieve the goal quite differently.

The Origin Story of CX

The modern customer experience team has its roots in the 1960s Mad Men era. In those early days of advertising, everyone thought a great tagline and jingle was all that they needed to persuade customers to purchase.

Then pioneering marketers discovered that not all customers are identical. People who live by themselves do not purchase the same products as people with children. People who live in cities do not buy the same products as people who live in rural areas. The science of market segmentation was born.

As marketers refined their knowledge, they moved beyond simple demographics to other factors, such as attitudinal psychographics. It wasn’t just about where a customer lived, but their attitudes towards things in their life.

Marketers started collecting more data. Market research transformed into marketing analytics.

In the early 2000s, voice of the customer research became popular. This research worked to identify how to satisfy the needs of customers.

The birth of social media showed marketers that their most effective marketing tool was a great experience. When someone had a great experience, they told all their friends. Word-of-mouth advertising was more powerful than any other medium.

CX was then popularized by industry analysts, most notably at the firm Forrester Research. Executives and senior marketing leaders went to Forrester’s conferences and heard stories of companies benefiting from great product and service experiences. To get these benefits, they created teams to spearhead their organization’s own CX efforts.

The Origin Story of UX

The modern user experience team has its roots in 1960s human factors and ergonomics. In the early days of complex technology, like airplane cockpits and nuclear power plant control systems, we realized that human error was costly. If we could design systems that eliminated errors, we could save lives.

When the personal computer appeared, products needed to become “user friendly.” Usability became a focus for products.

In 1993, Don Norman coined the term user experience. As the web made information available, UX teams took on the job of providing great information architecture, interactions, and visuals in their designs. The focus on apps broadened the scope of UX teams.

The UX team was there to collaborate with product developers and deliver better-designed experiences.. This ensured their products and services provided the most value.

Blurring the Boundary at the Moment of Purchase

From the beginning, CX’s mission was to market and sell products or services. CX teams know they can only succeed if the organization delivers the best experiences possible for their users. And while UX’s origins are focused on delivering those great experience, they can only do that if people buy the product.

There used to be a boundary at the moment of purchase separating CX and UX. What evolved into CX was responsible for everything that happened up until that moment. What evolved into UX focused on everything after that moment.

But that distinction is no longer helpful. That boundary is now blurred.

CX teams are concerned with the design of their products and the experience it delivers. They can’t succeed if they focus only on what happens before the sale.

UX teams are concerned with ensuring their products demo well and have the right features to sell. They can’t succeed if they focus only on what happens after the sale.

Same Language, Different Dialects

Because of the vastly different origins of CX and UX teams, they approach their common goal from very different perspectives with very different skills and tools. It’s as if they’re speaking the same language, but with very different dialects, almost to the point of not understanding what the other is trying to say.

CX has its roots in marketing analytics. CX teams are very comfortable with large sample sizes from surveys and analytical data. They love quantitative models. They are at home with what customers say they like and need.

Meanwhile, UX has its roots in behavioral science, primarily cognitive science and ethnography. UX teams work well with small sample sizes. They love qualitative methods. They focus on how people behave with the product.

CX and UX teams are trying to accomplish the same thing, using different sets of skills. For example, they both try to encapsulate user differences with personas.

But CX personas are very different from UX personas. The former is more about segmentation differences, while the latter is more about behavioral differences. This creates confusion when teams aren’t careful in understanding their origins.

Shifting from Roles to Skills

Some organizations let an unhealthy turf battle form between the CX and UX teams. Effective senior leadership prevents this turf battle by integrating skill sets.

Both CX and UX are critical to the success of an organization that desires to become a market leader. Product and service teams need insights that both the CX and UX perspectives provide.

In the most effective teams, the senior leadership moves the culture from roles to skills. Instead of trying to assign different responsibilities to separated CX and UX teams, they focus on creating a single team with both CX and UX skills and knowledge.

Creating an integrated team, with both the skills of large-sample quantitative analytical modeling and small-sample qualitative ethnographic studies, provides a powerful combination. Integrated teams have a wider toolset to apply to complex challenges.

Integrated teams provide a deeper understanding of what users truly need from the organization, who, in turn, deliver better-designed products and services. After all, that’s the ultimate goal of both CX and UX efforts.

If you want your UX team to work more closely with your organization’s CX efforts, you’ll need a plan. In our 2-day Creating a UX Strategy Playbook workshop, we’ll work together to craft your plan and give you the strategy you need to deliver better-designed products and services.

You won’t find a better way to identify the UX strategy your team needs. Choose the right approach from more than 130 strategies that have worked in organizations just like yours. Register today.

The Experience Vision: A Self-Fulfilling UX Strategy

February 5, 2019

The engineer reviewed his options one last time. While he was making an important decision, it was like many other important design decisions. If he made the right one, his work would be lost to obscurity. Yet, if he screwed the design or engineering up, it would be all anybody would talk about.

It was 1990 and the team was a year away from shipping the brand new Apple Powerbook 100. This was Apple Computer’s first foray into what we’d now call a notebook computer. In fact, it was one of the first notebook computers ever made.

The engineer was leading the design and engineering for the power supply component. Creating the best power supply component was the center of his world, even though it’s something nobody else is suppose to pay attention to.

For the last year, he’d been working on several alternatives. Now it was time to decide which alternative he’d use.

In any other job, he’d look at the best practices of his competitors. But, there were no competitors.

In the past, he had a standard set of questions to help him choose the best alternative. Which is cheapest to manufacture? Which would be fastest to market? Which would be most reliable?

Which alternative gets us closer to the Knowledge Navigator?

Apple’s Experience Vision Project

In 1987, Hugh Dubberly’s design team at Apple Computer embarked on an ambitious project. Their job was to imagine what Apple’s products might look like 23 years in the future.

To show what they thought computing could be like in 2010, they crafted a series of stories. All of the stories were about everyday people doing great work with the assistance of cool Apple technology that hadn’t been invented yet, but could be.

For example, one story described a television director scouting out locations. Wearing special glasses, the director would take pictures by positioning his thumbs and forefingers into the shape of a picture frame.

That gesture would signal the glasses to record spoken notes, the location, and position of the camera. The director could choose the best shots from the images and notes.

The 1987 Knowledge Navigator

Dubberly’s team made a few of the stories into short videos. Their most popular video proved to be The Knowledge Navigator.

Apple Computer’s imagined Knowledge Navigator from 1987

In the Knowledge Navigator video, a university professor reviews his upcoming class lecture. He updates his lecture’s underlying research with new data, collected from universities all over the world. (Apple managed to predict the Internet six years before Tim Berners Lee invented it.)

Eventually, he starts a video chat with a colleague at a university on the other side of the country. (Skype also hadn’t been invented yet in 1987.) A flat tablet-like computer assists all of this with some sort of talking AI avatar, high-speed internet, and built-in video—none of which was available in 1987.

Tablets aren’t remarkable today, but back then, they were non-existent. 1987 saw the debut of the IBM PS/2 and the Apple Computer Macintosh II. These big box computers with slow processors took five minutes to boot up.

In the Knowledge Navigator video, the professor opens his device and the AI character immediately starts reviewing the professor’s calendar—no delay. In 1987, people only used keyboards and mice. For many people this was the first time they saw a user do sophisticated actions using only voice and touch.

Apple’s Self-Fulfilling Prophecy

It was a lucky coincidence that the first iPad shipped in 2010, the year Dubberly’s team had depicted their Knowledge Navigator story. However, It wasn’t a coincidence the iPad shipped with most of the Knowledge Navigator’s features. The Knowledge Navigator had become a self-fulfilling prophecy for Apple.

The story caught the imagination of the company. Apple executives proudly showed the video to the shareholders. Everyone in the company was excited to figure out how to build it.

While it would take 23 years to come to fruition as the iPad, the Knowledge Navigator was guiding many of the projects in between. Looking back at the Powerbook, the Newton, the MacBooks, the iPhone, and the MacBook Air, it was clear that Apple was using the Knowledge Navigator to set their direction.

Experience Vision: A Flag To March Towards

Dubberly’s team had created experience visions. Each story described a future vision of the user experiences Apple’s customers could have.

You can think of an experience vision as a giant flag on a tall post in the sand, far away on the horizon. The flag is too far way to walk to anytime soon. It will take years. (In the case of the Knowledge Navigator, it was 23 years.)

Yet, because the flag is visible from where we currently are, we can set a directive: March towards the flag. Everyone in our organization can have the same directive. We’re all marching towards the same point of convergence, even if we’re starting someplace different.

Our marching steps are often baby-sized steps. The Powerbook 100 power supply engineer wasn’t trying to invent the power supply capability of the iPad. He was taking baby steps to make a smaller power supply than what had been in previous Macintosh computers.

It’s All About The Experience

What made the Knowledge Navigator experience vision so effective was how little attention Dubberly’s team paid to the product. Instead, all the attention was paid to the professor’s experience with the product. What was his day like? How could he seamlessly achieve his objective?

(Having now watched the video hundreds of times, I can tell you the professor apparently works in 5-minute chunks and gets his lectures done at the very last minute. Oh, the pleasures of tenure. He also ignores his mother.)

The vision primarily attended to the professor’s experience. It communicated what the outcome of the design needed to be. It didn’t specify how the design would achieve that outcome. If you watch closely, you can see that there’s very little detail on the UI or the mechanics of the professor’s work.

An experience vision represents an experience we can aspire to. We need to contrast that experience to our users’ current experience. In the case of the Knowledge Navigator, they relied on the fact that everyone had current, frustrating 1987 technology on their desk.

A viewer of the video would immediately see the difference in the experience. They could say: Yes, that’s exactly what I want!

The Power Of A Great Story

What makes an experience vision work is a great story. A great story isn’t just heard, it’s also told. It’s passed on.

For an experience vision to work, it needs to be something discussed in meetings. Everyone needs to ask the question What will get us to the vision?

That implies everyone needs to know the story. It has to be catchy and contagious. It has to stand the test of time.

It’s hard to come up with a great story. There’s no formula for success. (If there was, Hollywood would never put out a crappy movie.)

Dubberly’s team created several stories, but only the Knowledge Navigator caught everyone’s imagination. It was the right story at the right time.

What makes a story great is when everyone in the organization can see their own work inside the vision. Even though the Knowledge Navigator video never showed the power supply, the Powerbook engineer could see his own work there. If we can see our own work in the vision, we can imagine the baby steps we might need to get there.

Visions Aren’t Always Science Fiction

Dubberly’s team based their stories on the current research in human-computer interaction. They’d been paying attention to the innovations coming out of research labs like MIT’s Media Lab. They explored what it would be like if these futuristic inventions became commonly available.

However, most experience visions don’t have to tap into future science. We can look to currently available technology that hasn’t made it into our users’ experiences.

A few years back, an insurance company we worked with came up with this comparatively boring vision story:

During a storm, a customer has a tree fall on their car garage, damaging both the house and the car inside. The customer immediately takes pictures of the damage to their car and the building. They upload it to the claim center, which immediately opens a claim.

Within an hour, both an emergency construction crew and a rental car are dispatched to the customer’s home, preventing further damage from the ongoing storm and ensuring the family still has transportation. Within 24 hours, a contractor has been chosen to repair the home damage permanently and their vehicle is in the body shop. The family has received a debit card to automatically cover any out-of-pocket expenses incurred during the restoration process.

This story may not seem as far fetched as the Knowledge Navigator seemed in 1987. Yet, it’s was a good 5-year vision for the insurance company.

They could start taking baby steps right away, starting with using customer-supplied pictures to open claims and implementing an emergency dispatch capability. It would be years before they implemented everything in the story, yet everyone knows what to do.

Creating An Experience Vision From “How Might We…?”

The easiest way to create an effective experience vision story is to start with the current experience. What makes today’s experience with our product or service frustrating for our users?

Team members immersed in the current experience will do the best. This means the starting point for creating an experience vision is immersive user research. The key is to spend time studying the frustrations we put our users through.

We can ask, “What’s the best experience we could imagine providing our users?” We look closely at the frustrations and imagine an experience where those frustrations don’t occur.

Next up is to determine the timeframe of the horizon. Apple used a 23-year horizon, but that’s a very long timeframe for a vision.

Most of our experience visions come closer to a five-year horizon. Five years is far enough away that we could see eliminating whatever legacy issues are currently holding us back.

For the insurance company, they could imagine upgrading their old mainframe technology to support customer-supplied damage photos, but they believed it would probably take the full five years. (It only took two, which surprised everyone involved.)

The story now comes together. In 5 years (or whatever horizon we pick), what is the best experience we can imagine delivering? How will people’s lives be better because we’ve removed all the frustration?

The Experience Vision At The Center Of A UX Strategy

The best experience visions are contagious. They take on a life of their own.

You’ll know your experience vision has taken off when other people start explaining it to you, to make sure you’ve heard it.

It’ll really take off when you hear a senior executive, at some organization-wide meeting, use your story to explain where the organization is heading. They’ll be telling the story (probably getting a few details wrong) to everyone, saying “This is where we need to go.”

What happens next is magical. The organization starts to focus less on what the competition is doing. Decision makers ask What baby steps will it take to get closer to our vision?

Your user experience strategy becomes more real when there’s an experience vision to guide it. It shifts from “we need to make great designs” to “we need to make this be our users’ experience.”

The experience vision becomes a visible example of what great design can be in the organization. And that, in turn, pushes the organization to deliver better designed products and services.

Organizations see a dramatic improvement in user experience adoption through a great experience vision. Teams that create and socialize a great experience vision gives everyone a hook to hang important decisions on. In our 2-day Creating a UX Strategy Playbook workshop, you’ll choose the strategies that will work best to get total adoption of your experience vision.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Germany. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

How We Craft A Great Experience Vision Story

February 5, 2019

Ernest Hemingway once wrote, “Writing a story is easy. Just take out a sheet of paper and stare at it until your forehead starts to bleed.”

Writing a story for an experience vision can be difficult for our teams. We’re trying to predict what using our product or service could be like in the future. It’s hard enough to write about the present. Describing the future can be a daunting task.

Many teams fall into a trap. They believe they must predict what the future world of technology will be like. That quickly spirals into bad science fiction, trying to predict AI, alternative interaction methods, and other tropes best left to Sci-Fi futurists.

An Experience Vision isn’t a Science Fiction Story

For most experience vision stories, we don’t need to invent some new, futuristic technology. We don’t need to spend time exploring and wowing people with something they’ve never seen before. If we tell the right story, everyone will focus on the experience of the user.

Our vision story shouldn’t be set too far in the future. Five years out is good enough. Think of the technology you had five years ago. How truly different was it from what you have now?

Usually not that much. A few new, useful features, but mostly the same.

Remember, Apple’s Siri made her debut seven years ago. The Apple watch is more than three years old. And they weren’t the first of their kind.

Most “New technologies” like voice and wearables have been around for a while. Our five-year future vision should be set in a technological world that seems much like today’s.

We Need To Put The Experience Vision First

At the center of our great experience vision is the users’ experience. When we’re imagining a future story, we’re focused on one question: What’s the best experience for our users we can imagine?

All designers share a superpower. We all have the uncanny ability to solve well-defined problems.

I’ve worked with hundreds of teams. I’ve never met one that when presented with a solid understanding of how users struggle with our design, couldn’t come up with a wall full of great solutions.

Some of those solutions will be good. A few might even be great. Even fewer might be implementable. And, in all of that, there might be one that’s even practical and customers would pay for.

Start With The Experience of Today’s Users

When we understand the problems that frustrate our users, we have no trouble arriving at viable solutions. To craft a compelling, great story about the user’s future experience, we start with the user’s current experience.

We need to spend time with our users, listening and watching how they move through their day in the current world. When we do this, we’ll see what frustrates them. We’ll see where they spend time doing things that our designs could handle automatically. We’ll see how we can make the overall experience more delightful.

It can’t just be the UX researchers who spend time with our users. Everyone who we want to help compose the experience vision (and to subsequently sell it to the rest of the organization) needs to have this exposure.

When all the contributors have the same understanding about our users’ current experiences, they’ll join us in creating possible solutions. They can help us answer the critical question: What’s the best experience for our users we can imagine?

They’ll be sold on the solution because they’ll have had a say in its creation. They’ll understand the experience vision’s importance and how it’ll change the way we do business in the future.

Those team members will be our best advocates. With their help, our organization will deliver better-designed products and services. That’s the power of a great experience vision.

Is User Research Driving Your Product Strategy?

January 25, 2019

I spend time with each team to help them choose the strategies right for their organization’s needs.

Is your team’s user research driving your organization’s product strategy? Here’s how you’ll tell:

Does your organization’s senior leadership understand the value of great design?

Are you producing enough research for every product and service on your roadmap?

Is your user research influencing critical product decisions?

Are new product features actually what your customers need and want?

Is it easy to gain access to users for in-depth research?

Are your team’s research insights directly influencing the strategic direction of the organization?

Are critical decision makers helping to drive your team’s research agenda?

Without the right user research strategy, the benefits of your team’s user research will only go so far. Your team can’t do their job if they don’t have access to the right users. Their research insights won’t make your product better if decision makers aren’t considering their research.

Breaking through to make user research more effective is hard. It often requires tailoring a new approach to the culture and structure of the organization.

We’ll never have enough resources to do everything we want. We need to know how to use the resources we have most effectively.

Breaking Through The Strategy Barrier

We’ve done the hard work, so you don’t have to. We studied how design leaders all over the world have raised the effectiveness and influence of their team’s user research. From this, we cataloged dozens of strategies that teams can put into action right away.

We’ve made those strategies the core of our 2-day intensive Creating a UX Strategy Playbook workshop. You and your team will review each strategy to identify which actions will be the most effective for meeting your team’s goals.

You’ll return to your office with a solid plan of action. You’ll know exactly what you need to do to increase senior leadership’s understanding of your team’s value. You’ll put your team’s customer-focused research insights into the center of critical strategic product decisions. You’ll have no trouble getting access to the customers and users that will influence the future direction of the organization.

Building A Strategic Plan You Can Make Happen

With constrained resources, the strategies you choose are critical. You need to ensure every step you take is going in the right direction.

That’s why I work with every team that attends the workshop directly. I learn what their biggest challenges are and then, together, we come up with a plan. A plan that will increase the influence and effectiveness of user research throughout their organization.

The new strategies you come away with will inspire you. In turn, you’ll inspire the teams you work with. They’ll start producing better designed products and services. Your organization will be the envy of the industry.

“This was a really valuable, transformative workshop. I highly recommend it.” — Terence Nelan from CIT

Join me in Chattanooga, TN or Hamburg, Germany for an upcoming workshop.It will transform how you think about user research strategy. And it will change the way you deliver products and services forever.

In Chattanooga, we still have room for our February 6-7 workshop. The April 10-11 workshop has plenty of room, but it will fill up soon. We just opened registrations for our Hamburg, Germany workshop on June 25-26. Registrations have already started arriving, so don’t wait too long.

Markets are led by companies who know their customers and users better than everybody else. Create a user research strategy that will make your organization the leader in your industry.

I can’t wait to work with you on your user research strategy,

Jared M. Spool
Workshop Leader
Creating A UX Strategy Playbook workshop

We limit every workshop to 24 attendees. Don’t wait to register because they fill up quickly. Register now.

Progress Frameworks As A Competitive Advantage

January 23, 2019

A few years after the birth of the web, we embarked on a research project to study the questions people asked in online medical forums. We studied thousands of questions people had posted in forums related to chronic diseases.

As our research progressed, we noticed a pattern starting to emerge. People’s questions changed based on where they were in their journey with a particular disease.

For example, if the person was recently diagnosed, they had all sorts of questions about what the disease was and its implications on their lives. Whereas, if they were well within their treatment process, many of their questions had more to do with those treatments.

In our analysis, we found a dozen different chronic illness stages. In each stage, a person’s questions changed. They would need different information to manage their illness and live a quality life.

Progress frameworks help us structure our research

Now it seems very obvious to us that people’s needs changed as their life with the illness progressed. Yet, at the time it wasn’t obvious at all. Websites providing medical information were constructed like encyclopedias that never took an individual user’s needs into account.

Through our research, we stumbled into creating a framework around a patient’s progress with chronic illness. We could use the patient's progress framework to make sure we saw the entire picture.

What we found was that many information providers only focused on a couple of the stages. People newly diagnosed and those living with the illness were missing answers to their important questions. Using the framework, we could ensure we knew what questions to address and how to structure the information.

There are many progress frameworks to help us

Over the years, we’ve learned about other frameworks. Bob Moesta has popularized a great framework that shows how shoppers progress through a purchase.

Bob Moesta's Product Framework
Bob Moesta’s Purchase Progress Framework

It starts before the shopper even realizes they need to buy a new product and progresses up until the new product owner is getting benefits from their purchase. At each stage of shopping progress, the shopper needs different information about how the product will benefit them. Teams can use this framework to ensure they answer all the shopper’s questions, before the customer even asks.

Anthony Ulwick also has a framework he calls the Job Map. He uses this framework to map out how a customer meets an unmet need.

Anthony Ulwick's framework called the Job Map
Anthony Ulwick’s Job Map Progress Framework

It’s brilliant because, like Moesta’s framework, it starts before the customer has the unmet need. Then, in eight steps, it walks through the stages until the customer no longer has that need. By studying their users at each stage, teams can learn how the customer’s specific needs transition.

Amy Jo Kim has a 4-stage Mastery Path she uses to describe how users learn new products. It extends beyond the oversimplified notion of novices and experts, and is based on her extensive research into how people learn to play and become immersed in online games.

Amy Jo's Mastery Path
Amy Jo Kim’s Mastery Path Progress Framework

Like the other frameworks, Kim’s shows that the user’s needs change as they progress through each stage. The needs they have when they’re first onboarding with the product is different than when they’re later mastering advanced capabilities. Teams can use her framework to ensure they’re covering the full lifecycle in their research.

User research becomes our competitive advantage

If we want to produce competitive, innovative solutions, we need to uncover needs that none of our competitors are addressing. In most cases, we don’t need to invent something brand new the world has never seen.

Instead, let’s only look in places where our competitors aren’t looking. We use a progress framework to tell us where to start looking.

In most industries, competitors just copy other competitors. User research can become our competitive advantage, especially when we’re using a progress framework to focus where nobody else has explored.

When we understand our users needs better than everyone else, we can be the market leader everyone else chooses to follow. This is how we’ll deliver better quality products and services than our competition.

Jobs To Be Done: An Occasionally Useful UX Gimmick

January 17, 2019

It was puzzling. Jay (not the study participant’s real name) was sitting in front of a desktop computer with an open browser. Yet, it was his phone that he grabbed.

On his phone, Jay immediately opened his bank’s mobile app. Once he logged in, he glanced at his account balances, then proceeded to move a chunk of money from his checking account into his home equity account.

I was puzzled why he didn’t use the bank’s website instead. “The phone app is so much easier,” Jay responded. “I do this transfer every month and I find I can get it done faster using the phone.”

This fascinated me. Jay had used the bank’s website many times. He showed me how he paid bills using it. But when it came to transferring money, it was easier for him to use the mobile app.

Hiring and Firing

Jay needed to make a money transfer. To resolve that need, he chose the mobile app over the bank’s website.

We can frame Jay’s choice as two actions: For the job of transferring the money, Jay fired his bank’s website and he hired his phone’s mobile app.

The choice users make to fire one thing and hire something different is important. Why are they making that choice? If they choose to fire our design and hire someone else’s design, are they trying to tell us that our design is deficient in some way?

Why did they make this choice? The question points to a problem of impedance. In Jay’s case, the website provided some impedance to the job of transferring money. The mobile app resolved that impedance.

If the bank’s design team understood the impedance and what caused it, they’d have several options. They could market the effectiveness of the mobile’s apps transfer capability, to get other customers to take advantage of it. Or they could update the website’s design to remove whatever was slowing Jay down, to make it a more desirable solution in the future.

That’s the power of Jobs To Be Done. JTBD (as the kids call it) is a new approach to talking about choice and impedance. The Job is the progress a user is trying to make. (In this case, Jay is trying to make progress paying down his home equity loan.) The user hires and fires products or services to make that progress efficiently.

Where Jobs To Be Done Came From

Jobs To Be Done was popularized in Clayton Christensen’s books on innovation and disruption, primarily his 2016 Competing Against Luck. (It’s most telling by the subtitle of the book: The Story of Innovation and Customer Choice.) Christensen’s is the best resource we’ve found at describing how JTBD leads to innovative products. It’s what you’d expect from Harvard Business School’s foremost authority on how companies can deliver innovative products.

Yet, Christensen’s book doesn’t describe how to get there. This has spawned a small army of consultants to fill in the gap. Each of them has written their own books, including Chris Spiek and Bob Moesta’s Jobs-to-be-Done The Handbook, Alan Klement’s When Coffee & Kale Compete, and Anthony W. Ulwick’s Jobs To Be Done Theory To Practice.

In each case, the various authors talk about uncovering how the users make choices. Ulwick tends to be more focused on what people do with the product or service. The others tend to be more focused on progress that people are trying to make.

(This difference has created a bifurcation in the JTBD community, which can get contentious at times. That contention makes it hard to understand what JTBD offers at times. Several UX professionals have told me they turned away from JTBD, because they were turned off by the turf wars and excessive salesmanship of the consulting practices.)

The Framing of Jobs To Be Done

The believers of JTBD tell us that when teams don’t know what their users hire a job for, they’re likely to make poor design and marketing decisions. In JTBD, marketing and design find common ground to ensure their product or service addresses the customer’s (or non-customer users’) unmet needs. This could be useful.

Not too long ago, in a study we did of insurance agents, we noticed several of them turned to spreadsheets for creating price quotes for their customers. They told us they’d chosen to build and use their own spreadsheets, instead of tools their insurance company’s IT department had built, because the IT’s tools were overly complicated.

We could frame the agents choice as firing the IT tools and hiring their spreadsheet. The customers’ Job to be Done is getting the customer an insurance quote quickly.

In other studies we’ve conducted over the years, we observed customers trying to resolve issues. Many of those customers chose to call a toll-free support center number and talk to a human customer service representative instead of using the available online knowledge center. Those customers told us they preferred the human interaction because it gave them confidence in the issue’s resolution.

We could frame these customers’ choice as hiring the call center representative and firing the knowledge base. The customers’ Job to be Done is resolving their issue with confidence. A Job to be Done is another way to frame an unmet need. It puts it in the simple context of a service.

Jobs To Be Done Forces A User-Focused Approach

Christensen’s basic argument is you’ll create something innovative by focusing on the job the customer needs done, especially if it isn’t being done by a current product on the market. You’ll solve a customer’s unmet needs in a way that nobody else has. Christensen is using JTBD to promote a user-focused approach to innovation.

What’s great is we now have a Harvard Business School authority promoting talking to customers. Christensen spends an entire chapter scolding business leaders for being too inward focus. He tells them to listen primarily to what he calls passive data, instead of the normal data that the organization is swimming in.

Passive data is hard-to-get qualitative data that will go beyond the market data. Christensen doesn’t say it, but passive data is what we would call user research. He argues you need to get out of the building and talking with customers, to uncover the true jobs those customers need to do.

User Research: JTBD’s Mystery Step

One of the best features of all these books on JTBD is the volume of case studies. Christensen’s book is full of them, as is Klement’s and Ulwick’s. Spiek and Moesta produced a podcast that’s filled with them.

We noticed pretty quickly that every case study followed a basic template.

Act 1: We meet the executive or senior stakeholder who is convinced they understand why customers are choosing their product.

Act 2: The executive/stakeholder discovers Jobs To Be Done.

Act 3: Because of the Jobs To Be Done work they did, the executive/stakeholder changed up the product or its market positioning.

Epilogue: Profit!

What intrigued us was the lack of specificity for whatever happened between Acts 2 and 3. Only Spiek and Moesta go into any depth of how they determined what the customer’s jobs are. Everyone else leaves it as a mystery step.

Spiek and Moesta use an interview process. In one podcast episode, they reveal their technique by sharing an interview they did with a course attendee about the experience that attendee had buying a mattress. (Christensen reprints the 8-page transcript of this interview in his book.)

In his book, Ulwick unironically outlines an 84-step process he calls Outcome-Driven Innovation. (Really. It’s 84 steps. No joke.) But he only describes the actual research in a single step:

Step 12: Conduct customer interviews to define the core functional Job-To-Be-Done. (The following 72 steps are a variety of activities to validate the team did step 12 correctly.)

This lack of discussion suggests that JTBD is user research agnostic. Any amount or quality of user research will produce the same results.

We know, from years of design practice, that the quality of user research matters. Inadequate or poor-quality research will not uncover strategically important unmet needs. Leaving the research details undefined opens a door for process issues down the road.

The Problem with Jobs To Be Done

It’s this lack of definition on how teams conduct user research that makes JTBD problematic. Not because we don’t know how to do it. We know a lot about researching unmet needs.

Suzanne Bödker’s Activity Theory first started talking about this in the mid-80s. Karen Holtzblatt and Hugh Beyer’s Contextual Design gave us techniques specific for products and services in the 90s. There are decades of work behind applying modern ethnographic techniques to everyday product and service design.

More recently, we’ve seen work in Indi Young’s Mental Models, Jeff Patton’s Story Mapping, Dan Brown’s work on discovery, Gerry McGovern’s Top Tasks, and tools like Jeff Gothelf’s Lean UX and Jake Knoff’s Design Sprints. All of these practices are about surfacing and focusing on unmet needs of customers.

The lack of definition is problematic because it sends the message that research isn’t a critical part of a JTBD approach. Reading Christensen, it would be easy to think that uncovering the job is simple and take virtually no time.

It’s disappointing that Christensen, in this well-written book that’s likely to catch the attention of many senior executives, never mentions of any of this work. He treats his Jobs Theory as if it was something wholly new and recently invented. (For him, it may seem that way. Maybe we haven’t done a good job of promoting our field of knowledge to those outside, like business school professors, who might benefit from that knowledge?)

None of the consultant’s books mention the expertise that many UX professionals have. Some, in trying to protect their consulting revenues, go so far as to try to position JTBD as a faster, better, and more effective alternative to UX, which makes it even more problematic.

(Jim Kallbach is working on a new JTBD book. We love Jim’s work and are confident he’ll do a great job of showing how JTBD can integrate into modern UX design practices in a way that the current books haven’t done.)

Jobs To Be Done is a Sometimes Useful Gimmick

Professional magicians, dating back to Houdini’s time and before, have used the term gimmick to describe a device used to perform an illusion without requiring any skill in the art of performing illusions. With a gimmick, you just turn a nob, press a button, or engage the device in some form and, voilà, the audience sees the desired magical effect. The audience never knows the gimmick was engaged. That’s part of the magician’s secret.

If you’ve ever seen a children’s first magic set in a toy store, that’s a box of gimmicks. Professional magicians use them too. Anytime you’ve seen someone sliced into pieces and then reassembled in front of your eyes, well, the performers used a gimmick to make that happen. (Sorry if I spoiled that illusion for you.)

There are non-magical gimmicks too. For example, a magnifying glass is a device that lets its user focus in on the detail of a small part of the world. You don’t need special vision skills to see that detail. Just hold up the glass and new details are revealed. (Like magic!)

JTBD’s framing of hiring and firing is a gimmick. It’s a device for revealing and gaining a shared understanding of the behavior behind unmet needs. That has its uses. (And it seems like magic when it works!)

When a team is inwardly focused and creating features or imagining benefits without finding out what customers really need, JTBD can help. It can get the team members all thinking what those unmet needs really are. It’s a nice way to force a user-focused approach to design.

Two Problems with Gimmicks

A problem with gimmicks is, you can’t use them all the time. We can’t walk through the world with a magnifying glass on our face. Nor does the hiring/firing framing work for all types of needs.

What are the jobs a banking customer would hire or fire the bank’s website for? That will differ, based on the specific user and their needs. Remember, Jay hired his bank’s website for bill paying but fired it for money transfers. What would he do for checking balances, seeing if a deposit cleared, determining if he can afford a new monthly car payment, figuring out how much he can spend on his upcoming vacation, or any other of the multitudes of activities.

Jobs to be Done can’t help with most complex products and services in the world today. Sure, we could apply it to specific features or functions (and maybe we should more often than we do).

Another problem with gimmicks is, you can’t learn to achieve the same result without it. Gimmicks while useful, will become a crutch. All professional magicians will use a gimmick now and then. However, the best magicians can perform illusions with common objects. They can borrow a common object, like your phone or your ring, make it disappear, and then, magically, make it reappear in a place you didn’t expect.

To perform that level of magic, they need to learn and hone their crafts of manipulation and misdirection. Using a gimmick doesn’t help them learn or hone these crafts. It’s a completely different set of skills.

The same is true of design. The gimmick of Jobs To Be Done only works in certain situations. However, we have to build innovative products that deliver compellingly great user experiences even when JTBD isn’t the right approach.

To get those results, we have to learn a different set of skills than JTBD. At best, JTBD is just a distraction from the real skills we need. At worst, it takes our team in a completely wrong direction.

We need to be careful declaring, as Christensen and his disciples have, that Jobs To Be Done is the be-all-end-all innovation process. Christensen’s case studies make his book great, they also make it seem like JTBD is simple to do.

The lack of acknowledgment that design and research play a role in Christensen’s process of innovation makes it problematic. Design and research are not only seen as unnecessary, we don’t even have to acknowledge these practices exist.

Informing our Jobs To Be Done Practice

Jobs to be Done has its uses. We need to understand the contexts where it delivers value and identifies alternatives when the situation is too complex to use it.

Jobs to be Done can’t stand on its own. We need to support it with the expertise we’ve gained over the last few decades while creating our design research practices. Before learning how to apply JTBD to a project, we’re recommending teams learn and start practicing the techniques from these UX design leaders:

There’s a trove of expertise there. It’s the background a UX professional should have when exploring the current Jobs To Be Done approach. With this expertise under their belt, they’ll see that JTBD is an occasionally useful gimmick and know exactly when they need to employ it.

Getting Closer To Your Users And Their Needs

January 15, 2019

There’s a game many of us played during our childhood. I’m betting you remember it.

In a group of many people, one person starts by whispering a phrase into a second player’s ear. The second player then whispers what they heard to the third person. This repeats until the message has transited through the entire group. Then the last person tells the first person what they believe the phrase was.

The last person’s phrase never matches what the first person said. In the United States, we call this the Game of Telephone. (In other countries, I’m told the game has other names, some of which seem culturally offensive, like Chinese Whispers or Russian Secrets. Whatever it’s called, the game is still the same.)

Unfortunately, the Game of Telephone isn’t just a children’s game. It’s what we adults do in our organizations, especially as we get bigger.

Communication Breakdown

When companies are small—startup small—we communicate frequently with our design’s users, often out of necessity. To survive with limited resources, we pay close attention to what the users want and what the customers will pay for. If we don’t, we run out of money and time.

As companies get larger, those close bonds start to break down between the users and the team designing the product. More intermediaries come into the picture. Eventually, there are many, many people playing the Game of Telephone. Our users far away at the start and our product design team all the way at the end.

The end user is frustrated, so they tell their manager.

The manager tells the person who purchased the original product.

The purchaser asks their salesperson from your company if there’s a way around the frustration. (There isn’t.)

The salesperson tells the sales manager.

The sales manager tells the VP of sales.

The VP of sales tells the chief product officer.

The CPO tells the head of product for your division.

The division head of product tells your product manager.

The product manager writes user stories and then creates Jira tickets.

You pull the Jira ticket and wonder how this ever became a thing.

We have a ticket that says “intelligent data export,” “forecasting,” or some other thing we don’t understand. We have no idea what the message started as. What was the problem the end user had that caused them frustration?

The way to win at the Game of Telephone is to eliminate the people in the middle. That’s true whether it’s children or companies playing the game.

Design Leaders Must Squash Message Distortion

Some companies manage to avoid this. Intuit, for example, has always had a strong cultural battle against message distortion. When Scott Cook founded the company, he instituted a policy where every employee had to meet and watch customers frequently. It’s part of their performance reviews. It’s baked into who they are.

At organization’s where it’s not baked in, design leaders need to make it a top priority to constantly push through the distortion field. They must find ways to get in front of their users. They must ensure key personnel—those who will make important design decisions, like product managers and developers—have regular, direct exposure to what frustrates and delights their users.

As an organization grows bigger, natural forces will continually try to insert people into the middle. Design leaders fight those forces by constantly highlighting the benefits their teams has made through direct exposure. Showing what they’ve learned from user research and how that research improved their products by making it their top priority.

The Game of Telephone doesn’t have to be the norm in the organization. It takes continual work to prevent the middle people from distorting the message. Design leaders who successfully keep the Game of Telephone at bay enable their organizations to deliver better designed products and services.

Creating Your 2019 Action Plan for UX Strategy.

January 8, 2019

It’s January. Time to be thinking about what new outcomes you’d like to see at the end of the year. How can you encourage your organization to deliver better products and services?

Imagine you could review the strategies that other successful UX teams have employed to make their organizations more design mature. You’re in luck, because that’s exactly what we do in our Creating a UX Strategy Playbook workshop.

In this workshop, you and your team’s leaders will craft your 2019 action plan for delivering better products. You’ll review more than 130 strategies other organizations have successfully employed.

For each strategy, you’ll ask yourself, could we do this? You’ll assess the kind of impact the strategy could have. You’ll determine if it would be easy or hard to implement.

The strategies with the most impact and are most feasible become the basis of your action plan. They’ll be what you’ll take home with you. They’ll be what you focus on for 2019.

When you and your team put these strategies into motion, you’ll see immediate improvements. Your organization will have new respect for the value of design. Your teams will deliver products and services with better user experiences. Your organization will become more design mature.

That will happen when you come to our Creating a UX Strategy Playbook workshop. There’s one coming up very soon. February 6-7 in Chattanooga, TN.

Can’t make the February workshop? We have one every two months in Chattanooga, TN. We’ll be announcing our UK and European dates for 2019 shortly.

Don’t delay. Put your 2019 UX Strategy plan into action right away. Sign up for the workshop today.

Dividing User Time Between Goal And Tool

January 3, 2019

Designers have to worry about two types of time their user spends interacting with their design: Tool Time and Goal Time.

Imagine the user wants to put together a presentation in Microsoft PowerPoint. They’ll spend some time refining what they want to say to their audience: What’s the key message? What are the right details? Are they being too confusing? Should they communicate with words, images, or charts? Other time they’ll spend making things bold, green, and flashy.

The difference between goal time and tool time is the increase in quality gained by spending the time. When the user is working on refining a presentation’s content, they are investing in goal time. The more goal time they can invest in, the better the quality their result.

In contrast, tool time, when extended doesn’t add to the quality of the result. If it takes twice as long to change a bulleted list to be a numbered list, the presentation won’t be better quality.

In fact, we can cut the amount of tool time in half without seeing any degradation in quality. That means, we leave more time for the user to put towards goal time.

When Mihaly Csikszentmihalyi talks about Flow, he’s talking about the ultimate goal time. Not all goal time achieves flow, but when it does, that’s when we see the best quality improvements. Creating a design that helps users reach the flow state is what we should strive for.

Flow is easily interrupted. Mihaly says it takes 20 minutes for someone to get into the flow state, but only seconds to lose it. Tool time activities, when they take too much attention, can break flow or prevent users from ever attaining it.

Imagine a woman visiting a website about pregnancy, fertility, and conception. She and her partner have been trying to have a baby for a while, but without success. Now she’s looking for information that could help them achieve this important goal.

The time she spends reading helpful articles is definitely goal time. If the articles are informative and well written, she’ll spend more time reading and become more knowledgeable. If she achieves flow, she’ll spend hours on the site without even realizing the time has passed. And, she’ll be happy about it!

However, the site’s navigation, the process for registering (so sponsors can send her “relevant” advertising emails), and fluff-piece articles that don’t say anything are just tool time. Working to minimize the time our user spends on these elements will only improve her overall experience, making her more likely to come back to the site and recommend it to her friends.

Do you know what parts of your design are tool time elements? Could you reduce or eliminate these elements without reducing the quality of the user’s results? Do you know where goal time comes in? Could you find ways to increase the user’s exposure to this part of the experience?

Four Articles for a New Year

December 27, 2018

As we mature our UX craft, we’re realizing long-standing design leadership myths that have guided our work don’t really hold up to scrutiny. We have to be more deliberate about how we deliver value in our work.

It’s not a coincidence that our four most popular articles of 2018 look behind these myths to find the truth on what work practices make a difference. This is how our field matures, increases the design maturity in our organizations, and delivers better products and services to the world.

As you read these articles below, you’ll see that we’re no longer just collecting up any idea that might work. Instead, we’re forming an important foundation to what it means to produce great designs.

Net Promoter Score Considered Harmful (and What UX Professionals Can Do About It)

We were a bit taken by surprise how much discussion this article created. From our perspective, executives relying on NPS are grasping at straws for a way to tell how well their organizations are doing.

However, when you open the hood, you’ll find that there’s nothing in how Net Promoter Score data is collected or analyzed that stands up to inspection. UX professionals are caught between a rock and a hard place, trying to deliver a simple summary their executives could understand about the very complex interactions their organizations have with customers.

In this article, I explore why NPS doesn’t make sense once you start tearing it down and what UX professionals can do about that problem.

Continue reading on UIE.com.

Yes, Alan, There Is An ROI For UX Design

”How do I show the value of UX to my executives?” is probably the most common question we hear. When we’re trying to grow our efforts, we need our executives to understand what value they’ll see in return.

When Alan Cooper went on a rant, declaring that any executive who asks is probably not interested in hearing the answer, we realized we needed to talk more about how we explain value. There are very clear returns on investment for delivering well-designed user experiences, but our field doesn’t always know how to talk about them.

In this article, I explore how to formulate the answer to the value question. Design leaders need to be prepared for this question, so they can get the resources they need to do the job everyone needs them to do.

Continue reading on UIE.com.

Proactive UX Design: A Big Leap Requiring Baby Steps

Almost every organization’s UX design practice starts as a reaction. It’s a reaction to a sudden realization that without a better user experience, the organization won’t produce competitive results. Most of the advice around getting a UX design practice started in an organization is how to build a reactive UX design practice.

Yet, our research comparing successful and struggling organizations has shown that, at some magic moment, the design leaders need to change their tune. They need to move the organization, albeit slowly, in a new direction. They need to change into a proactive UX design practice.

This article talks about that inflection point of change. And we explain how successful design leaders have moved their teams into this new world of proactive UX design.

Continue reading on UIE.com.

Users Don’t Hate Change. They Hate Our Design Choices.

We found it amusing that this was our fourth most popular article this year. It’s a topic we’ve been talking about for more than a decade. Yet, it seems, many organizations haven’t realized the damage they do to their user experiences when they make jarring changes to their designs.

In this article, we tackle the myth that users hate change and that’s why they get angry when we put out a new release, even if the new release has a proven better user experience. (Anyone remember the Microsoft Ribbon?) I explore how to reframe the changes you need to make, so that your users love new updates, instead of mounting a full-scale revolt.

Continue reading on UIE.com.

Value and how to measure it were two of this year’s big UX themes. What will be 2019’s big themes? We can’t wait to find out.


It’s not a mistake that these four topics drive many of the discussions we have in every one of our Creating a UX Strategy Playbook workshops. The 2-day workshop is how design leaders put together action plan for the bringing their teams and organizations to a new level of design maturity. We can’t talk about doing that without communicating and measuring our value. So, we dedicate serious time to it in the workshop.

You’ll want to join us at our next workshop. We limit the size of each workshop to 24 people. The workshop is most effective when you bring your product and development leadership teams, so you’ll want to register soon to reserve your seats. Develop Your Organization’s 2019 UX Strategy today.

Avoiding the Wrong MVP Approach

December 19, 2018

by: Jared M. Spool

“We could make our customers happier and save the company a ton of money, all at the same time.” That was the pitch behind the innovation team’s new idea.

Yet, many at this 120-year-old insurance company weren’t convinced. They thought it could never work.

The innovation team’s idea was conceptually simple: The insurance company’s claims adjusters use photographs to assess the damage and fill out claims reports. Instead of sending professional photographers out to take the pictures of damaged vehicles and homes, they’d let customers send in their own pictures.

The company pays those photographers a lot of money. Plus, there aren’t enough of them, so customers often have to wait. Customers often need to be present when the photographers show up, which means missing work or other responsibilities. The current process is slow, frustrating, and expensive.

On the surface, it seems like a great idea. However, there are questions to resolve. Could customers take photos good enough for adjusters to do their job? These photographers go through extensive training to ensure the pictures capture the right information.

What about an MVP?

The claims processing product team was chartered with figuring out how to make something like this work. In the olden days, they would just dive in and build working functionality, hoping it would work great when launched. But, it never worked great.

To prevent a poor launch experience, the executive team had latched onto this idea of a Minimum Viable Product or MVP. They could create and deliver an MVP quickly, to see if this idea of customer-supplied damage photos might work for the claims adjusters.

What exactly is an MVP?

For many organizations, they’ve come to use MVP to mean a less functional, limited implementation application. Build it quick, get it into the hands of customers, and see how they like it.

Yet, a limited functionality version, for customer-supplied claims photos, would still be a lot of work. They’d need a way to upload the photos to the company mainframe systems, used for claims processing. They’d have to build something that attached the photos to the correct customer’s claim records. They’d have to change the adjusters’ workflow to let them know the customer had added new photos. That’s a lot of difficult system-wide changes for something that’s an unproven idea.

This isn’t how MVPs are supposed to work. Eric Ries, who coined the term in his book, The Lean Startup defined an MVP as something that “allows a team to collect the maximum amount of validated learning about customers with the least effort.” The innovation team could learn about customer-supplied photos with a lot less effort than building a limited functionality version. So, they did.

Iterate on the learning

The team started by breaking down the questions they needed to answer. The first question was, could they get customer-supplied pictures that would be good enough for the claims adjusters?

To answer this question, they simply recruited a small handful of claims agents to help with an experiment. When those agents would get a call from from a customer opening a new damage claim, they’d ask that customer to send in some photos. Maybe those photos would be good enough?

Turns out, they weren’t. The customers didn’t know what the claims adjusters would need, so the pictures didn’t have the right information. (My favorites were the customers took smiling selfies of themselves in front of their damaged home. Fun pictures, but not good enough.)

The team iterated. They asked the same claim agents to repeat this experiment, this time sending the customers specific instructions on what to photograph. The pictures that came back were better, but still not good enough.

The team iterated a few more times. Eventually, they hit upon the right set of instructions to do the job. The pictures coming in from customers were now good enough for the claims adjusters to do their work.

MVPs: No coding necessary

Without writing any code, the team learned what they needed: customers could supply valuable pictures. That was only the first step, but it was a big one. (Next up: could they easily get those pictures into the existing claim system?)

MVPs often don’t need code, but teams forget this. Our organizations are so used to solving every problem with software that we forget that we can learn what we need by faster, more effective means.

The teams that use MVPs most effectively focus on what you need to learn first. Then they ask how they can best learn it. Often, you can avoid writing any code altogether.

Consistency in Design is the Wrong Approach

December 12, 2018

Current Knowledge is a much better way to think about the problem.

Consistency in design is about making elements uniform—having them look and behave the same way. We often hear designers talk about consistent navigation, consistent page layouts, or consistent control elements. In each case, the designer is looking for a way to leverage the usability by creating uniformity. After all, if the user learns to operate the design in one place, why not have that knowledge transfer to the next. This is all good. But wrong.

For example, let’s look at a design decision our friends at Avis.com once made. At the time, they chose to use the asterisk (*) to denote optional fields instead of denoting mandatory fields. Less than 10% of the fields on the entire site are optional. If they were consistent with the outside world, entire forms would have every field denoted with an asterisk. That might create its own problems.

So, Avis.com’s designers did what designers are supposed to do: they made a choice. They chose to be inconsistent with practically every other form on the web. But they were internally consistent with themselves.

The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. “Is what I’m designing consistent with other things we’ve designed (or others have designed)?” is the wrong question to ask.

Instead, the right question is, “Will the user’s current knowledge help them understand how to use what I’m designing?” Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.

If the designers at Avis had asked, “Will the user know how to separate optional fields from mandatory ones?” they would likely have come to the conclusion that using asterisks to denote optional fields might confuse a user or two. They could’ve used a different typographic or visual solution, or resorted to the old-tried-and-true “(optional)” text next to the appropriate field label.

When you think about consistency, you’re thinking about the product. When you’re thinking about current knowledge, you’re thinking about the user. They are two sides of the same coin. We’ve just noticed that the designers who spend more time thinking about the users are the ones that end up with more usable designs.

Why do we gravitate to consistency? Because it’s easier to think about. You don’t actually have to know anything about your users to talk about making things consistent. You only have to know about your design, which most designers are quite familiar with.

Current knowledge, on the other hand, requires in-depth knowledge of the users. And that takes research time and investigative effort. It doesn’t come cheap, like consistency does. But it produces much, much better results.

Funny thing about thinking about current knowledge: when you’re done, your interface will feel consistent. Why? Because it will match the users’ expectations and, where they expect it to behave like something they’ve encountered before, it does.

(This has the interesting side effect of reinforcing the wrong thing. When you run into a site that feels consistent, you’re not likely to say, “Hey, those designers did a good job because they obviously researched what my current knowledge would be.” Instead, you say, “Hey they made things consistent. We should do that.” Thus, the cycle of poor practice is reinforced...)

My recommendation: anytime someone on your team starts talking about making things consistent, change the conversation to be about what the users’ current knowledge is.

Service Design: Pushing Us Beyond the Familiar

December 6, 2018

On this day, everything was different. Well, not everything. In fact, almost nothing. But almost nothing can seem incredibly dramatic, especially when you’re a trained observer.

The day before, our user had no trouble with the software application. While we were watching, he used it for hours exactly as the developers had intended.

Here we were, replicating all the conditions from the previous day, yet the way he used the software was completely different. His behavior had, literally, changed overnight.

Our study participant was the owner of an auto repair shop that specializes in mufflers, brakes, batteries, and tires. The application he was using was the customer tracking software, which followed each customer through their visit, tracked his shop’s inventory, and estimated and invoiced every customer work order. It practically handled everything.

Baseline: Friday

The day before had been a Friday. For this shop, Fridays are like most weekdays. Customers come into the store at a regular pace. There’s often a small rush first thing in the morning, and most of those customers have appointments and are already in the system.

On that Friday, we watched the shop owner process new customers. He’d get their name, the make, model, and year of their car, and the symptoms of their problem. He’d carefully and deliberately enter the proper information into the system, which in return, provided a proper estimate of the work.

Most of the time, this estimate turns out to be what the work actually cost, a fact the owner was proud of. Even more frequently, the estimate was lower than his direct competitor, whose shop was on the opposite corner. Another fact that made the owner proud.

The shop owner wasn’t a particularly fast typist. But on this Friday, he didn’t need to be. There were never more than two customers in the shop. He could enter all the data with his two index fingers, just like he usually did.

In between customers, he showed us how he loved the data the system tracked. He could tell that there were seasonal patterns to the types of repairs customers needed. Mufflers came in the spring, tires came in the fall, batteries in the winter. He could predict his inventory and make sure he had everything.

This application made his life easier, he proudly told us. It should. It cost a lot. (He told us that too.)

Chaos: Saturday

When we showed up on Saturday, there was already a line in the parking lot. These folks were new customers, coming to get an estimate on new work.

That’s when the application failed him. Instead of the shop owner poking the data into the application, he’d take a blank from and fill it out by hand. And instead of getting the information the application needed, he’d jot down the bare minimum from each customer.

Within 20 minutes, the waiting room was filled with new customers, all looking for an estimate. To move as fast as he could, the shop owner had to abandon his much loved application. If he didn’t help these folks, they’d go across the street and do business there. He couldn’t afford that and wasn’t letting a piece of software get in his way.

On Saturday, the software application he had praised just the day before was now his enemy. It was preventing him from getting his job done. He was inventing workarounds to bypass it.

Stumbling into Service Design

Unbeknownst to us, we had stumbled into a service design problem. Between Friday and Saturday, the application hadn’t changed. The user was the same user. What had changed was the context of use. Suddenly, something that was previously helpful was now an impediment to the business.

Because all this was more than 20 years ago, we had, at the time, never heard of service design. (In those days, we never used the term “user experience” either. That took a decade to catch on.) Because our work in those days focused on the design of software applications, that’s where we focused our energy.

Yet we couldn’t ignore this bigger picture thing happening to our user. And we didn’t know what to do about it.

Today, we’d know what to do about it. What we’d seen was a classic service design problem, and we now have oodles of techniques and tricks to find great solutions.

Now, many user experience professionals accidentally find themselves working in service design. They stumble into it, just the way we did more than two decades ago.

Service Design Is an Extension of Digital UX Design

Most of today’s user experience work is done on some sort of digital device. It involves an application or web site. Solutions involve moving bits around on a display.

However, that isn’t the “total experience” a user has. Our shop owner didn’t only type data into a computer and produce reports. For him, the digital experience was only a piece of a total customer service experience.

If we’re going to truly create better user experiences, we need to know how to create better non-digital user experiences. We need tools and techniques for doing that, just like the ones we have mastered for our digital user experiences.

Service Design Pushes Us Beyond the Familiar

In digital user experience design, we think about a lot of things. We conduct user research. We work on the visual design, the interaction design, and the information architecture. We focus on the written copy and put together a content strategy to manage it.

In service design, all those things still exist. We still need to learn about who is involved in the service scenario, understanding what their goals are and how we’ll tell what success looks like.

We need to ensure the experience looks good, feels right, and has everything the service participants need. And we need a process that gets the right information into the right hands at the right moment.

Think of an online chat capability for an e-commerce site—a tool customers use to ask about product details.

In a conventional UX approach, we’d focus on the bits. What does the chat window look like? How are messages displayed? What’s the noise or vibration it makes when a new message comes in? All of this is designed. All of it is intentional on our part.

Service design extends this scenario. When we push beyond conventional UX into service design, we now want to think about the experience of what is said in that chat window. How will the customer indicate which product they’re interested in? What will the customer service rep say in return? Is it scripted? Is there a research tool for the rep?

These details of the conversation go beyond conventional UX work, but are the centerpiece of service design work. That shift changes everything. Deep down, it’s the same interaction: using the chat window to find out info about a product. But our scope of design has extended into the service.

Extending UX Practices

Let’s look at user research: Today, many organizations conduct usability tests as their primary user research activity. They put their users in front of their digital designs and watch what happens. From this, they learn what works and what doesn’t, giving them insight in how to make the design better.

In service design, user research is still about learning what works and what doesn’t. Teams practicing service design still glean insight on how to make the design better from their user research. User research goals in service design are familiar to anyone practicing conventional user experience work.

However, to achieve these goals, we must extend our user research practices. Usability tests won’t work, because we’re not watching someone interact with a screen. They’re interacting with others. The simulated laboratory of the usability test won’t tell us the difference between a Friday and a Saturday at the auto repair shop.

For that, we need to go into the field. We need to use a full toolkit of ethnographic techniques. We may want to employ a Day In The Life study, or mobile ethnography. We’ll look beyond just the customer and explore the experiences of all the participants, including stakeholders and ancillary service personnel, such as a wholesale product buyer.

User research isn’t the only aspect of digital UX practice that we need to change when we start doing service design work. We need to look at how we prototype services, how we think about the information organized in the service delivery, how the service looks, and what behaviors we want each party to have when interacting in our designed experience.

It sounds like a lot. It is. But it’s not difficult to master. First, we learn the terminology and tools. Then, we practice them. With enough practice, it will feel natural.

Service Design is Unavoidable Today

Just like 20 years ago when our team visited the auto repair shop, teams today will get pulled into non-digital service design. It’s unavoidable.

As digital technology becomes more integrated into our overall experiences, we’ll need to start thinking about how our customers and employees flow from one area to another. We’re no longer in a world when we can design for just a single isolated online interaction, not thinking about what happened before that interaction or what happens after. And, we’re no longer in a world where we believe that every before-interaction and every after-interaction only happened online.

We’re now in a world where digital and non-digital are merging. And we need to be prepared to design in that overall experience.

Service design is no longer a “nice-to-know, someday we might do this” kind of thing. It’s become a “today, this is how we compete and produce the best damn experience for our customer” kind of thing.

As UX professionals, we need the skills and techniques of service design in our toolkit. Acquiring them will push us beyond what’s familiar to us. And that’s a good thing.

Planning The Ideal UX Leadership Offsite Is Hard

December 4, 2018

Imagine you could put together the perfect UX team leadership offsite. Two days full days, where you and your team focus on choosing strategies that grow the importance of design in your organization. Your team would review what everyone is doing well and where the team needs to up their game.

In these two days, your group would explore your team’s work from multiple dimensions:

  • Where can your team have a greater influence on your organization?
  • How would your team advance better design in your organization?
  • Where can you improve the products and services you’ve been working to deliver?
  • How might you improve the capabilities of your team, so they’re better prepared to the handle bigger challenges that the future holds?

Over these two days, you and your team would conduct some serious reflection. There would be some difficult topics to explore and some hard discussions.

With skilled facilitation, you’d navigate those difficult conversations and emerge aligned. Your team will be excited about the solid action plan they jointly created. Everyone has now bought into doing what it takes to get the team—and the entire organization—to the next level.

It’s Hard To Pull Off A Great Team Offsite

Pulling off a workshop like this takes immense preparation. You would need to craft a rock-solid agenda that covers every aspect of how your team works—at the organizational level, with each other at the team level, and as individual contributors.

You would want to assess what you’ve already accomplished, to ensure you and your team have done all you could do. You would need the team to agree to make improvement a priority.

You would need your team to go beyond what they’ve always done. For the organization to attain a new level of design maturity, you would need strategies for tackling new, difficult challenges.

We’ve Done The Preparation So You Don’t Have To

While we didn’t think of it this way when we created it, it turns out our 2-day workshop, Creating a UX Strategy Playbook is a great team offsite. Team leaders have told us they’ve seen more positive results from attending the workshop than any other workshop they’ve put together.

That benefit comes because we’ve done all the hard preparation work. We’ve studied world-renowned organizations, looking at what made them successful. From that, we’ve identified 130 unique strategies that have helped organizations deliver better products and services.

We structured the workshop to get everyone attending on the same page. They spend more than 50% of the workshop in their teams, discussing which strategies would have the most impact. They identify which strategies would be easy and which would be challenging to employ.

From the workshop’s structured discussions, teams emerge bought in and excited about their most effective strategies. When they return to their office and the daily grind, they have a plan to shift their team—and the organization as a whole—to advance the role design plays. And because everyone’s on the same page, they’re doing it together, with a common language and understanding they reached during the workshop.

We set out to create a great way to discuss UX strategy. It turns out our Creating a UX Strategy Playbook workshop is also an ideal UX leadership workshop.

Bring your team and start making awesomeness.

Bring me to you. I visited four companies in November, conducting the workshop for them. In each one, they brought 30-40 UX, product, and development leaders together, to craft an action plan with complete buy-in. They are already reporting results. Let me know if you’d like to explore this option.

A Proven Method for Showing the Value of Good UX

November 29, 2018

by: Jared M. Spool

For a while now, this has been the most common question I get:

How do I convince people in my organization to take user experience seriously? I’ve tried giving brown-bag sessions on the importance of UX, but nothing has happened.

They’ve shared every case study they could find. Nothing changed.

I tell them that I’ve never had success with brown-bag intro sessions either. But there is a way to get user experience taken seriously.

When pressed for time, I often give the short answer:

You don’t have to. There’s a high likelihood there’s someone important in your organization who already takes it seriously. They just don’t know it yet.

However, there’s a more helpful, albeit longer answer. And it goes something like this…

Step 1: Start with frustrations caused by poor experiences

Organizations that aren’t fixated on creating great user experiences are usually saddled with poor user experiences. A great user experience only comes about through constant diligence and attention. If the organization isn’t paying attention, it’s unlikely they stumbled on one by chance.

We can measure the experience that comes from a product or service’s design on a scale that ranges from extreme frustration to extreme delight. At any given moment, the design is either frustrating or delighting the person using it. By definition, a user experience is good when it delights its users and poor when it frustrates them.

Yet, it might not be the direct users—those people who interact with the product or service directly—that a poor design might be frustrating. There are indirect users, often within the organization, that find the design frustrating. Here are some common examples we’ve seen:

Salespeople trying to sell a product that is hard to demonstrate or explain.The sales team is trying to get prospects to fall in love with the idea of a purchase. If a competitor looks simpler or the prospect doesn’t understand how the product or service helps them, they won’t want to sign up. A salesperson, looking to meet their sales goals, would find the product extremely frustrating if it’s causing them to lose sales.

Call-center management responding to a poor design that generates support calls. A product with a poor user experience might put an excessive burden on the call center team. The manager of the call center, always trying to keep their costs down, may very well be frustrated by the increased call volume, even when the answers are easy to dispatch. (“Have you turned it off and on again?”)

Production managers dealing with lost worker productivity. An internal application (such as a case management system) that has too many steps or is poorly integrated with other tools will force production work to take longer. This creates backlogs and slows down overall productivity.

Development managers watching their teams rewriting the interface code.When the developers get the user interface wrong the first time, they spend time refactoring it to be easier to use. A better informed design process could’ve gotten closer in the first release.

Development managers learning that built-out features aren’t ever used. It was a waste of resources to build functionality into a product that customers aren’t using, either because the feature wasn’t wanted or the product was too complicated for the users to take advantage of the features.

In organizations with a history of producing poor designs with frustrating user experiences, it’s usually not hard to find frustrated indirect users like these. If the designs are frustrating enough (and they often are), the indirect users can become the key to build awareness in the organization.

Step 2: Identify the frustration costs

Almost always, when there is extreme frustration coming from a product or service’s design, that frustration shows itself somewhere on the organization’s bottom line:

Frustration costs due to lost sales revenue. Sales are going to competitors, the salesforce is discounting to compensate, or customers are taking a long time to sign up.

Frustration costs due to increased support costs. Call-center representatives are spending time answering calls that come from the user’s poor experience.

Frustration costs due to lost productivity costs. Backlogs are requiring more working hours or preventing the organization from being efficient.

Frustration costs due to wasted development rewrites. Development costs are higher because the team rewrites the same code multiple times.

Frustration costs due to unused feature development. Development costs for never-used features is a resource that could’ve been used to build something else.

With a little digging, we can calculate these costs. If the problem is lost sales, we can ask the sales team to estimate the amount of the sales they’ve lost. Or if the sales team is discounting to win against a competitor with a more delightful design, we can add up the discounts they have to give out to win the business.

If the frustration costs are coming from support calls, we’ll calculate how much those calls cost. We find out the budget for the call center, then divide that by the overall number of calls they get. That gives us the average cost for each call. When we multiply that average by the number of calls needed to deal with frustrating user experience features, we have the cost of that frustration.

We can do something similar with the lost productivity numbers: Figure out how much those personnel are paid and calculate how much time is spent dealing with the waste from the frustrating user experiences, either working with it (production workers) or creating it (developers). Multiply the percentage of time by the total personnel costs and you have a rough estimate.

Often, these rough estimates are all you need to get someone’s attention. After all, if this is the first time the organization is thinking about user experience, it’s likely the costs are pretty high. In one instance, we found that the costs of handling password resets at a large bank were costing the call-center support team $75 million each year. That large number was enough to quickly get the attention of senior bank management.

Step 3: Find the person in charge of reducing those costs

This is where luck plays in our favor. In most organizations, especially large ones, there is already someone in charge of dealing with the costs of frustration. However, they may not realize it yet.

It’s very likely there’s someone already assigned to increasing sales. There’s someone in charge of reducing support costs. There’s someone with the job of making the production work more efficient. There’s someone who is very interested in making developers more efficient.

These people are often easy to find. And they’re rarely in the design team’s direct chain of management. They are often in parallel organizations, outside the design organization.

Once we find them, they’ll probably be surprised that we are thinking about their problem. It’s likely they’ve never thought about how the product or service’s user experience is a root cause of their issue. They’ve either never noticed the frustration, or if they have, they didn’t think anything could be done about it. (Or they were told it was too hard to fix.)

Yet, now we have numbers. An estimate of what this is actually costing the organization. And because our number is focused directly on their charter, they often have the role power and the political influence to make something happen. Suddenly, UX is important.

Step 4: Ask the new UX champion to sponsor a lean UX project

Chapter 3 of Jeff Gothelf and Josh Seiden’s seminal book, Lean UX: Designing great products with Agile teams, is called “Driving Vision with Outcomes.” They talk about how product and service teams have traditionally focused on features, by driving projects with requirements and deliverables. They suggest there’s another way.

“Lean UX radically shifts the way we frame our work by introducing back the strategic context for our feature and design choices and, more important, how we—the entire team, not just the design department—define success. Our goal is not to create a deliverable or a feature: It’s to positively affect customer behavior or change in the world—to create an outcome.”

Reducing frustration costs are an ideal outcome. And with our new UX champion, we can get support for a pilot project.

Lean UX is an ideal approach. We can start by testing the hypothesis that our rough estimates are close to correct.

We’ll ask our new UX champion for help putting together a multidisciplinary team to uncover where the frustration is coming from. By assembling a small task force with members from all over the organization, we can collect more accurate data about the frustration and ideas about how to start to whittle those costs down.

Calculating the cost of the frustration, wherever it’s coming from, is an ideal metric to drive the project and create a measurable approach to valuing design efforts. By finding a high-ranking champion outside the design team, we get exposure at a key part of the organization. And without wasting a minute in a brown-bag lunch lecturing on the importance of good user experience, we’ve shown the organization how good design can make us more profitable.

Learn how to calculate the cost of frustration in your organization. Attend our two-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

Baby Steps - An Organic Approach to Organizational Change

November 27, 2018

We want to deliver better quality products and services. That means our organization will need to change how it approaches the planning, design, and development of those products and services.

Change is hard. There are two ways to change how an organization works: Big steps and baby steps.

The way many design leaders try to approach change is with big steps. Big steps require we make big plans. We need to get big approvals from bigwigs. There’s a lot of big evangelism we’ll need to do. We’ll likely need a big budget. That means we’ll need to make big promises. We’ll have to arrange a big number of visits. We’ll need to produce big results.

Big begets big. Everybody has high expectations. Things become high risk with a lot of attention focused on us.

Let’s say we want our developers and product managers to spend more time observing people using our product or service. Our goal is to increase their exposure hours.

We could go the big step way. We make this big plan about how we’ll get every developer and product manager in front of customers. We’ll need to appeal to the bigwigs to get big permission to take these folks away from their current work.

We’ll have to put together a big budget for all the travel and visits. We’ll need to make a big list of customers to go visit. We’ll need to make some big promises on how this will benefit the quality of the product. We’ll need to show some immediate big results to prove this is working.

That’s a lot of big risks we’re taking on. What if it doesn’t work?

Never Underestimate The Big Power of Small Changes

Or we could tackle the change with baby steps. We could do what LaiYee Ho did when she was leading design at Wink. She didn’t put together big plans.

Instead, LaiYee went on a few low key visits with a willing compatriot—a QA engineer who was really curious. She didn’t have to convince anyone but her immediate boss. She didn’t need a big, upfront plan. She just needed to get out to one or two visits.

Those visits were a complete success. That QA engineer came back completely jazzed. He helped her sell the idea for a few more visits to a few more developers. Those developers also found the visits amazing and their excitement grew. It was contagious.

Baby-step by Baby-step

Within a surprisingly short amount of time, LaiYee found herself orchestrating visits for all sorts of team members. She didn’t have to promise future results because the results were already happening. She just needed to make sure others at Wink knew about them. That was easy because team members were going around sharing all of the exciting things they were learning from visiting customers.

This is how change works when you use baby steps. Each baby step is a small risk, which goes unnoticed until something good happens. Then people get excited about the change and want to be part of it.

Baby steps are easy to repeat. If things don’t go perfectly, the next baby step is easy to do a little differently. This makes baby steps easy to sustain. Everyone’s confidence builds. And that creates excitement for the change.

We Don’t Need Big Steps To Make Big Changes

Taking baby steps like LaiYee’s show us how to introduce change and lasting influence into our organization organically. That’s how we ensure our organization delivers better products and services.

Now you know how to do it. Go forth and make awesomeness.

UX Strategy Playbook Workshop: Bring the Right People Along

November 21, 2018

Jared talking with a design leader to help him build out his organization’s UX strategy.

Implementing an effective user experience strategy for your organization will take more than a good effort from your UX design team’s leadership. You’ll need the support and understanding of every group involved in the product’s definition and delivery. You’ll see the most success from your UX strategy when the leaders of those teams buy into a plan you collaboratively come up with.

Some design leaders try to accomplish this by creating their strategy in isolation, then deliver it to the other product team leaders as a done deal. This approach rarely gets buy-in from those other team leaders. We’ve found a better approach: bring all the leaders together to hammer out a strategy everybody feels ownership of.

You’ll get the most out of our Creating a UX Strategy Playbook workshop when you bring the right people along.

Seeing the Benefits of a Strong UX Strategy

The great thing about our workshop is you can bring folks with any level of understanding about UX design. Even those who have only a vague appreciation of the benefits of good design. It’s ok if they walk in thinking that UX design is something that happens at the end of the project to neaten and pretty everything up. We’ll help them get a deeper understanding.

Everyone who comes to the workshop realizes the strategic power of thinking about their users and what they need. They see how UX design is more than nice colors, clean layouts, and modern typography. They learn how a UX design strategy is essential to solving your users’ big challenges, while also dealing with the real-world project constraints.

Don’t worry—this is a business workshop, not laden with designer jargon. Everyone will follow along, because we define every strategy and method. You will all leave the workshop with a common language and deeper insights into UX’s benefits. This will help you implement your strategy when you return to your organization.

For Product Management and Development Leaders Too

The Playbook workshop is about UX strategy, so of course you should bring your UX design leadership. You’ll get even more value when you bring the leaders of product management and development.

For your product leadership, we’ll focus on how a great UX strategy makes a product manager’s job much easier. They’ll walk through the best methods for dovetailing the UX strategy with every key product initiative, strengthening both in the process. They’ll get the ammunition they need to push back on arbitrary high-profile customer requests and unreasonable delivery dates, ensuring their team builds the right product that meets the needs of all users.

The development and engineering leadership who attend will immediately see how a great UX strategy makes their life easier. They’ll learn how their skills and knowledge can deliver better user experiences from the start. They’ll discover why it’s best if the UX design team is brought in earlier in the process.

Bring the Right People and See Great Results

As a design leader, bringing your peers from other parts of the product development organization to the workshop will make a huge difference when you start implementing your UX strategy. You’ll have their commitment to your strategic plan, with support across the entire product team.

Great products don’t happen because the organization hires a Justice League of Super Designers. Your organization will deliver great products because the teams collaborated by following a cohesive UX strategy.

Our Creating a UX Strategy Playbook workshop is the perfect place to strengthen vital team relationships. Attend the workshop together and leave with a team ready to take action and deliver better designed products.


Bring your team to next week’s Creating a UX Strategy Playbook workshop in ThoughtWorks’ Manchester, UK office. (Most teams come with four members, so bring your team of four or more.) We also have upcoming workshops on Dec 12-13 and February 6-7 in our Chattanooga, TN USA classroom.

Let’s work to collaborate together and create your team’s cohesive strategy. Register today at the Creating a UX Strategy Playbook workshop website.

Goal Challenges and Tool Challenges

November 20, 2018

For both seasoned professionals and infrequent travelers, booking a flight is a pain in the buttocks. Finding a flight that will meet the needs of the traveler and not cost a fortune can be taxing, even for those who do it every week.

Let’s say you’re trying to fly from Boston to Sydney. There are no direct flights, which means you play games with a connection. Which route is best? Will you get there in time for dinner with your sister? You have an important meeting that morning at the office. Will you have to leave early? You’re hoping this isn’t too expensive.

Hipmunk, a website and app, tries to make the challenge of finding the best flight easier than other travel sites. And, it does a good job of it.

Hipmunk’s designers came up with a novel method for displaying available flights, using ‘swim lanes’ to put each flight up for comparison. Then they sort them by a proprietary ranking system they call Agony. This combination lets you see the best flights quickly by visually scanning all the details.

hipmunk app screenshot
Hipmunk uses swim lanes and sorting by agony to help travelers book the best flight.

Designing for Two Types of Challenges

These days, collecting all the necessary details to make a smart flight purchase is very challenging. These are challenges external to Hipmunk’s team, yet they’ve done a good job of using its novel visual display and sorting algorithms to reduce those challenges. We call these goal challenges because they are inherent challenges the user faces while meeting their goal.

But novelty comes with a price. Because people aren’t familiar with this display of their information, they need to learn how to read it. When it comes time to customize the information, such as to indicate flexibility in departure times or to hone in on only non-stop flights, the user needs a method to control the display. If Hipmunk’s users are distracted while controlling the interface, they can’t pay attention to the thing they came to do: book the best flight.

Hipmunk’s designers don’t want more challenges because of their interface design choices. When they do, we call these tool challenges. Tool Challenges are obstacles created by the designers due to their choices in the design.

An important design goal for any productivity tool is to simplify goal challenges without creating any new tool challenges. Any productivity tool, whether it’s to schedule appointments, identify supply chain backlogs, or discover new chemical interactions, has goal challenges. These tools need to ensure they don’t also add tool challenges.

Turning to Game Design

Designers of Productivity tools aren’t the only ones who have to find the best balance of goal challenges and tool challenges. Game designers do, too.

In game design, you want the user to focus on the challenges inherent in the objectives of the game. Yet, to play the game, it has to be easy to manipulate the game pieces on the board, to ensure the player doesn’t get distracted by the mechanics.

Take a puzzle game like Two Dots. The basic play of the game is simple: draw a connection between two or more dots. Each level of the game adds challenges to accomplish that, which is what makes the game fun for its players.

Two Dots app screenshot
Players connect dots to clear the level. The game designers need to keep other challenges to a minimum.

Two Dots’ designers also needed to put in tools to control the play of the game. These tools let players change levels, turn off the sound or music, and adjust colors if they have color blindness or another visual impairment. These tools must be easy to find and use, not a challenge like the gameplay itself.

Game designers are experts at ensuring goal challenges remain in the users’ focus while minimizing or eliminating tool challenges. By studying how the best game designers have made these trade-offs, we can learn how to improve the productivity tools we’re designing.

You’ll want to learn how to apply this to your team’s UX design strategy. You can learn how during our two-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

We’ve partnered with ThoughtWorks to help you deliver great design

November 15, 2018

Our first Creating a UX Strategy Playbook workshop at ThoughtWorks.

We often struggle when the product managers, developers, and stakeholders we work with aren't as design literate as we need them to be. When these folks make product and service decisions, they might not realize how it affects our customers’ experience. These decisions can unintentionally make designs worse.

During the Creating a UX Strategy Playbook workshop, you’ll learn specific strategies to transform your team’s level of design literacy. With more than 130 UX strategies to choose from, you'll find the perfect ones to embed design education into your team.

Our next workshop is November 27-28, 2018 in Manchester, UK. We keep the workshop small, only a dozen or two dozen folks. You’ll get a lot of my attention to help you work through your organization’s biggest challenges, like challenges around design literacy.

November’s Creating a UX Strategy Playbook workshop is also special. What makes it special? We’re partnering with ThoughtWorks to host this workshop in Manchester, UK!

ThoughtWorks is one of the most experienced organizations at executing smart design. We’ve found their expertise has made them great partners. During the November Manchester workshop, you’ll get a nice, low-pressure way to explore if their expertise would make them a great partner for you and your organization too.

I’d love to work with you during our November Creating a UX Strategy Playbook workshop. Let’s work together to identify the perfect strategy combination for your organization alongside the great folks at ThoughtWorks.


November’s Creating a UX Strategy Playbook workshop in ThoughtWorks’ Manchester, UK office is the perfect place to spend two days focusing on your organization’s UX strategy. Join us in November.

We also have upcoming workshop dates in Chattanooga, TN. Check out our December 12-13 and February 6-7.

Four Approaches to Share and Reflect on Our Work

November 8, 2018

“Emily is going to demo her design to the entire team next week.”

“Hey, Satish wants us to critique his latest design work.”
“We’ve scheduled a meeting to review Marsha’s design.”
“Dean’s doing a design walkthrough at 2.”

We throw around these phrases all the time. Do they mean the same thing? Or are there differences? Let’s explore and take them apart.

Terms for Us and Jargon for Them

Here are two conversations for us to compare:

“Hey, what happened?” “Oh, I broke my wrist.”
“Doctor, what’s today’s surgery?” “We need to pin up the left scaphoid.”

Both are talking about the same problem. The difference is the amount of jargon for precision.

If you tell your best friend that you broke your scaphoid bone, you’ll probably just receive a blank stare in return. Most people don’t know that’s one of the eight bones that compose each wrist.

But you’d want your surgical team to be quite aware that it’s the scaphoid and not the capitate or the trapezoid. These words are medical jargon, and they are there to be precise. That precision helps the surgical team get the outcome they desire.

Someone who doesn’t know much about design (also known as a layperson) doesn’t need to know there’s a difference between a review, a critique, a walkthrough, or a demo. They shouldn’t have to know.

Yet, these terms should mean different things to design professionals. When we’re trying to communicate how we share and reflect on our designs, there are different approaches to do it. Each approach produces different outcomes.

Four Approaches to Share and Reflect on Our Work

What could make each approach different? Each one could answer a different type of question:

Design Walkthrough—How does the design match up with the business problems we’re working to solve?

Design Review–Is this design ready for moving forward or are their still issues to resolve?

Design Demo–What is the user’s experience when using this design?

Design Critique–What can we learn from this design we’ve created?

Sure, as designers, we could use these terms interchangeably, but that doesn’t help us. Establishing a consistent usage helps us understand what we’re intending, just like the surgery team wants to know if they’re pinning up the lunate bone or a triquetrum bone. (Who knew wrists were so complicated?)

Matching Up Our Intent—The Design Walkthrough

Probably the most common way we see designers share their work is with a walkthrough. The walkthrough is a simple “here’s what I did and why I did it” discussion about the design.

Walkthroughs can have a wide variety of audience members. It could be other designers on the team, stakeholders, or even customers/end users. These folks want to see the approaches the designer took to solve the important problems.

The walkthrough structure is usually quite simple. The designer shows each design element, such as a screen or a page. They point out the interesting bits and explain the rationale behind their decisions.

Audience interaction is often limited to clarifying questions and pointing out potential issues, though we’ve all seen these devolve into attempts at design by committee. (It can take a strong facilitator to prevent this from happening.)

A good design addresses a specific set of problems. If a team describes and gets agreement on those problems before they do a walkthrough, the walkthrough session will be smoother. When you clearly identify the problems, you help the discussion stay focused on whether this design is providing effective solutions.

Moving Our Design Forward–The Design Review

There are various points in a design process where we have to say, “Yes, we’re ready to move forward.” That’s where a design review would come in.

What moving forward means will depend on the process. Maybe it’s reviewing a concept prototype to decide if it’s worth refining it further. Or maybe it’s reviewing the final layout to turn over to the developer, who will turn the design into production code. In almost any flavor of the process, there are checkpoints to ask if we’re ready to move on.

When the goal is to determine if our design is ready, then we conduct a review to go over each issue that could keep it from moving forward. Once every issue has been addressed (either fixed or pushed aside), then our design can proceed on its journey.

Our focus during the review is on the design’s issue list, not the design itself. To generate that list in advance, the team could do one or more design walkthroughs. Walkthroughs would give them a chance to prepare a response to each issue before the review starts, which will make the review session more efficient.

There you have it: use walkthroughs to generate the issue list and reviews to decide which ones still need resolutions. These are two ways to communicate a design, each with a different purpose, structure, and outcome.

Sharing the Experience–The Design Demonstration

Sometimes, it’s easier for someone to understand the design by seeing it from the perspective of using it. That’s when a demo becomes the right way to share how the design works.

What makes a demo different from a walkthrough is the noticeable absence of any discussion about the problems the design is trying to solve. In the demo, the demonstrator (who doesn’t have to be the designer), narrates their experience as they use the design.

Whereas a list of problems drives the walkthrough, a scenario drives a good demonstration. “Let’s say a patient, who is experiencing extreme wrist pain, walks into the Emergency Room’s triage station. We need to get them checked into the tracking system.” Now, the demonstrator proceeds to show what the triage nurse’s experience would be, one interaction at a time.

Demonstrations can be useful, like a walkthrough, for generating a list of issues for an upcoming review. However, it can be harder to do well. Demonstrations don’t lend themselves to interruptions because it breaks the “suspension of disbelief” that puts the audience member into the experience.

If the goal is to generate a list of issues, it might be good to put a demonstration back-to-back with a walkthrough. The demo can show the experience, then a subsequent walkthrough can deconstruct it, allowing for more along-the-way discussion.

Reflecting on the Design–The Design Critique

Every design is an opportunity for the designer to learn something. Maybe they learn about new techniques. Maybe they learn something about the users and their needs. Or maybe they learn how other parts of the design work.

The critique is a fantastic opportunity for the design team to turn inward and take apart a design, learning what makes it tick. Everyone in a well-run critique walks away with a new perspective on design and how to better meet users’ needs. It’s a great way for us to improve on our craft.

Unlike demos and walkthroughs, the intended audience is the design team. Others can join in (and the team should encourage this). But a critique wants to dive into the details of how the design came about, so it’ll get geeky. (They should be warned.) After all, if a developer or product manager is curious about how the design came together, getting an immersive education on the thinking behind it will give them better insight into the process, making it less mysterious.

Critiques are different from reviews because the team isn’t honing in on the issues. Whereas a review likely only focuses on things that need fixing, a great critique session might only focus on things that worked well. After all, how did the developer get it right? What was their thinking? What was their process? What would they do to make it even better?

Of the four techniques, critiques are the ones we do the least. Yet, they are probably the most valuable, as they not only help us understand how to make this design better, but all the designs that will come after.

Variations on a Theme

For each of the four techniques, variations can modify what they accomplish. For example, one team we recently worked with took a walkthrough and modified it to compare the user stories they’d created to the prototype they’d implemented.

As one designer walked through a piece of the prototype’s flow, another designer pasted screenshots on the wall. The business analysts who created the user stories pasted the relevant stories underneath each screenshot. Then, the team could clearly see which parts of the flows were missing comparable stories and if there were stories that didn’t deal with the prototype. It was the first time the two groups had a chance to ensure their work was synchronized.

There are many ways to do each of these techniques. It’s up to the team to pick the method and variation that best suits their needs at the moment.

The Attributes Behind the Techniques

If we look closely, we can see some patterns in these techniques. Reviews and critique are both about reflecting on the design, while walkthroughs and demos are for sharing the design with others. Reviews differ from critique because reviews focus on the future of the design. Critiques focus on how the design got to where it is today.

Similarly, walkthroughs focus on sharing why the designers chose a specific solution, while demos focus on sharing how the design feels to use. Both walkthroughs and demos are about bringing a shared understanding of the design to a larger audience than only the design team. Critiques and reviews are specifically for the design team, helping them get a deeper understanding.

A team can ask basic questions about what they need. Do they have a shared understanding with a larger audience? Do they need a deeper understanding amongst themselves? Answering these questions can help them pick the right technique to use at that moment.

To the layperson, the terms might not seem that different. But to the designer, they precisely describe a technique that will help move the project forward.

Drive your organization to share and reflect on design work more effectively. During my Creating a UX Strategy Playbook workshop you’ll craft a plan for you and your team that delivers value to your customers and your organization.

There are still spots open for my workshops in Manchester, UK November 27–28, 2018, and in Chattanooga, TN, December 12–13, 2018 and February 6–7, 2019. Pick a date that works for you and let’s help deliver innovative experiences together.

Understanding the Kano Model – A Tool for Sophisticated Designers

November 7, 2018

Years ago, when Flickr, the photo-sharing website, first appeared on the scene, the designers delighted their users with a variety of interesting innovations. One of those innovations was something that now seems strikingly simple in concept: a customized home page.

At that time, practically every other website had a standard home page. When a user typed in the site’s main URL, they saw an identical page to every other user.

Flickr’s page was different. When registered users typed Flickr.com into their browser’s address bar, they saw a personalized page complete with their own latest uploads and recent pictures from their friends and contacts. We interviewed users who told us they found the personalized page very exciting, including the happy “Hello” that appeared in a different language each time they visited.

It wasn’t very long before other sites started incorporating similar capabilities. We saw many sites with a personalized dashboard showing recent activity. We even saw other sites copy the multi-lingual greeting prompt.

The interesting thing is, as these innovative features propagated into other sites’ designs, they became less remarkable and less delightful to those sites’ users. These users rarely mentioned the features and never seemed as excited about it as those initial Flickr users did.

The Kano Model—A Tool for Sophisticated Designers

Years ago, we came across the work of Noriaka Kano, a Japanese expert in customer satisfaction and quality management. In studying his writing, we learned about a model he created in the 1980s, known as the Kano Model.

This model predicted users’ reactions as the key elements of Flickr’s personalized home page appeared on other websites. It predicted why users were initially delighted and why the delight faded over time.

We find the Kano Model to be an indispensable tool for designers. Let’s take the model apart, so we can understand why it’s so useful.

The Two Dimensions of Kano: Investment versus Satisfaction

The easiest way to think of the model is on a two-dimensional grid.

Kano Model Axis Only
The two dimensions of Kano: Investment versus Satisfaction.

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality (remember, Noriaka was a quality guy at heart) or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight. (Neutral satisfaction being neither frustrated nor delighted is in the middle of the axis.)

It’s against the backdrop of these two axes that we see how the Kano Model works. It shows us there are three forces at work, which we can use to predict our users’ satisfaction with the investment we make.

Performance Payoff

When blogging first started, a blog author needed to know basic HTML to do anything fancy with their formatting. Many blogs were absent of any style just simple words on the page.

The first blogging systems added basic formatting features, like bold and italics, to their text input fields. These features would give a small word-processing feel to an otherwise bland input tool. Users were delighted.

The designers took the hint. They started adding more word processing-like features. We saw bullets, justification, image insertion, and fancy link capabilities. Each feature took more investment and returned more satisfaction.

Kano Model performance payoff
Performance Payoff-The more organizational investment, the more user satisfaction.

We’ve all seen instances like this. By adding new features or cleaning up the quality of the product, we generate more shouts of delight from a thankful audience. This is the Performance Payoff, the most visible force of the Kano Model.

Every design has a performance payoff as the design team evolves the functionality and quality. Its key designers understand how much delight is generated with each new feature, as it takes more investment to garner more delight over time by just adding features in this fashion.

Basic Expectations

Google Docs changed the game of office software. It eliminated the notion of a file and let your data live in “the cloud.” Google Docs makes it easy to share and collaborate with colleagues because it eliminates the emailing of duplicated files. Everybody works from the same source. Each person sees the same changes instantly.

A downside of editing in the cloud is the need for constant connectivity. If a user is editing someplace where the connection is spotty, intermittent problems occur. Something as simple as saving a draft becomes a frustrating moment for the user, who doesn’t know the state of their document.

Document saving isn’t a feature that will make anyone excited. But its absence or unreliability will frustrate folks immensely.

Kano Model basic expectations
Basic Expectations: The bad frustrates, yet the good doesn’t impress.

This is a defining trait of the Kano Model’s Basic Expectations. Capabilities that users expect will frustrate those users when they don’t work. However, when they work well, they don’t delight those users. A basic expectation, at best, can reach a neutral satisfaction a point where it, in essence, becomes invisible to the user.

Try as it might, Google’s development team can only reduce the file-save problems to the point of it working 100% of the time. However, users will never say, “Google Docs is an awesome product because it saves my documents so well.” Users just expect the software to save their files correctly at all times.

Basic expectations are often related to bugs and reliability. When a Skype conversation is cut off by a bad connection, it can frustrate the people on the call. When an e-commerce application double charges the site’s shopper, that’s frustrating, too.

However, a basic expectation may be something the user is already familiar with, such as automatically receiving a confirmation email after they complete a transaction. Your users may expect your product or service to have features they find in other products or services they frequent regularly.

As a designer, you need to pay close attention to the basic expectations of your users. It’s easy to focus on the new and novel elements of our design, forgetting to look back at how our users are using our existing capabilities while making sure we’re meeting all of the basics.

Excitement Generators

Zappos customers report, while they often purchase using the company’s 4-5 day free shipping frequently, they’ll receive that order within one or two days at no extra charge. This delights the customers, who go on to tell their friends. Zappos has a special relationship with their shippers to accelerate the deliveries. It’s part of their desire to “under promise and over deliver.”

Kano Model excitement generators
Excitement Generators: Design elements and features that delight the user.

There are many ways to add the Kano Model’s Excitement Generators into the user experience. Zappos does it through their delivery operations and customer support, but that’s not the only way.

Groupon generates delight through their clever use of advertising copy for the products they sell. For example, a recent ad for half-price gourmet brownies started with: “Without chocolate, the world would still be under the oppressive rule of the Turnip King and his tasteless parsnip army.” Groupon’s customers regularly say they find the clever copy delightful.

Tripit.com’s users tell us how much they love the travel-itinerary site’s automatic confirmation parsing feature. When the users email their hotel or airline confirmation email to the site, it automatically parses out the dates and locations, adding it to their trip’s itinerary. If no itinerary exists for the reservation dates, it automatically creates one. These Tripit users love that they don’t have to enter a ton of information to get all their reservation details into one, nicely formatted page.

Exploring the users’ context and overall experience helps identify potential excitement generators. These don’t have to take a huge investment. While Zappos invests a lot in their customer service, writing creative copy, like Groupon’s, can be a much simpler method to garner the user’s delight. (Copywriting is hard, and good copywriters are not cheap, but it’s easier to establish a good copywriting practice than it is to move a distribution center within 10 miles of the overnight shipping hub.)

Of course, excitement generators won’t delight users who are frustrated when you don’t meet their basic expectations. Designers need to ensure they are focusing on both ends of the model.

The Migration From Excitement Generator to Basic Expectations

A great model can help us understand what we’re seeing. Flickr’s delightful home page experience, for example, became less delightful when it started showing up in other designs.

One of the predictions that the Kano Model makes is that once customers become accustomed to excitement generator features, those features are not as delightful. The features initially become part of the performance payoff and then eventually migrate to basic expectations.

Flickr’s designers did something delightfully novel by creating a personalized home page, with a customized dashboard that showed the users’ own photographs, contacts, and activities. As other sites implemented similar dashboard-like pages, these users became more accustomed to it. The feature lost its luster.

Today, many users will be frustrated if they don’t see a dashboard page, or if they’re required to log in before seeing it. The feature, once a delighter, is now a basic expectation.

Kano Full Model
The full Kano Model: A tool to predict user satisfaction.

Applying the Kano Model

Working with our clients, we’ve seen teams prioritize their work using the Kano Model. They’re constantly monitoring their users’ current basic expectations, to make sure there’s nothing they’re missing. They are always on the lookout for inexpensive ways to add excitement generators. And they use the performance payoff to help understand how much delight they can generate with new features.

The model becomes a great way to explain to stakeholders and project owners how to tackle hard decisions. It’s a great way to keep teams focused on the right priorities.

Identify your customer’s hidden problems using the Kano model. Bring your team to our 2-day Creating a UX Strategy Playbook workshop and together learn how to institute the Kano Model at your organization.

Together you’ll also create your team’s unique strategy playbook, using other proven strategies to deliver better products and services. Look over our upcoming workshop dates, include our November Manchester, UK workshop in partnership with ThoughtWorks here: Creating a UX Strategy Playbook.

What Makes an Experience Seem Innovative?

November 1, 2018

A few years back, as it has done so many times before, Apple came up with a game changer—an innovation. For its Genius Bar, customers wouldn’t need to form a line to receive customer service. Instead, they could make an appointment for a specific time, show up, and get the help they wanted.

This was a first in consumer electronics retail. At stores like (the now defunct) Circuit City and Best Buy, the ritual was for customers to stand in lines—sometimes very long lines—waiting to meet a store representative.

Everyone assumed the old way of long lines was how you did it. They built their stores with dedicated space to accommodate the lines during busy periods, such as after the holidays. Apple’s new approach meant their architects didn’t need to build in that space, letting them put it to other uses, such as product displays.

Here’s the thing: Apple didn’t invent making an appointment. Yet their approach to using it for customer service seemed completely innovative.

Why was that? If we want to produce innovative products and services, there are lessons to learn from what Apple did.

Innovations Extend the Evolution

Standing in line sucks. There are so many better things we could be doing with our time. But if we step out of the line, we lose our opportunity to get the service we want. We want the result without the wait.

Years ago, some store somewhere (probably a delicatessen) came up with an idea. Instead of making people wait in line, they handed out numbers. When the clerk finished with a customer, they’d call out the number of the next customer. Customers no longer needed to wait in line. They could mill about.

However, they couldn’t go far from the counter. If they missed when the clerk called out their number, it would present a socially awkward moment as they tried to get back into the queue. Numbers are just one step above standing in a line and just slightly less frustrating.

The first doctors’ offices worked the same way. Want to see a doctor? Go to the clinic and get in line. See the doctor when it was your turn. A popular doctor would require you wait a long time before it was your turn—maybe the entire day.

The advent of the telephone gave patients a chance to call ahead and schedule a time to see the doctor. Now the patient could show up at the designated time (and hope the doctor hasn’t fallen behind). This change let doctors use less space for their waiting room and more space for their clinical work.

Unlike doctors’ practices, retail customer service lines hadn’t evolved to the next level. Apple made the logical jump before others. It was only because other retailers hadn’t seen it as a problem to solve that they let Apple beat them to it. Those retailers didn’t see the need to evolve.

Innovation Found at the Point of Deepest Frustration

Apple didn’t invent the appointment and they weren’t the first retailer to use it in the context of retail customer service. The tailoring and fitting services of a few high-end clothing retailers have been using appointments for years.

About a decade ago, Disney installed a similar appointment mechanism in their theme parks to alleviate lines for their attractions. Park guests can get an appointment for a specific ride, like the Tower of Terror, thereby freeing them up from long lines and letting them enjoy other aspects of the park.

Southwest Airlines reduced the confusion surrounding the crazy lines when boarding an airplane by giving everyone a place in line. Similar to Disney’s machine-assigned appointments, Southwest makes it easy for people to know when it’s their turn.

A modified implementation of the appointment is also at the heart of Uber’s city-ride service. Instead of waiting in taxi queues, Uber’s passengers request an available car by clicking on a button on their phone, making an immediate appointment. The phone’s GPS tells the driver where the passenger is waiting and sends them to pick up the fare.

Apple, Disney, Southwest, and Uber borrowed the basics of the appointment to deal with a frustration all their customers faced: waiting in long lines. Waiting is a deep frustration for customers because it’s a complete waste of their time.

By focusing on a deep frustration, the change to appointments has the feel of making a huge improvement. Had Apple focused on improving something their customers didn’t find deeply frustrating, the outcome probably wouldn’t have seemed so innovative. The perception of innovation needs a deep solution.

Innovation Extends Into the Experience Gaps

Tool time is a great place to look for deep frustration. In an experience, tool time is the cumulative moments where the user is dealing with a system requirement that doesn’t advance their goal.

In the entire experience of getting customer service at a store or riding amusements at a theme park, standing in line doesn’t help the customer or park guest enjoy their time. They may see it as a necessary evil and tolerate it, but it doesn’t make them happier. Providing them with an alternative does.

Since customers think standing and waiting is a necessary evil without alternatives, they may not complain about it. Organizations that focus on the specific activities to resolve their perceived customer objective, may overlook the deep frustration from tool time that’s happening in the gaps between those activities.

Teams that study the entire experience look into those gaps to see from where the deep frustration emerges. Addressing that frustration, when no other product or service has done so, will look innovative to the customer.

Delivering on the Promise

Apple’s appointments only delight when the Apple Store staff keeps their promise. If an Apple customer makes an appointment, only to be made to wait at the store, the innovation loses its magic touch.

The organization has to take extra care to ensure their promise is kept. Apple had to build resource management systems into its appointment scheduler, to prevent the system from scheduling too many customers for any given slot. They had to give managers tools for dealing with cancellations, absent service representatives, and walk-in customers with an emergency that can’t wait for a later appointment.

The back-end systems to something as simple as making an appointment can get very complex. Hiding that complexity while delivering on the promise makes the appointment system seem innovative.

No Innovation Before Its Time

Ten years before Apple opened its first store, Best Buy’s stores were fast approaching $1 billion in revenues. The Best Buy folks could’ve tried to come up with a solution to making folks wait in line.

In 1991 the technology landscape was very different than 2001. There was no internet or web-based applications to build a calendar on. Mainframe database systems, necessary to run an application of this scale, were slow and hard to manage. The customer service center to handle all the appointment calls would’ve cost millions to operate each day.

The Apple Store opened at the right time in technology history. By the time the first stores were opening, it was easy to build the appointment system on the new range of technology. (If the stores were to open today, the technology is even cheaper and less expensive.)

The Apple Store had the advantage of being in the right place at the right time. Their design seems innovative because they could use new platforms and a new technology stack to build out their “simple idea.”

What Makes an Experience Seem Innovative?

Who would’ve thought you could innovate around something as simple as waiting in line at a store, a taxi stand, or boarding an airplane? Yet when businesses look at what’s happening with their customers, it’s these opportunities that are most ripe for creating delightful experiences.

The recipe for making an experience seem innovative requires just the right combination of ingredients. Start with a deeply frustrating experience. Then look into the gaps between the activities. Finally, build out the systems to make sure you can deliver on the promise. When complete, you’ll have something that could change how your industry thinks about delighting customers and users.

Instituting mini creative briefs is one of more than 130 proven strategies we’ve identified in our Creating a UX Strategy Playbook workshop. Facilitating productive design discussions will allow team members to know what’s expected from them in delivering your organization's best designed products and services.

Learn more about the Creating A UX Strategy Playbook workshops at Playbook.uie.com.


I’ll be back in Manchester, UK on November 27-28—partnering again with our friends at ThoughtWorks—for another European Creating A UX Strategy Playbook workshop. Space is limited to make sure I have time to work with every team directly, so don’t delay. Register for a UK or USA Creating A UX Strategy Playbook workshop today.

The Magical Short-Form Creative Brief

October 19, 2018

Something this simple shouldn’t have such wide-spread, long-term effects on the quality of a team’s work. Yet surprisingly, it does.

We first saw it with one of our clients. It was this weird ritual at the start of every meeting that discussed one of their designs.

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three-quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review.

Typically, this little pledge-of-allegiance-like ritual took about two minutes to complete. Not much really. However, it completely changed the tenor of the meeting.

Making Sure Everyone Is Working on the Same Project

Like many teams, this team had several projects happening simultaneously. They created a different creative brief for each one. By reading a project’s specific brief at the beginning of the meeting, they made it clear to everyone in the room what they were about to discuss.

What happened after the reading was really interesting, too. The project’s leader would turn to the group and ask the same question, “Everyone agree that this is what we’re working on today?” Most of the time, everyone nodded in agreement. Occasionally, someone would ask what was meant by one of the phrases in the brief and there’d be a quick discussion clarifying some important detail.

In a couple of meetings, a discussion broke out about whether the details in the brief were still relevant. Since the last meeting, there had been changes in the direction of the overall project. The team took this opportunity to discuss how those changes might affect this specific part of the design. Sometimes that resulted in a rewriting of the brief. (On one occasion, the change was substantial enough that they postponed planned design review until the designers could incorporate the new direction into their work.)

Separating Where We’re Going From How We Get There

Talking about the creative brief at the start of the meeting has an interesting outcome we should’ve thought of before: It lets us separate our discussions of where we’re going with our design from what we build to get there.

Talking about the goals of the project is important. Often we only have these discussions during a project’s kickoff. Then we jump into the details of executing and never look back.

However, things change. New people come on board. The organization updates its offerings. Market opportunities and technology changes start to creep in. We hit constraints and challenges that make us rethink what we’re trying to do.

Dedicating a moment at the start of each meeting to discuss these changes and get everyone in the room to agree on the project’s current path is a brilliant move. It prevents a litany of time-wasting activities that happen when people are on different pages about what they’re building, who they are building it for, and why it makes the design better. Reading this short-form creative brief out loud short circuits those endless debates and lets the team focus on the problem at hand: does this design get us where we’re trying to go?

What’s in a Short-Form Creative Brief?

The trick to the brief was its brevity. We’ve seen creative briefs that weren’t brief at all—they were 200-page “thump books” (called that because of the thump they made when you dropped them on a table). These tomes, filled with every possible piece of thinking and research about the project, wouldn’t make sense to read out loud at every meeting. At best, they were read once and then long forgotten.

Instead, this team had honed their briefs down to four key components: the project objective, the key personas they were building for, the key scenarios those personas would try to use the design for, and the key design principles for this round of the project. Each of these were just a few sentences. It was simple to create and simple to read during the opening ceremony of each meeting.

Part 1: The Project Objective—This was 2-3 simple sentences about what this specific part of the project was trying to accomplish. For example, one team was working on a call center application for airline reservation agents that had a project to help with distressed passengers dealing with an unexpected flight change.

Objective: Build an automatic sidebar selector that appears when the passenger calls in. The application detects that the current itinerary needs a re-routing and provides the agent with the best new travel options to recommend to the passenger.

The idea is to keep the objective simple, so the brief doesn’t get into all the constraints and requirements. The team has all those things written down, just not in this document. They only included enough so everyone knew what this project was trying to do, relative to everything else they were trying to accomplish at the same time.

Part 2: The Key Personas—The team would list one or two personas they were designing this particular functionality for. They chose these from a larger set of personas they had created earlier. What they listed on the brief were the most important personas for this round of design. This helped eliminate discussions about personas and scenarios that they explicitly weren’t trying to deal with at this time.

Key Persona: Walter—a 17-year veteran of the reservations center, who primarily works with premium and global services customers. He is a walking encyclopedia of the reservation system arcana and often supports other employees on difficult problems.

Like any good persona description, the team would only include details that would play a role in key decisions they were facing. Their personas reflected real people they had researched themselves, so they intimately knew these people and what they were trying to accomplish. The personas often came up during the design discussions because they were fresh in everyone’s mind, having been just read out loud.

Part 3: The Key Scenarios—Here the team would describe up to three short scenarios that the design was trying to solve. Like the personas, they chose these from a larger set that had come out of their research. While everyone knows there are other important scenarios, the ones listed in the brief are what the team is now solving for and where the discussion should focus.

Key Scenario: Walter was called in special to help with a huge snowstorm that had cancelled many flights along the Eastern Corridor. The current call is from a passenger whose Philadelphia-to-Denver delayed flight (which hasn’t departed yet) will cause him to miss the only connecting flight to Seattle. This passenger needs a rerouting that will get him to Seattle today.

The scenario provides enough detail to make the design rich. By including a couple of these in the brief, the team can explore different angles of the problem that can help derive the design.

Part 4: The Key Principles—Like many teams, this one had come up with several guiding principles. In the brief, they listed one or two that they wanted to focus on for this iteration of the design. They would change it up as the design progressed, to ensure they were considering all the principles they thought were important.

Key Principle: Passenger Delight over System Efficiency-The design should provide a great passenger experience even if it incurs an expense or inefficiency in the flight system.

Like the personas and scenarios, the principles came out of the team’s research of where their customers were frustrated and how to bring out great experiences. They had a half dozen of these and would choose a new one for each design iteration.

A Simple, Yet Effective Ritual

We’ve been bringing this ritual to many of our clients and were shocked at how successful it’s been. Because it’s such a simple technique, everyone finds it easy to adapt into their current process. The elegance of the solution is what makes it work so well.

A short, concise brief about what we’re trying to do can focus our design discussions and keep our meetings productive. The end result is better designs that get regular, constructive feedback, without the baggage of dealing with the ever-so-common disconnects teams often experience.

What Goes into a Well-Done Critique

August 23, 2018

Receiving a critique is probably one of the hardest things we’ll do in our work. Giving one is equally as difficult. It’s hard to do well and easy to do poorly. As we’ve been working with teams over the last 20 years, we’ve accumulated an understanding of what goes into a successful critique. Here’s what we’ve found.

What a Well-Done Critique Is (and Is Not)

You can tell a critique has been successful when everyone involved—the design owner, the critic, and the rest of the team—have all learned something to make them better designers. A well-done critique is a way to step away from the specifics of the design process and better understand how to create great designs. We do this by starting with the current design and asking “What is it we’re really trying to do here?” and “How close are we to doing it?”

A critique is different from ‘proofing’ the design. When we proof, we’re looking for those little details, like typos and inconsistencies, that distract us from reaching perfection. Proofing is about polishing, whereas critiquing is about reaching understanding.

A critique is also different from common usability techniques, such as heuristic evaluations, cognitive walkthroughs, inspections, and usability tests. These, when done well, look at the design from the perspective of the user. Instead, critique looks at it from the perspective of experience and viewpoint of another designer. Both perspectives are invaluable to successful designs, but they should not be confused.

The most successful teams have everyone in the role of a critic at some point. Some do it through regularly scheduled studio sessions. Some make it part of their overall design process. When everyone knows they’ll be on both the receiving and delivering end of a critique, they tend to be more in tune with the overall goals.

Four Elements of a Well-Done Critique

As we observe teams involved in critiques, we’ve seen some patterns emerge. The teams that benefit most from the critique process share four basic elements: respect for the hard work and experience, a dispassionate approach, recognition that the critic lacks authority, and justifications for the discussion points.

Element #1: Respect

In the best critiques, the critic, when delivering their advice and criticism, understands and acknowledges the hard work the design owner has put into the design. The critic knows it’s taken a lot to get to this point, and they reflect that understanding in their dialogue.

The critic also knows how difficult it is for any design owner to receive a critique. This means going beyond basic cordiality and politeness. A skilled critic will understand the design owner is invested and works to reduce the ‘attacking’ feeling that is a natural reaction to any criticism.

Respect comes in small ways, such as only providing a critique when the design owner is ready to receive it. Anyone who has been ‘ambushed’ by an unsolicited critique knows that the element of surprise does not enhance their receptiveness to the advice and criticism.

Element #2: Dispassionate

When done well, everyone can step away from the design. The design owner understands they aren’t being judged.They’re helping the team see the journey they’ve taken to get here. The critic, who sees the design at its current state, uses the critique to explore different design directions. The critique becomes a learning opportunity for the entire team by spreading expertise, vision, and skills.

Element #3: Lacking Authority

The seasoned critic knows the harsh truth: nothing they say will directly change the design in any way. The only way the design can change is if the design owner does it.

In the best critiques we’ve seen, the critics never made a single recommendation. Instead, they asked questions and guided discussion. They talked about the significance of design rationale as it pertained to a bigger philosophy and vision for the design.

For example, instead of saying, “While I think those flyout menus are slick, I recommend you nuke them and put the links in the center of the page,” the critic might ask, “What alternatives did you consider for the flyout menus?” By moving the conversation to talk about the bigger picture, everyone can discuss how this element (the flyout menus) is contributing to the total experience.

Element #4: Justified Impressions and Concerns

In any well-done critique, we see two themes that run concurrently: the positive impressions the design leaves on the critic and the concerns the critic has about the design’s direction. This balances hard-to-hear criticism with the good things the design owner did. In both cases, the critic goes beyond a simple statement and provides a good justification for their thinking.

We’ve observed the skilled critics avoid hollow compliments, such as “I’m liking the direction you’re going in.” (Or worse, the half-compliment: “I like this, but…”) Instead, they take it further, sharing specifics on what they like and how it supports the direction of the design. The detail not only helps the design owner feel good about what they’ve done, it connects the vision and philosophy to the design itself.

Similarly, when offering criticism, we’ve seen the seasoned critics stay on solid ground by justifying their concerns and showing alternative examples. The team can then discuss the merits of the justifications, instead of making it a battle of opinions about taste. By comparing design alternatives, the team looks at the essence of the design issues. While, in any project, practical constraints often win out, discussing the higher level concepts help the design owner (and other team members) make better decisions going forward.

Questions for the Well-Groomed Critic

Thinking about improving your critiquing skills? Here’s one way to approach the process. Just ask yourself these questions during your critique:

  • What did I enjoy about this design and why?
  • What concerns me about this design and why?
  • What does this design remind me of and why?

Ideally, you can keep all three questions in balance, ensuring you have as many positive comments about the design as criticisms. (Some of the more seasoned critics we interviewed told us they try to have two positives to every negative in their critiques.)

When delivering the critique, the skilled critics told us they rank the criticisms in priority order, ensuring that the most critical comments come first. Each point they raise is about moving the conversation forward. “Have you considered…” is a great way to start an important criticism, since it gives the design owner a chance to say, “I did, but I chose this direction because…” Now, the team can talk about the bigger issues behind the rationale instead of nitpicking the design details.

Critique-Safe Environments

As we talked to teams, another pattern emerged: the teams that felt they got the most out of their critiques also were the teams that conducted them the most. We learned that regularly scheduled studio sessions, where the team reviewed one or two designs each time, had several interesting benefits.

One benefit that jumped out at us was that critiquing skills improve with each session. As each team member took their turn to conduct a serious, wholehearted critique, they got better at it. Sitting in the design owner’s hot seat also improved the skills for receiving criticism and thinking more broadly about their own work.

Another benefit came from seeing a design evolve. Later critiques would have better background knowledge on the goals and history, showing how both the design and the designer have matured through the process.

Well-Done Critiques

Critique is an essential part of the design process, but it’s not something most UX professionals are taught. Like many important skills, it’s hard to do well and easy to do poorly. Improving your critiquing skills makes you more valuable to the design team, while you learn about creating better designs.

Originally published on UIE.com

The Hunt for Missing Expectations

August 16, 2018

Few things in business are worse than a bookkeeper scorned, and this bookkeeper was angry. She was upset because she wasted what seemed like 20 minutes looking for something so simple and obvious, it just had to be there. But it wasn’t.

The bookkeeper in our study was looking for a way to indicate a double underline. When you have a column of numbers, divided into sections (such as income and expenses), you use a single underline above the total of each section. For the grand total, at the very bottom, the standard practice is to put two underlines.

The practice of double underlines for grand totals predates computers and spreadsheets. One can look at ledgers from the industrial age and see the double underline hanging out just above the ubiquitous “bottom line.”

That’s what our participant wanted. She had her income section, all neatly totaled, followed by an equally neat expense section. The formula of subtracting expenses from income left a hauntingly small profit line. This line begged for the double underline.

Yet nowhere in Google Spreadsheet could she find such a thing. It was a spreadsheet, just like Microsoft Excel, Lotus 1-2-3, and the others that came before it.

However, for some unknown reason, the developers of the Google Spreadsheet had either left out or hid the double underline. The bookkeeper couldn’t imagine they’d leave such an obvious thing out of the design, so she searched for it.

And searched for it.

And searched for it.

All to no avail. It just wasn’t there. The developers had just missed this function.

A double underline is not a difficult thing to implement. Maybe they knew about it and wanted to keep the interface lean, so it didn’t make the cut.

The Death of a Thousand Cuts

That didn’t stop this user from expecting the double underline to be there and, subsequently, wasting precious minutes searching for it. This simple thing upset her tremendously and she told us she didn’t like using the application.

There were other features and design elements she searched for. Each one took time. Each one distracted her from her goal of producing what should’ve been a simple profit and loss statement, something she’d done a million times in her job.

The design was dying the death of a thousand cuts. No single missing feature was a big deal, but when she added them all up, it was making the design less desirable to work with. This is the problem with missing expectations.

Missing Expectations vs. Failed Expectations

In a hair salon we recently visited, the receptionist was despondent. As clients came in, she’d glance at the screen showing what should be her day’s appointments, frown, then proceed to ask the customer their name and what they’d made their appointment for.

A few days earlier, the hard disk crashed on the server the salon used for its appointment booking application. If there were backups, nobody at the company or the software provider knew how to restore them. All the salon’s data was gone.

Customers would show up for an appointment the salon didn’t have a record of it. They were trying to recreate everything, but it was extremely frustrating.

The salon’s owner had the expectation that the salon’s data was safe. Hardware failures have been a fact of computing life for decades. The owner had every expectation the software provider would take all precautions to ensure no loss of data or time when something catastrophic happened, yet here they were with a business catastrophe of epic proportions.

The data loss is a failed expectation while the Google Spreadsheet’s double underline problem was a missed expectation. Users and customers don’t care about the difference, but teams should because you look for them in different places.

Failed expectations are uncovered by careful introspection of our designs. We can look at each functional component and ask “How will users be disappointed or disrupted if this feature fails them?” Even if we miss it the first time, we’ll hear about it when it raises its head and we’ll be quite alert to ensure it doesn’t happen again.

Missed expectations are more fiendish than failed expectations. They are much harder to spot. Introspection won’t likely get us there. Instead, this is where solid user research comes to the rescue.

Surveys and Usability Testing Won’t Help Much

When many folks reach into their user research toolbox, the first tools to emerge are surveys and usability testing. However, these are not that helpful with discovering potential missed expectations.

For example, imagine I was building a new hotel and I asked you what you’d expect to be in the ideal hotel room. It’s unlikely you’d think to mention “a working bathroom” because you’d just assume I’d already know that. However, I’m betting you’d be surprised if there was no bathroom when you checked in.

Watching users work with the design, the core practice known as usability testing, also struggles to uncover important missed expectations. They seem like they’d be perfect, but the way we construct the tasks gets in our way.

To keep the testing simple and under control, we often define the outcomes we want. For example, in testing Google Spreadsheet, we might have a profit and loss statement we’d want participants to make. To make it clear what we were expecting, we might show the final report we’d like them to make.

Since we never thought about the importance of double underlines, our sample final report wouldn’t have them. Our participant, wanting to do what we’ve asked of her, would unlikely add double underlines in. Our bias is reflected in the test results and we won’t uncover the missing expectation.

Milking Any Customer Contact

One good source that’s probably flowing with missing expectations are the calls and questions coming into customer service. Users, frustrated by what they can’t find, may regularly reach out to the service reps with inquiries about their expectations.

We’ve found most organizations don’t do a good job of collecting this information. Because it’s not a fixable problem, it usually doesn’t get logged and categorized. Even when these are collected, they are usually just counts of the requests and there’s no exploration as to why they are needed. Without answering why the user needs it, attempts to implement it will likely get it wrong.

Upgrading the customer support mechanism to collect and categorize these inquiries can raise the awareness of missing expectations, which, in turn, helps justify other research.

Upping our Ethnography Game

Armed with the list of possible missed expectations gleaned from the customer service department, teams can head into the field to observe how these needs manifest themselves. This is when we really learn what we can do better in our designs.

Walking into a customer site for the first time is much like awaking in the middle of the night and turning on the bathroom light—it’s too bright to see anything meaningful until your eyes adjust. The flood of contextual information you get from the initial customer visits is overwhelming to those who are new at it, thereby making it difficult to say what you’ve learned.

However, with repeated visits to other customers, you start to see patterns emerge. The definition of the missing expectations becomes clear. In each location, it’ll show up slightly different, but the basic theme will be there.

Regular ethnographic activities are critical for any team that wants to ensure it meets expectations. The investment here is easy to justify in reduced support costs, better customer engagement, and solid differentiation from those competitors that don’t go into the field.

Advanced Lab Techniques: Interview-Based Tasks

Having been in the field, the team can then create similar environments in the lab. Using a technique known as interview-based task design, the team can extract missing expectations by more closely simulating what users really do, thereby uncovering what they think they need to do it.

Instead of dictating exactly what the usability test participant will do, the moderator starts each session with an interview of the participant. They ask questions about how, in the past, they’ve performed the activities supported by the design. The moderator dives deep into what led to the activity and how it turned out for that participant.

Based on what they learn, the moderator works with the participant to create a task that replicates what they did last time. Then, they set out to replicate that past experience with the design.

It’s in the recreation of the work that missing expectations become pronounced. Since the co-created task is a better match to the users’ previous experiences, they’ll fall into their own habits. Once they are comfortable working as they always have, any place where the design has missed a feature or implemented something awkwardly will quickly emerge.

This approach takes a more sophisticated user research approach than standard usability testing. Many practitioners aren’t comfortable improvising tasks, while making sure they don’t lead the participant down a path that only confirms the teams’ existing balance. First time folks need to practice a bit to get it to work.

With a good combination of ethnographic field work and advanced lab techniques like interview-based tasks, teams can avoid missing important expectations. Even those expectations that seem minor at first, but add to the death of a thousand cuts, can be discovered and seamlessly integrated into the design.

Originally published on UIE.com

Learn how to surface your users’ expectations before they fail. Bring your product team to our 2-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

Experience Rot

August 9, 2018

Here’s a counter-intuitive fact: Chances are all those features you’ve been adding to your design are hurting your user experience. Every feature that’s squeezed in, in the name of giving your design a competitive edge, has been making your design less competitive.

Welcome to the effects of Experience Rot. As you add features, you’re adding complexity to the design, and decreasing the quality of the experience.

Pick up any modern TV remote and you’ll immediately see the problem of experience rot. On/Off, volume and channel selectors are no longer enough. We need to switch devices, control captions, have a text capability for on-screen editing, a thumbs-up and thumbs-down for ratings, pause, record, slow motion, rewind, 30-second rewind, and, well, you see the effects. The complexity never ends, it never gets simpler, and it’s never delightful.

Experience Rot Starts with Version 2 (maybe earlier)

By their nature, most first releases of a design are really simple. The design is a small collection of well thought out features. Everything fits and makes perfect sense. At this time, the rot hasn’t begun. Everything is new and fresh.

However, that doesn’t last long. The moment a new feature is added–one that wasn’t considered in the initial design–the rot starts to take hold. It’s at this moment that a rethinking of the design has to happen and the seeds of complexity are laid.

If that new feature is close in style and function to the original set of features, the experience rot may not be visible. Yet, because it needs to be retrofit into the original design, it starts down the inevitable road.

As more features are added, it becomes harder to make the overall design coherent and sensical. Soon features are crammed into corners that don’t make sense.

The Experience Rot Experience

Users who have been along for the ride since the early versions can slowly adopt to a few new features in each release. As more features are added, the chances they’ll want or need those features start to diminish. They’ll do their best to ignore anything that doesn’t work for them. It’s the features they like, but only use occasionally that give them the most trouble. These features are often hidden in a place they don’t expect. Their frustration grows.

New users suffer more dramatically. Having joined the design later in its evolution, they find themselves befuddled by any logic in its organization. As soon as they start to glean a consistent mental model, they encounter a feature that seems to have no logical reason to be there. It’s like wandering through a mansion and coming upon a large banquet hall with a toilet in the center.

Organizations and individuals become more reluctant to upgrade to the newest versions. The value in each new release is diminished by the hours lost learning the new interface. Eventually, it’s not worth the time and energy to get a few features which may never get used.

Rotting on the Inside

It’s not only the external user experience that suffers from the rot incurred by the slow addition of features. The internal code suffers too.

Every new feature puts demands on the architecture that wasn’t originally anticipated. At first, a smart team can keep up with the necessary refactoring. The increasing rate of new features puts pressure on the team and it isn’t before long that the architecture starts to show strain.

Often there’s a central piece of core functionality that suffers the worst. (In my experience, it frequently goes by the name “billing engine”.) The logic and threads get so gnarly that nobody can risk making changes without breaking something important.

All of this slows down the pace of future development, making even minor enhancements substantially more difficult. The time between design iterations can move from weeks to months to years.

In Comes the Competition

It’s the market leaders that often suffer the worst experience rot. They have the most money to spend on new development and they have the most pressure to keep leading the marketing place with new inventions.

It’s experience rot that opens a market up for disruption. The market leader, slowed down and overly complex, gives a chance for a new company to make inroads. By studying the small number of features that most users care about, and freed by not having a large codebase to deal with, they can implement a simplified version. This version is much easier for new users and a straightforward transition for the more experienced user base.

We’ve seen this pattern repeat itself dozens of times. Microsoft Word for DOS, with only 70 features upon launch, beat down the 1700-feature WordPerfect. Now we’re seeing Google Docs doing the same thing to Microsoft Office (despite Microsoft’s attempt to port desktop Office to its SaaS-version of Office 365). In search engines, Google took over from AltaVista. In the world of CRM systems, Salesforce.com displaced Siebel which upended Oracle who stole the market from SAP.

Experience rot not only makes design and development difficult, it puts the entire organization at risk. Unless it’s controlled early and often, it’s a growing time bomb waiting to go off.

‘No’ Fights Rot

The best way to fight experience rot is to say ‘no’ to everything except the most essential of features. Deliberately slowing down the product roadmap to only include well thought out and integrated new enhancements will keep experience rot at bay.

Saying ‘no’ is always in the designer’s toolkit, but in the excitement of producing something new that gets press and attention, it often gets overlooked. It takes a lot of organizational willpower to keep a design simple.

Often the organization’s design leadership doesn’t realize they needed to be saying ‘no’ until the rot is horrifically visible throughout the design. It isn’t until users are complaining about complexity and the developers can’t make important changes quickly enough that everyone realizes that full extent of the problem.

The 1,000 ‘no’s to every ‘yes’

It takes strong organizational leadership to keep the team focused on fighting rot from the beginning. It’s not the norm in today’s world, but we do catch glimpses of teams that pull this off.

Steve Jobs once said, “You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.”

Picking the right things to say ‘yes’ to is a careful art. One trick is to give yourself a lot to choose from. Saying ‘no’ to 1,000 things, like Jobs referred to, means you have to have 1,000 things to say ‘no’ to.

The smart organizations spend a lot of time trying ideas, knowing they’ll say ‘no’ to most of them. However, that constant experimentation helps them understand what’s possible and gets them closer to finding the ‘yes’ that will dramatically enhance the experience without increasing rot.

Strong leadership, constant experimentation, and a diligent attention to what truly enhances the design is how you fight against experience rot.

What Customer Problem Are We Solving?

August 7, 2018

“This is exactly what we need right now,” the head of engineering said to me. We were reviewing the eight user experience plays his team chose (out of the 130 I presented) during our Creating a UX Strategy Playbook workshop.

They’d chosen smart strategies for their situation, but one play stood out: Institute “What customer problem is this solving?” into enhancement discussions. By executing this play, the team would make it safe to talk about the customer’s problems driving any feature or enhancement.

I asked the head of engineering what made this an important strategy for his team right now. His response was telling. “We’re always being asked to build things and we often don’t know why.”

Where Do Feature Enhancements Come From?

“Sometimes, the enhancement comes from one of our users,” he explained, “who we never get to talk to. Instead, the user would tell their manager about the problem. Their manager told their organization’s head of IT. The head of IT told our salesperson, who in turn, told our product manager. Our product manager then wrote a user story that they put in the backlog. That’s when we hear about it.”

“The user story might say, ‘As a user, I need to export my data to load into other applications.’ We don’t know which data. We don’t know which other applications. We don’t know what they do with it once it’s there.”

“We’d ask our product manager, but he doesn’t really know much more than we do. If our user ever mentioned the reason to anyone else, it has long been lost to the chain of communication.”

Are we Building The Right Thing?

When they don’t know the problem that precipitates an enhancement request, they can’t possibly know when their new feature might be ready or how they’ll do a good job. “We usually don’t know if we’re building the feature right or if we’re even building the right thing.”

“Without knowing the problem, it’s almost impossible to do a good job,” he told us. This is why he loved this UX strategy play so much.

He’ll institute a regular discussion about the customer’s problems for every new feature and enhancement the team is asked to work on. He wants the salesforce and product management teams to collect this data as they get new feature ideas. He’d ask the design research team to lead his engineers into the field to meet directly with users, so they can see the problems first hand.

Fall In Love With The Problem

There’s an old saying: “Great designers don’t fall in love with the solution. Great designers fall in love with the problem.”

It’s impossible to fall in love with a problem you know nothing about. Instead, start asking What customer problem is this solving?

Don’t stop asking What customer problem is this solving? until the team truly understands the problem. That’s how we deliver the best products and services. That’s how we make our organizations competitive through design.

Proactive UX Design: A Big Leap Requiring Baby Steps

August 2, 2018

These days, we’re seeing more teams successfully bring more proactive user experience design into their projects. It’s not easy, but the results are worth it.

When teams engage in proactive user experience design, they deliver better products. Proactive UX design tackles the bigger challenges faced by the product’s users. By delivering a better design, the team contributes more to the organization’s overall success.

Reactive UX design is where most design teams start. Reactive UX design is just what it sounds like: reacting to a problem in the moment. “Oh, can you fix this?” “Help! Users are complaining this is too hard! What can we do?”

Without also having proactive UX design efforts, the design team is only fixing problems caused by decisions the product team has already made. These already-made decisions are about what the product will do, how it will work, and what its underlying architecture will be.

By the time the design team is brought in, these already-made decisions are cemented into place. They present the design team with huge, often challenging constraints to work under. The design’s problems need solving, but the options for solving those problems are very constrained.

When Design Teams Get Comfortable Reacting

Despite challenging constraints, reactive UX design is often a comfortable place for teams to find themselves. It’s clear what the team needs to do. The team’s UX designers create wireframes, communicating how the screens and pages should look. They conduct usability tests, ensuring users can easily interact with the design as it’s being built.

For those product teams that previously didn’t have serious design efforts, reactive UX design feels like a huge improvement, and it is. The organization sees happier users from the better designs.

Unfortunately, it’s an easy place for design teams to get stuck. The product leadership, seeing the benefits of good design work, wants more of it. Yet, all they know is the processes and deliverables of reactive UX design. They like the wireframes and usability tests.

They believe this is what design work looks like. They believe design work always happens at the end of the process. Accidentally, the design team’s behavior reinforced this belief.

The leadership doesn’t realize it could get something better. They’ve never seen the benefits of proactive UX design. (To be fair, they likely had never seen the benefits of any design until the design team started their reactive UX design efforts.) This is all they’ve ever known about design.

The Benefits of Proactive UX Design

When a design team is engaging proactively, their research efforts are exploring the users’ experience in more detail. They go beyond usability testing by heading out of the building to on-site visits, seeing customers and users in their natural habitats. These observations bring back a larger context of what the users’ challenges are. These challenges aren’t often addressed by any competitors, let alone by the organization’s own products.

The design team can use these insights to suggest alternative directions for the product. These directions are informed by actual user needs, not by market pressures and guesses about how people might use it.

The deliverables of proactive UX design give substantially more guidance to the product team. The design team can create journey maps and service blueprints to show what the users’ current experiences are. They can craft an experience vision to promote what an ideal, aspirational experience could be.

When proactive UX design is at its best, the rest of the product team is bought into this work. The product team integrates the users’ needs into important up-front decisions. Those decisions prevent restrictive constraints in the product. Eliminating those constraints reduces new design debt later on and makes delightful design solutions easier.

Once product leadership sees what proactive UX design can bring, they love it. Yet, that’s the catch-22. They won’t invest in it until they see its benefits, which can’t happen until they invest in it.

Introducing Proactive UX Design isn’t Easy

The design team has to leave their comfort zone of being reactive all the time. It’s hard to do, because being reactive can be all consuming. If you’re spending all your time reacting to the design problems coming at you, where do you find the resources to do proactive UX design?

The reactive UX design work can’t stop. It’s adding necessary value to the product.

However, the way most design teams handle reactive UX design work can change. Instead of designers doing all the work, they can start to share the burden.

Developers can learn how to design better interactions. They can use techniques like paired design, where a designer and a developer sit together and work through designs of screens or interactive dialogues. In these sessions the developer learns the essentials of good interaction design. Over time, they can handle more of the design work, requiring fewer wireframe efforts.

Similarly, exposing developers and product managers to more user research creates a larger shared understanding of the struggles users have with their product. They start making more decisions informed by what they’ve seen users do in research sessions. The designer’s burden to be the sole advocate of the user diminishes.

None of this happens quickly. It takes time for everyone to come up to speed. It needs to become a habit to work this way.

Proactive UX Design Doesn’t Happen Organically

Without concerted efforts from the design team, they’ll remain doing reactive UX design forever. Proactive UX design requires different work from what a team does for reactive UX design. The design team needs to add this additional work into their daily routine.

Some teams try to sell the idea of proactive UX design to their management, but that rarely works. Because of the catch-22, management can’t commit to a large change in the process. It seems too risky. Also, teams can’t just switch to the new work. They have to keep designers solving reactive UX design problems while they adapt to the new proactive UX design practices.

Instead, the design team leadership has to make changes incrementally. They have to introduce the new work practices one at a time.

The rule of thumb is simple: If the rest of the team can notice you’re doing something different, you’re probably changing too much too fast. Design leadership is a game of patience. To avoid triggering resistance to change, any change has to happen undetected under the radar.

Proactive UX Design is Worth the Hassle

If introducing proactive UX design into an organization was easy, everyone would be doing it. It’s not natural. The team will face many stumbling blocks.

Design leaders who undertake this challenge need to know what they’re in for. For many of them, it’s the first big challenge they’ll take as a design leader.

However, it’s worth it. The research insights of who the product’s users are and what they need should inform every decision in the process, not just the decisions that come at the end of the process.

Everyone benefits from taking the time and pushing the organization in the direction of becoming more proactive. Product management gets a vision informed by user research that shows how the product could be a market leader. Development gains the skills and insights to produce better designs. The users get a better, more thoughtful experience.

Design and research can now influence every decision about the product. Design gets its metaphorical “seat at the table.”

It’s a big leap for the organization, even if it took many baby steps to get there.

Goods, Bads, and Dailies: Lessons for Conducting Great Critiques

July 26, 2018

What do Pixar’s animators and teenage magicians have in common? Surprisingly, they both have developed some interesting critique techniques that we’ve learned a ton from.

The teenage magicians are members of the Society of Young Magicians’ Boston Chapter. It’s a group of 30 or so kids, ages 8 to 20 years old, who meet monthly to learn about performing magic and hone their skills.

Each meeting, they conduct “The Chosen Ones,” where four of the young magicians perform a five-minute routine and then receive critique from the other kids in the group. When I first heard about this, I thought, “Wow, that’s got to be a disaster.” After all, young adolescents aren’t known for thoughtful critique skills.

I was blown away by the performances and by how constructive and encouraging the critique sessions were. The kids came away feeling good and received a wealth of helpful, instructive ideas on how to make their routine even better. The respect and thoughtfulness these kids put into the sessions is something I wanted to bottle up and bring to every design meeting.

Pixar’s Dailies

Around the same time I was hanging out with the kid magicians, I started learning about Pixar’s process of reviewing their progress in the creation of their great animated films. One of their techniques is a regular meeting they call Dailies.

Dailies come out of the movie industry. They were a morning showing of the previous day’s filming. Before a day’s filming, the director, producers, and senior crew would review the previous day’s film to identify any reshoots or changes.

At Pixar, where films are made in the memory of graphic processors, they’ve morphed the regular meetings into something a little different. In these sessions, artists and crew members present work-in-progress for group critique. Practically every day someone presents what they’ve been working on to gain an outside perspective. The teams at Pixar say dailies are a key contributor to the tight, high-quality films that the company is known for.

Both the SYM’s Chosen Ones and Pixar’s Dailies have evolved into well-honed sessions that produce great results. Taking a moment to peek into how they work can provide us with a ton of insights into how we can get the most from our own critiques.

The Importance of Ritual

Each of the several dozen SYM Chosen Ones sessions I attended was conducted the same way. Four kids would perform and before each performance the chapter’s vice president, a 15–16 year-old, would make a brief professional introduction. The audience would applaud and the performer would start their five-minute routine. Once completed and after the well-deserved rousing applause, the VP would return and ask for “Goods and Bads” — their code word for critique.

At this point, the kids in the audience would politely raise their hands and the VP would call on them to share what they liked and what questions they had about the performance. As each kid said something nice, the performer would thank them. The performer would address any questions and give thoughtful consideration to improvement ideas that emerged. Everyone in the room was soaking it in.

At the end, the senior adult advisors, many of whom are themselves famous professional magicians, would offer advice following the same goods and bads model the kids used. In many cases, they would just agree and amplify the advice that the other kids had already offered. Then the performer would thank everyone, step off the stage, and the process would repeat for the next child performer.

Having it work exactly the same way each time put the performers at ease. They knew exactly what to do and could concentrate first on their performance and then on the feedback they were receiving. It’s stressful enough presenting your work and getting the feedback without worrying about what’s next and how it comes together.

Separating Out 3 Roles: Presenter, Facilitator, Recorder

Giving the presenter a chance to show their work without being interrupted by a string of questions turns out to be pretty important. After seeing the Chosen Ones in action, I immediately noticed how, in my design reviews, disruptive interruptions can be. It throws the presenter off and doesn’t give them a chance to tell their story about the design and what they’re trying to accomplish.

There are four roles in any critique session. The two everyone’s most familiar with are the presenter and the audience (also sometimes called the critics). However, every session also needs a facilitator and a recorder.

Unfortunately, we often let the presenter also play the roles of facilitator and recorder. The wise kids at SYM let one of their own be the facilitator. (It was officially the VP’s job, but when that kid needed to perform, one of the other chapter officers would facilitate that meeting.)

Recording all the ideas coming in is important and really hard to do, even for seasoned adult presenters, when simultaneously trying to listen and take in ideas. Having another person record the group’s thoughts gives the presenter confidence that everything’s being recorded without needing to juggle listening with note-taking.

Goods and Bads: Affirmative & Constructive Criticism

By asking for Goods and Bads, the kids knew to start their feedback with a positive comment. We call this affirmative criticism and it’s critical to the great critique sessions.

Receiving a compliment delivers an endorphin rush. The presenter also hears what shouldn’t change or go away in future renditions of the work. In many ways, this is as important than knowing what needs changing. It forms a good design “root system” that everything else can grow from.

Knowing that one day they’d also be a chosen one, the kids would be very careful about how they worded their “bads.” They’d try to be very constructive, often forming a question, such as, “Did you intend for me to see that was my card before you flipped it over?” This gives the presenter a chance to think about what they intended to happen, versus what actually happened.

The subsequent discussion delved into fascinating nuance and subtlety about the work that everyone in the room learned something from. You can tell it’s a great critique when everyone’s learning something new, not only the person presenting the work.

The Work-in-Progress Sweet Spot: Being 25% to 75% Done

Pixar has an interesting rule for their dailies: the presented work should be at least 25% done and no more than 75% completed. It should be a solid work-in-progress.

When the work is less than 25% completed, it’s too early and most decisions haven’t been made yet. The session is too likely to turn into group brainstorming and design-by-committee, which everyone wants to avoid. (Brainstorming is great, but not in a daily, where the session is about receiving feedback on what’s been done so far.)

When the work is too close to completion, it’s hard to take in the criticism and feedback. At that point, there’s just not enough wiggle room for changes. Instead, Pixar wants to find their work-in-progress sweet spot — that place where the direction can change and new ideas are easy to take in.

Everyone’s Invited

Pixar opens their dailies up to anyone who wants to come. It’s not unheard of for someone from accounting to sit in on a review of an upcoming film’s art direction.

By being open, ideas emerge that are unconstrained by the thinking that’s already gone on. It also helps the presenter remember to bring out some of the early thinking and design rationale, thereby challenging and reaffirming they are still the right direction to take.

Subsequently, other departments at Pixar, including the business side, have started presenting their own work in dailies. It’s a great forum to get outside views and to help understand how you’ve gotten to this point.

Great Critique Doesn’t Happen By Accident

Critique is one of the most valuable tools a design team has. Careful thought and consideration on how it’s done is as important as doing it.

The lessons we can take from the kids at SYM and the animators at Pixar tell us we need to be thoughtful in how we run our own critiques. There’s a lot for us to learn from these guys and gals.

Originally published on UIE.com

Using daily critique as a strategy to make your company more design competitive is more than just a great idea, it’s one of our 130 proven strategies. During our 2-day Creating a UX Strategy Playbook workshop Jared assists a small group of attendees in creating their own unique UX strategy. He explains how critique plays a critical role in helping your organization become more design mature, which in turn helps deliver better products and services. Learn how Jared can help you and your team create your own unique UX strategy.

It’s a long game. Patience is key.

July 24, 2018

Jared talking with a design leader to help him build out his organization’s UX strategy.

Jared talking with a design leader to help him build out his organization’s UX strategy.

Practically every week, I find myself standing in front of design leaders saying the same thing: If at any point, I gave you the impression any of this would be easy, I apologize. It’s not.

Good design is hard. It’s even harder to establish a user experience strategy for producing great products and services.

We can make it easy to identify which strategies our organization would most benefit from. (In our Creating a UX Strategy Playbook workshop, teams do it in just 2 days.) However, putting those strategies into action and achieving the desired outcomes—that’s harder.

A solid UX strategy moves the needle in the organization. It pushes every decision influencer to be more design literate and fluent. Better informed decisions enhance a design’s user experience.

None of this happens overnight.

We can decide if a design system is a good UX strategy for us. However, we need time to craft a new design system, disseminate it, and get everyone using it. Plus, we don’t just need them using it. We need them using it well. That requires even more time and effort.

We can decide if more exposure to users and customers is a good UX strategy for us. However, putting a plan into play that gets developers, product managers, and other stakeholders in front of users takes time and effort.

Design leaders must have the patience to see each strategy through. Patience does not come naturally. Patience is a learned skill.

Any new UX strategy is a change. And the organization is resistant to change. Patience is the antidote to an organization’s natural resistance.

Starting with the end in mind.

Design leaders find patience by having a clear picture of where they’re trying to go. They know, from the moment they start executing a strategy, what they want that strategy to achieve. They know what the end game looks like.

They bring their team along. They make sure their team also knows what success looks like. Because the team has a clear picture of the objectives, they can see progress. They can make adjustments when progress starts to stall.

As with many things, balance is important. A design leader needs to know when to act. They must also have the patience to wait and allow a strategy to progress further. Sometimes, it’s in the moments after our intuition has told us to stop that we learn what we need to know to make things better.

As design leaders, we need the patience to see our strategies through. That’s how we deliver better-designed products and services.

Yes, Alan, There Is An ROI For UX Design

July 17, 2018

Alan Cooper recently wrote that the value of design should be obvious to everyone in the organization. If someone is asking you to explain design’s value, it’s because they can’t see it. He said:

“If your boss is asking you to quantify the value of your work, you need to understand that your work indeed has no value. Not at that company. Not with that boss.”

That was harsh. Alan goes on to suggest there are only two alternatives for this situation:

“So when your boss asks you “What is the value of your work?” you have only two valid courses of action: 1) Accept that you and your situation are a valueless combination; or B)[sic] Go some place where your work is valued. Go somewhere that doesn’t ask the value of your work, but instead values your work!

For me, this hit home. Back in 2011, I said something very similar. After explaining a couple ways to get stakeholder to start investing in UX, I suggest:

“…maybe it’s time for you to find someplace else to work. Someplace where the executives are already convinced and want to make the investment.”

“Go Somewhere Else” Is Privilege Talking

It’s been years since I originally wrote that. I now realize that’s a very privileged point-of-view. Not everyone is in a position to switch up jobs and move to a new job where the management appreciates design more.

While the demand for designers is currently the highest it’s ever been, it’s not evenly distributed. There are places where designers struggle to find opportunities. Walking away from their current job, no matter how unappreciated, may not be an option.

Alan’s recent post reminded me we need to talk about viable alternatives for those who need to stay where they are. It’s unfair for Alan or me — two middle-aged white dudes — to tell others finding a new job is their only option.

Not All Design Work Has Value

I think Alan is correct when he says some design work produces no value. A designer could feel that just by tweaking colors, cleaning up typography, or making a set of screens look consistent, they are making a design better.

But just making a design feel better doesn’t mean it’s more valuable to the customer or user. It may be designing for design’s sake.

That said, I don’t think Alan is correct when he suggests that when someone is questioning the value of design, it’s always because the design work has no value. It might be because the value hasn’t been discovered. Not all value is obvious.

Not All Valuable Design Work Is Of Equal Value

The value that comes from good design is incremental. Thousands of small decisions, thoughtfully made, with a focus on the users’ experience is what makes design valuable.

Not all design decisions have the same value. For example, in the initial release of a recent new design tool, the design team didn’t include a way to store work files in folders. Every designer’s files needed to be in the same collection with everyone else’s, with no way to divide up the work by project or design portion. This wasn’t an issue for small projects, but designers using the tool for large projects found the missing folder functionality frustrating.

In user interviews, no designer would tell you that folder support is a feature they’d pay extra for. Yet, when it was left out, it devalued the design tool. Several of their early adopters gave up using the tool because they couldn’t make it work well for their projects.

Someone on the product team decided to leave that functionality out. There’s any number of reason why that might have happened.

They might’ve run out of time or decided it wasn’t necessary. It might not have been part of a bigger decision to focus on the design-related functionality and not the file storage capability. Maybe they didn’t think of it at all.

By leaving out the folder functionality, they missed a basic expectation for many of their users. Adding it back in is valuable. Is it as valuable as, for example, a feature that could cut hours out of building animations? Not all valuable design work is of equal value.

In UX Design, ROI Is Often About Eliminating Poor Design

Return on investment isn’t as complicated as everyone makes it out to be. It can feel difficult to calculate, but that’s because we often look in the wrong places. Not because it requires some fancy financial wizardry.

For UX Design, ROI is about finding an improvement to the organization’s bottom line. (“Bottom line” refers to the design of a Profit and Loss Sheet, a standard finance tool where the organization lists all of the money coming in and all the money going out over a time period. The bottom line is the report’s last line, where we subtract the total expenses from the total income. When we improve the bottom line, we’re making the organization more profitable.)

The obvious place designers go when trying to calculate the bottom line is to ask the question, If I change the design, how much more income could we generate? But there’s another way design can help: reducing the costs.

A much-overlooked portion of design’s value is that poor design is very costly to an organization. Poor design generates costly support calls. It causes lost sales or dropped subscriptions. Poor design can increase development costs through rework and waste.

When we start looking for where poor design hurts our organization, we can talk about how much money we’d save. We make it easier to calculate the return to our investment for making better design decisions. (If this intrigues you, I wrote more about this in A Proven Method For Showing The Value of Good UX.)

Design Leaders Know Poor Design’s Cost To Their Organization

This is why I disagree when Alan says your design has no value if your boss asks you about it. I believe your boss might be asking you about the value of design because they think of you as a potential design leader.

If you are reading this, it’s very likely you either are a design leader or will become one soon. One responsibility of a design leader is to demonstrate the value of design to the organization.

It’s likely your boss wants to help you make the products or services better but hasn’t learned how to describe it’s value yet. They’re looking to you to help make that case. They’re looking for you to be the leader your organization needs.

A design leader is ready when their organization comes asking about value. That means researching where poor design costs your organization money.

If it’s a big enough amount of money, you don’t even need precise numbers. Sometimes, it’s good enough to just point to large pain the organization is feeling.

For example, say you get many support calls because the design doesn’t do something the users expect. That’s a high cost due to a poor design decision. If it’s easy, you could ballpark a number. (Number of calls x average support call cost.) You may not need the math if everyone agrees that’s likely expensive. High value doesn’t always need to be quantified; it just needs to be seen.

Design Leaders Promote The Value of Good Design

A design leader finds where poor design is costing the organization money and pain. They start documenting it and put together ideas around what the design team could do differently to reduce those costs.

When the boss comes to ask, the design leader will be ready with answers for them. They can tell their boss which poor designs cost their organization and how they believe they could fix it.

Good ROI happens when the cost of fixing a problem is less than the ongoing costs of letting the problem continue. By having a ready plan, they’ll have the perfect starting point to discuss the ROI of design.

However, here’s the trick: smart design leaders don’t wait until their boss asks them. Smart design leaders are pointing out costs and how good design would reduce them before their boss even thinks to ask. When they can, smart design leaders start decreasing costs without being asked at all.

Smart design leaders prove the value of good design in advance of being asked. Their bosses don’t ask what design’s value is, because they already see why the organization should invest in it. They’ll know why they are investing in the design leader.

Smart design leaders aren’t in the position Alan describes, where their only options are to stay somewhere that doesn’t understand the value or leave for another place that does. They’re right where they should be. Providing value to their organization by doing the right thing.

Originally published on UIE.com

Uncovering and promoting the value design brings to your organization is a major topic we discuss during the Creating a UX Strategy Playbook workshop. We look at proven strategies for showing design’s contribution to everyone in the organization, and how this contributes to making the organization more design mature. Explore how your team can surface your design’s value within your organization.

The Redesign of the Design Process

July 13, 2018

It wasn’t that long ago that we believed in a romanticized notion of the power of the talented solo designer. This individual would lean back in their chair as everyone else would await the genius idea that would emerge. “Yes! That’s it. That’s what we need to build. Thanks again, Awesome Designer. You’ve made us great again.”

It doesn’t work that way anymore. And actually, it’s clear it never did.

Today, the best designs aren’t coming from a single designer who somehow produces an amazing solution. The best designs are coming from teams that work together as a unit, marching towards a commonly held vision, and always building a new understanding of the problem.

These teams create their great designs without using any magic or special formula. They create great designs by applying their design skills to the act of designing.

Rendering Intent About Rendering Intent

Design, in its simplest form, is about rendering intent. When a person makes a choice about how they want something to be, they are designing.

Do we want the glasses in the cabinet above the sink because they’d be easier to reach? Yes. We just designed the kitchen layout. We intended easier access to common items in the kitchen and we rendered that intention by placing the glasses in that cabinet.

If we intend to create great designs, how will we render that intention? That’s the role of a design process.

In our research, the teams that produce the best designs, have a process that’s geared towards forming a common understanding. That understanding needs to cover the problem they’re trying to solve, the users they’re solving it for, and the gamut of approaches they can use to get there.

Innovative designs don’t happen because of a single smart person who drives everything the team does. Innovation happens when the team creates an environment where small, powerful ideas can float to the top.

The process that a team needs to create great designs doesn’t just happen. It needs to be intentionally rendered. It needs to be designed.

What Does the User Research Say?

We all know user research tells us about our users, what they are trying to accomplish, and how they succeed or fail with our designs (and competitive approaches). Many teams now regularly conduct user research. However, the best teams design how that research fits into their process.

It’s easy to throw together a usability test. (Well, relatively easy. It’s still too difficult to do it well, but that’s a discussion for another day.) It’s almost as easy to do a quick-and-dirty customer visit.

Executing user research is a well-understood process. Integrating user research effectively into the design process is something many teams fail at. The best teams are quite intentional about their process of fitting what they’ve learned into what they already understand.

The user researcher’s role has changed. It used to be about running studies. Now it’s about growing the team’s understanding of their users.

In this new role, the user researcher still needs to run a high-quality study. However, the real emphasis is to truly understand what the team thinks about their users. Then, using their well-adapted toolbox of user research techniques, they identify where that thinking is faulty. In time, a great UX researcher guides the team to a more accurate understanding of the user, which means design innovations are more likely to emerge.

Designing the Design Meeting

Another archetypal process moment: We need to find out what the design should be. We do that by holding a meeting.

It’s not just an efficiency that drives us to collect all the key players and stakeholders into a conference room to discuss what the design should be and where it should go. It’s because there’s a lot of potential to have a group of smart, talented, and experienced people share their different perspectives.

Yet most teams rarely go beyond crafting the list of attendees and a collection of agenda items. Then they complain when the meeting falls flat and is a waste.

The best teams use these meeting opportunities to exercise their design skills. They think about what they intend the experience of the meeting to be in order to get the best results. They then design the meeting for that intention.

Take the act of recording the notes. In most meetings, people bring a notebook and scratch key ideas. Objective, revelations, assignments, and deadlines are spoken, but no-one is ensuring they’ve all been captured.

The best teams solve this creatively. While it’s not uncommon to designate an official note taker, it is uncommon for them to display the notes they are taking publicly, for everyone to see as the meeting progresses. Yet this technique ensures that everyone sees what’s being captured.

Multiple positive effects emerge from designing a public note-taking process for important meetings. People in the room see which points are worthy of recording, thus cementing their importance in everyone’s mind. Participants who feel their point of view wasn’t accurately recorded get another chance to clarify where they’re coming from. The notes end up having a longer lifespan and better cement the team’s understanding of the project’s objective.

Designing useful meetings has huge implications for the team. It means they need to think of their own experiences as something they have to design for. They need to collect successful “patterns” of meeting activities, just like they’d collect up interaction patterns for their designs, so they have a full toolbox of ways to make the meetings über-productive. Meeting facilitation is now a core skill for successful designers.

Team Experimentation, the Lean UX Way

Projects usually start by listing out the team’s assumptions. However, they aren’t always labeled as ‘assumptions.’ Instead, they are often labeled as ‘requirements.’

Even worse, these ‘requirements’ aren’t ever questioned or tested. Validation is considered harmful to the project.

The result is even more assumptions get built upon these assumptions. And soon we have a house of cards that defines the entire project. No wonder we’re surprised when it collapses upon first contact with the users, after incurring great expenditures.

Lean UX has shown up at the right time. Our world is already under a shift because of the move to more agile development processes, and thus we’re open to new ways to approach the design process. Lean UX presents itself as a shortened upfront design approach that fits with agile thinking. Yet that’s just a ruse.

The (not-so-)hidden agenda of Lean UX is to redesign the upfront assumption process. Using experimentation, we test the assumptions and requirements to discover their validity, when it’s cheapest to do so.

The best teams approach Lean UX incrementally, testing their own hypothesis on how a design process should best suit their needs. They measure and adapt their process over time, with the goal of making it better in each iteration.

Expanding the Design Vocabulary Through Critique

Another ruse is the critique. On the surface, we tell the team that we’ll use critique to collect feedback on a few design ideas and approaches. But that’s not all that’s happening.

Frequent, well-executed critiques are growing the team’s design vocabulary. The best teams critique current design approaches, future possibilities, competitor’s designs, and even ideas they find in the wild.

With each critique, the team engages in a conversation about what makes great design and what is undesirable. That ongoing conversation strengthens their vocabulary. Fuzzy concepts become clearer. Principles become stronger.

This new vocabulary surfaces when the team members return to their work. They start to become more intentional about increasingly subtle and nuanced characteristics in their design. A coherence emerges across the entire team.

A strong design vocabulary is key to producing great work. Embedding critique as a regular activity in the design process ensures the vocabulary is constantly growing stronger.

Attaining a Collaborative Shared Understanding

July 2, 2018

For a design, it’s a long journey from the first idea through the final implementation, involving many people along the way. Ensuring each person shares the same understanding about how that design should turn out is one of the biggest challenges we face.

I remember seeing an architect who talked about his best projects. When he walked through the finished building for the first time, he said it felt completely familiar because it matched exactly what he’d imagined years before. His intention had made it all the way through the implementation process.

Seeing our designs rendered exactly as we imagined them is exciting. It’s frustrating when our designs aren’t implemented the way we were thinking.

As we study what makes design teams successful, shared understanding keeps bubbling up to the top of our list. Teams that attain a shared understanding are far more likely to get a great design than those teams who fail to develop a common perception of the project’s goals and outcome.

While this seems obvious, many design processes don’t have an explicit goal of developing and maintaining a shared understanding. It’s almost as if the team members assume it will happen. Often just pointing this out to the team can cause change, at least temporarily. (It’s easy to fall back into old habits if you’re not careful.)

Even when the team has a goal of attaining a shared understanding, we’ve found there are two opposing approaches, which we call contractual understanding and collaborative understanding.

Contractual Shared Understanding

For many years, user experience designers relied on wireframes, design guidelines, and user interface specifications to express their intention. They created these thick, mind-deadening tomes with the intention of communicating every little design detail.

The point of these documents is to separate out the design portion from the implementation, creating a recipe, as it were, to be cooked. The more specific the recipe, the more likely the dish turns out correctly.

These documents become the contract between the design and implementation teams. The designers say what they want, and the implementors agree to deliver that. It’s a negotiated process, resulting in what everyone would like to believe is a rock-solid agreement.

The contractual approach has a huge advantage when it comes to predicting the design result and estimating the work involved. Experienced developers can accurately budget the cost and schedule the activities for every element in the specification. Management is happy because they know what to expect and when to expect it.

Unfortunately, lawyer-like precision comes at a price. First, documents like these take a long time to create. Though modern tools let us produce specifications faster than ever, with graphical annotations that make it simpler to explain the subtleties of the design, the result still takes time. Nailing every detail across the design is hard.

Leaving a detail open to interpretation causes the potential for a mismatch between the design team’s intentions and the implementation team’s results. Teams choosing the contractual understanding approach learn to increase specificity, which slows down how fast they can produce new features and ideas.

Additionally, a static document for an interactive experience is substandard. We’re using words to express behavior—something that’s very difficult. Talking about design is like performing an interpretive dance about architecture.

Another big problem with the contractual approach is its inflexibility to adapt to anything that pops up once the design is committed and agreed upon. If something changes in the environment or the team learns something new about the constraints or needs of the users, it’s hard to retrofit the documents and go through the agreement process again.

With the contractual approach, there are three possible outcomes to the implemented design. Ideally, the design works great for the user. Alternatively, it doesn’t work because the implementers didn’t follow the contracts correctly. Or it doesn’t work because, even though it was implemented perfectly, it was the wrong design for the users’ objectives. It’s the latter two outcomes we see most often due to the inflexibility of this approach.

Collaborative Shared Understanding

Contracts are about the letter, not the spirit. In a collaborative approach to shared understanding, you focus much more on the spirit of what the team intends.

Here the techniques are not about documentation and agreement. They are about exploration, experimentation, and, dare we say, enlightenment. What we’re trying to do is get to a point where we have an epiphany about the design—a revelation that makes everything clear.

We can see this emerge in two techniques of collaboration: prototyping and paired design.


In prototyping, we take ideas and render them, bringing the concepts to the forefront with the baggage of detailed implementation. The simplest form of prototyping is the sketch. Whether on paper or a whiteboard, an animated discussion in front of a sketch brings new life to ideas. In some ways, the scrawls summon spirits into the room that give everyone a deeper understanding.

For years, we taught teams how to use paper prototyping. With the entire team around the design, a user can move through tasks and activities. We love this technique for interaction design because so much of the subtleties of interaction can emerge in the representations of paper.

And it’s fast. Really fast. Working together, a team can create a complicated set of interactions in mere minutes.

This means the entire team, not just the skilled designers contribute to the construction. There’s something about tactile manipulation that speeds understanding, so the act of building the paper prototype contributes to the shared understanding almost as much as seeing the final prototype in action.

Paired Design

With the advent of easy-to-use front-end components, JavaScript libraries, web application frameworks, and prototyping applications teams can quickly render working digital versions of their ideas. Even clickable PDFs give a sense of reality that helps the team understand what they are trying to build.

While pre-made plugins and built-in operators make many interactions easy to produce, sometimes it takes advanced programming skills to see how a complex interaction will really work. This is where paired design comes in.

In paired design, a designer is paired up with a developer. They sit together and work on the design in parallel. The designer is constantly showing sketches to the developer, who is working quickly to realize those ideas in code. The code is messy and not at all the quality necessary for release, but does the job of getting the ideas in front of everyone.

The result of paired design is a level of communication about the intention that goes beyond what shows up in the prototype. Later, when the developer is working on details without the designer, they’ll have enough understanding of the spirit of the design to make great decisions.

There are two big downsides to the collaborative approach of shared understanding. First, it’s hard to predict what will be built and how long it will take, due to the iterative nature of the design process. Teams used to the clean estimation process of a contractual approach have trouble transitioning to a collaborative approach when they can’t easily estimate resources and costs. (For some business models, like agency-based design where a price needs to be established with the client up front, this makes a collaborative almost impossible.)

Second, the collaborative approach is intensely intimate over a long period of time. For it to be successful, designers and developers need to work in close quarters, surrounding themselves with the work in progress. This is very hard for remote teams who don’t have the luxury of being co-located for the duration of the project.

Right now, our research shows that, despite these constraints, it’s easier to produce great designs using a collaborative approach to attain shared understanding. If you really want to produce great designs, structuring your teams to work in this fashion, paying close attention to what everyone understands, is the best way to get there.

Originally published on UIE.com

Creating a design squad to build demo prototypes and pairing designers with developers are two of different strategies we discuss in our Creating A UX Strategy Playbook workshop. Learn how to bring your teams together with strategies picked specifically for your organization.

Join us for our 2-day workshop and help bring shared understanding to your team, problems, and designs. Look over our 2-day workshop agenda at Playbook.UIE.com.

Critique: The Secret to Growing Your UX Team Skills

June 28, 2018

I get emails several times a week like this one: A manager asks me to come in and train her design team on UX skills. I respond to her and suggest we have a discussion about it.

During this discussion with the manager, I realize conventional classroom UX training won’t help her team. It would be easy for us to sell her a course, as that’s exactly what she’d like me to do. However, it would be a waste of her money and, in good faith, we can’t do that.

Yet her team does need to learn more about user experience design. They are struggling with design challenges that exceed their knowledge and expertise. She tells me the team doesn’t have a common language to talk about design and it gets in the way of problem-solving.

It’s clear her company’s future success depends on solving those problems. Even though training seems like the obvious solution, my experience tells me it won’t work here.

Training Options for Teams with Varied Skill Levels

This organization, with 1000+ developers, has built a UX team of 65 folks. Some are senior designers and user researchers. Others are much newer with only a small amount of experience behind them. There are even folks who have joined the UX team from other parts of the organization, never having done any UX work before.

The team is completely varied in their skill levels. Some have great experience and knowledge in interaction design, while others aren’t aware of basic design patterns. Some are super information architects, while others barely know about card sorting. Any training would need to take all these different levels into account. If the team were to set up training, there are several ways they could structure it.

They could have an outside organization (like ours) come in and teach a course with the entire team. Because the team’s skills are so varied, it would be hard for the trainers to provide the necessary foundational training without boring the more senior team members.

Of course, they could somehow train only those folks who are missing the skills. But an outside organization would bring their own dialect of the language of design that wouldn’t be exposed to the team’s senior members. Those trained will speak a different language than those who aren’t.

Another alternative is to train the team’s senior members to teach their own classes. This would solve the dialect problem (and possibly be less boring), but it’s a lot of work to build and teach classes. And it could be reinforcing some bad habits that the senior members have. Plus, as the team grows, this would have to be a continual effort.

To make it even more complex, at this team’s company (as is common among lots of companies), the UX cadre is distributed across time zones and project teams. It’s logistically complicated to get them all together for regular training.

Finally, the people who belong to the UX team aren’t the only folks in the organization who need training in user experience design. Almost everyone they work with could use some level of training. Everyone could use a common vocabulary and literacy about what makes a design good for the users.

Any solution to the training problem has to involve everyone who influences the design. It can’t interrupt the daily project work—it needs to help move it forward. It has to engage everyone intellectually and adapt to changing demands of the organization.

There’s one technique that’s rarely thought of as an educational technique, except that’s exactly what it is. That technique is critique.

Shifting Critique from Design Feedback to Design Exploration

Critique is when a group of folks get together to discuss a specific designer’s work. Often, the designer presents their work, then solicits affirmative and constructive criticism about that work.

When I talk to folks, they see critique as an advanced form of design review. They gather in a room and give feedback on how to improve the design. It can be a harsh environment for the person who did the work, having to project a thick skin as everyone’s opinions come rushing by.

However, when done well, critique won’t be like that at all. The critique session can be an educational experience, exploring the designer’s work and what it means in a bigger picture.

These teams don’t approach critique as, “What feedback can we give this designer about their work?” Instead, the team members see critique as, “What can each of us learn from the work this designer has done?” Everyone walks out of the session with new knowledge and perspective about their designs.

Focus is Key

I recently participated in a critique where the team decided to focus the session on the design’s information architecture. The designer, who knew up front this would be the focus, started by presenting his IA goals for the project. He talked about the users, what their objectives were with the IA, and then showed us variations he’d come up with for the design. He talked about design principles he was focusing on and alternatives.

All the while, the team members in the room, some of whom were themselves quite knowledgeable and experienced about information architecture, asked him questions about his choices and thought processes. The session’s facilitator also made sure those in the room who weren’t as experienced had an opportunity to ask their questions and get informative responses.

The session hit a lot of tangents and a few digressions, but the facilitator did a great job of bringing us back to focusing on the information architecture. By the end of the session, the team explained complex concepts. New terminology emerged. The designer, who was fairly junior in the organization, confirmed they’d done a good job on the design, and left the session with some alternative ideas to explore.

Because the team agreed up front to focus this critique on the information architecture, everyone was prepared. And everyone learned a ton, which was reflected in future conversations the team had about the design.

Lenses of Learning

Information architecture isn’t the only thing the team can learn about in a critique. They can explore any aspect of the design or the design process, and should. Here are some of the different lenses that teams use critique to explore:

Design Concepts: All the different aspects of design, from visual design to copywriting, information design to interaction design. Holding a critique to talk about options for typography or grid layouts, or another one for discussing microcopy and form field labels would develop literacy in those topics.

The Design Itself: What are we trying to build? Are the flows through the design the right way to approach the problem? Have we arrived at the guiding principles that will make this design successful?

Design Systems: Is this design part of a large suite of designs? Are we evolving a design system that we can use in other places? Are we exploring the systems that are out there (such as Google’s new Material design system)?

Who the Users Are: What do we know about our users? What makes them distinct from non-users? What are the different personas we’re designing for? What are the common scenarios for each of those personas? How does this design match those scenarios? What are alternative ways to design for these personas and scenarios?

Business Needs: What are the explicit and implicit goals of the business? Have we designed for the immediate short-term needs? Have we ensured our design could last for the longer term?

Constraints (Technological and otherwise): What constraints will we run up against? What happens to the design when it’s at its most degraded (simple devices without capabilities like JavaScript, for example)? Have we explored the different progressive enhancement options?

Team Process & Collaboration: How are we working as a team? What are alternatives to our workflow? Where are we spending time that’s not getting us closer to a better design?

Critique Process: Are we learning everything we can from these critique sessions? Are the right people in the room? What alternative techniques could we use to be more effective at learning?

Each critique can focus on one or more of these lenses. Ideally, the team decides on the lens before scheduling the critique and starting the work. Teams that go into each critique session knowing what they want to learn are more likely to get the most out of each session, coming away energized and excited.

Separating Critique from Design Reviews

Design reviews are a necessary part of the process. Reviews determine if a design is ready to move to the next phase. Does it need more work or should you abandon it for another approach?

A common mistake we see is when teams combine design reviews with critique. They use the review session to offer constructive or affirmative feedback on the design.

This combination can strip the critique of its educational value because everyone is focused on making deadlines and meeting project objectives. Keeping the critique independent of the review sessions preserves the educational objective. It helps each team member think about the design work as a chance to learn and gives the designers a chance to take more risks with their work.

Critique and the Growth of Your UX Team

Regular critique, whether formal or ad-hoc, ramps up team members’ skills quickly. By changing up what the focus of learning is for each session, the team ensures that everyone’s skills become more well rounded. A vocabulary for design emerges and principles evolve.

Critique is a great way to get smarter about design, which in turn, helps the organization become more design-focused. As more people are brought into the critique process, such as product managers, stakeholders, content providers, and executives, teams see an organization-wide appreciation for the hard work of design and the outcomes it can produce. It’s the most effective way we’ve found for continual education and growth of the team.

Building An Experience Vision From A Journey Map

June 21, 2018

The task of coming up with a long-term vision of your design can be a daunting one. It’s a lot of responsibility to imagine what an ideal experience can be, then render a possible design to achieve that experience.

However, there’s a way to break this task into bite-sized bits. By doing that, a vision emerges from a series of smaller, um, shall we call them, visionettes.

Here’s how teams we’ve worked with have done it:

Step 1: The team observes participants as they use current solutions to a problem they have. Those solutions could include the product’s existing design. Those solutions could also include other tools and processes available to participants. As the team members observe, they note the order of steps the participant takes and whether the participant finds each step frustrating or delightful.

Step 2: The team creates a journey map that shows the experience of each study participant. One approach is to use a horizontal timeline with milestones that represent each step. The team measures frustration and delight on the map using a vertical timeline. The higher the point on the timeline, the less frustration and more delight the participant had at that point.

The resulting map shows the current experience for that participant. The team creates a different map for each study participant and looks for patterns that emerge.

Step 3: The team draws an archetypal journey map—one for a persona that represents the patterns they’ve observed across participants. (When they create more than one archetypal map, they now have multiple personas for their design. This isn’t necessary, but it can provide some interesting insights, especially if the activities vary widely.)

An abstract map of the current experience and the aspirational experience

An abstract map of the current experience and the aspirational experience

Step 4: The team studies the archetypal journey map for frustrating dips in the experience. They discuss: What could we do to make each of these better? Can we change the design to be more delightful? Is there a way to eliminate the step altogether?

By reviewing the unique points of frustration across the archetypal journey map, the team gets a jumpstart on what their overall vision might be. It’s easy to take a complex series of interactions and imagine a cleaned-up version. When they do that two or three more times, they start to see a better experience that flows more smoothly.

By focusing on all the low bits in the design, the team has a good starting point for a future vision that is a more delightful experience.

Creating a compelling experience vision is a powerful tool for design leaders. The story of a better user or customer experience helps the entire organization appreciate the value of great design. In our Creating A UX Strategy Playbook workshop, we explore a variety of UX strategies that will show your organization why great design makes a difference. See what hundreds of design leaders have already learned.

The 3 Steps for Creating an Experience Vision

June 14, 2018

The team was happy to be together. Forty-six folks from eight different offices, traveling from all over the world, had come together for their annual meeting.

They were excited to be there. It was good to see faces of people who were often just an email address or voice on a conference call. It was nice to reflect on all the great things they’d accomplished.

Over the past 3 years, the team worked diligently on server reliability, eliminating dead links, and consistent navigation and branding across all 200 of the sub-sites. They’d installed a new enterprise-wide content management system, a better process for editorial work, and new application tools to help their franchise owners sell more high-margin products. By all measures, the website had become a critical element in their multinational business.

However, there was still an unsettled tone amongst the group. Given all the progress they’d made, they felt they still had a long way to go. They weren’t sure what the next step was.

Overcoming Lip Service to Users

“Users are our first priority,” is the executive team’s battle cry. Yet, when the priorities came down from above, they seemed to focus on business unit needs and technology solutions. Somewhere, in all those priorities, the first priority got lost.

It wasn’t that the team wanted to ignore the users. It’s just the demands of the business units they served, and the constraints from IT made serving the users take a back seat. In the day-to-day hustle-and-bustle, the long-term perspective gets lost.

When the long-term perspective vanishes, it becomes difficult to feel like you’ve made any significant progress. Sure, you’ll have checked many items off the ever-growing to-do list, but have you really improved how the business serves its customers?

To solve this, many teams are turning to an old tool: creating an experience vision.

The Flag in the Sand

When you create an experience vision, you try to mentally picture what the experience of using your design will be like at some point in the future. As we conduct our research exploring best practices for experience design, we’ve discovered that nearly every successful team has actively created an experience vision that they frequently refer to. Often their visions are for experiences five or ten years in the future.

These visions act like a flag stuck into the sand somewhere on the horizon. The team can clearly see the flag, yet it’s far enough away that they won’t reach it any time soon. Because the flag is clearly visible, the team knows if every step they take brings them closer or farther away. If the flag weren’t visible, the team wouldn’t know and could wander off in an undesirable direction.

Having a clear vision helps the team understand if changes are moving them in the right direction or not. Occasionally, due to pressing business needs, a design change is going to move the team away from the vision. However, if everyone understands the vision, they’ll know when this is happening and can act to correct it. More often, choices are available and the team can choose the option which best serves the experience vision.

The experience visions of the successful teams all have the following qualities:

  • They are research-based
  • They focus on the users’ experience
  • They are shared across the entire team

Step 1: Focus on Research

A few of the organizations we’ve studied have one or two people at the top of the organization that just know what the vision should be. One company that immediately comes to mind is Apple, who had Steve Jobs and Jonathan Ive as their visionaries. Apple’s success with its products come directly from the visions that Steve and Jonathan handed down.

However, most organizations don’t have a visionary at the top of the organization. These organizations need to get their inspiration from someplace else.

When no visionary is present, most teams find their inspiration from in-depth research of latent user needs and desires. Latent needs are things users can’t elaborate on their own because they don’t know what’s possible. For example, few people would’ve told researchers they wanted home-delivered DVDs. However, through careful research, the team at Netflix saw how miserable many people were with the video store experience and created a solution that would catapult their business to the head of video rental industry. They repeated this when they launched into streaming.

Research techniques, such as field studies, give us the foundations of what the current experience is like. We can see what’s working and where people’s experiences are less than desirable.

The techniques also show the latent needs and desires. We can compile the latent needs and desires into an ideal experience. The best ideal experience eliminates frustration and instills delight. This becomes the foundation of our vision.

The space between the current experience and the ideal experience is where the insights come from. Innovation happens here.

Step 2: Focus on Experience

A common trap is to focus only on technological innovation, but this would be a mistake since technology changes over time. Predicting new technology five years out will be near impossible.

The best teams ensure they focus on the experience of the user, divorced from the underlying technology. The vision talks about how users experience the product or service. Experiences don’t change quickly and make for a better long-term target.

Because the team is focusing on experience, it goes beyond the pure technology touch points. A vision for an online book community, for example, would go beyond the specific online activities and must include reading the book and offline discussions about the books. A high-quality vision integrates all the instances when the elements of the designs are part of the user’s experience, not just when they’re interacting with the specific product or service.

Step 3: Share the Vision

Having the vision exist only in the head of one or two people doesn’t help the team know how to make important decisions. The vision must be shared throughout the organization.

The successful teams make sure everyone making decisions is aware of the vision. Not only does this include the primary design agents, such as designers and developers, but also the indirect design agents, such as customer service, manufacturing, and even the legal team. Since some of the user’s experience happens when they are away from the design, other organization entities will have an impact. The indirect design agents are forming elements of the experience often as much as the design does.

There are many techniques for sharing the vision. We’ve seen everything from video reenactments to comic strips. They all have two things in common:

  1. The technology is downplayed keeping the focus on what the user is experiencing.
  2. The team shares the vision frequently, not relying on a single presentation or document to make it permanently sink in.

Validating Activities Against the Vision

Once the vision is shared throughout the team, a culture needs to evolve where the team is constantly validating all their activities against it. This is where they tell if the steps are leading towards the flag or away from it.

Visions are reached through baby steps—the hundreds or thousands of little, incremental changes to the design. As the team takes on each change, they need to ask, “Is this getting us closer to our vision?” Often, the discussion that follows this inquiry is as informative as the original vision discussion. You can learn a lot by testing each project this way.

If a particular change is taking away from the vision, the team needs to decide if they should go ahead anyway. Sometimes, you have to take a step backward to eventually make leaps forward.

In other instances, you may discover the vision isn’t quite right and needs adjusting. Remember, we stuck the flag in the sand because it would be easy to move if we had to do it. If you need to change your vision, just remember to make sure everyone knows about it (and why.)

If you don’t know where you’re trying to get to, the odds of getting there are slim. Having a solid vision that everyone shares will help you feel that you’re working towards something important, even with the busiest of organizations.

Originally published on UIE.com.

· · ·

Creating an experience vision is one of the strategies we discuss in our Creating A UX Strategy Playbook workshop. In this two-day workshop, we explore dozens of strategies successful UX design leaders have employed to keep their organizations focused on the users. You can learn more about the workshop, what you’ll learn, how much it costs, and where you can attend at Playbook.uie.com.

Promise, Vision, Scenario, and User Stories

June 8, 2018

People like to share their stories with me. Lately, many of these stories have been about their experiences on recent United Airlines flights. I’ve become a bit of a magnet for United Airlines stories.

Most of these stories are about how the airline failed them in some way. In their minds, they weren’t asking for much.

They wanted their flight to go exactly as the airline had promised. Yet, for whatever reason, it had gone awry. And then, due to issues that seem to be endemic inside the airline, it got worse. The outcome was frustration and disappointment.

Yet sometimes the stories have a happy ending. Frequently these stories start with something that went wrong, but then a helpful employee takes the reins and goes above and beyond. The problem isn’t just resolved, the employee treats the passengers great, and everything ends well.

These stories are about promises. Promises broken and promises exceeded.

If you listen closely to the stories, you can hear the underlying user experience interactions. You can hear where those interactions went well and where they failed. Promises can be the key to how you deliver better products and services.

We Can Design Our Users’ Promise Stories

If you speak with an Uber customer, they frequently have a glowingly positive story to tell. They talk about how simple it is to get a car. How easy it is when the trip is automatically charged to their credit card. How much nicer the ride is than a taxi, and how it’s often the same price or less.

This isn’t an accident. The Uber team has carefully designed the rider experience: The way the app works and the system that handles the payment. All of that was designed as an explicit experience. The Uber team made an intentional promise about great service, then designed every aspect of the system to fulfill that promise.

United Airlines’ promise stories are also designed, but not like Uber. Often, they are what we call an unintentional design. Unintentional design happens when the organization focuses on the business or the technology, but doesn’t focus on the customer or user experience. The result is an experience that emerges that often isn’t pleasant.

As an organization, we can choose if we want to be more like Uber or United Airlines. We can choose the promises our customers talk about and design the stories they’ll tell.

Promise Stories Represent the User’s Perspective

The promise story is what a user tells a friend. It focuses on their perspective of what happened. For a banking customer, that story might sound something like this:

“When I was young, I opened my first bank account. I’ve had it ever since. When I got my first job, I had my pay directly deposited into it. I remember it being easy to set up.

The bank figured out how much my regular expenses were and kept telling me how much money I could save, if I was good and didn’t act crazy with money. So I started following the bank’s advice and soon I had a pretty big savings.

When my kid was born, I told the bank I wanted to use that money for college. They told me how much I needed to save each week from my pay. Every time I’d spend more than I should, the bank would tell me, and I’d stop.

Now my kid is about to graduate from high school and just got accepted to a great college. Thanks to following the bank’s suggestion, I’ve got enough money to pay for her education. My daughter will be the first person in our family to go to college. I’m so proud of her and excited that I can afford it.”

While the storyteller doesn’t say specifically how the banking software was designed, it’s easy to imagine an interface that would fulfill the important elements of the story. That’s when the vision story comes into play.

Vision Stories Show How We’ll Deliver on the Promise Story

A vision story describes the experience the user has as it happens. Whereas the promise is what the user tells their friend after the experience, the vision is about the experience proper, or an important piece of it.

Here’s a vision story demonstrating the experience of how the system coaches the user on good financial practices:

“Soon after our banking customer, Mary, had her baby, she decided she wanted to start saving for her daughter’s college education. She went to the bank’s economic calculator to estimate the cost of tuition. This gave her the goal to achieve.

The bank set up a savings plan for her, using her history of direct-deposit income and fixed household expenses. Adjusting for the new expenses incurred with a new baby in the household, the bank system identified how much spending money she’d have each month after putting the college money aside.

It would be tight, but she could do it. As each month progressed, the bank system tracked her income and expenses. When her projected spending money started to get low, the system sent Mary a warning. There were a few months where she didn’t quite save as much as she would’ve liked, but most months she was putting aside enough money to keep her on track. The financial advice the system gave Mary was helpful and on point.

When her daughter graduated from high school, Mary had managed to save enough money for tuition at a good school. Mary found the system encouraging and optimistic. She was happy and proud to have saved the money.”

The vision story tells one way the design could deliver the promise story’s experience. The combination of the two are a powerful high-level view of whythe team is building this design. As the team faces design decisions, they can ask which alternative will get them closer to their vision and promise stories.

Scenarios Provide Context for Designing the Promise and Vision

When the team researches their personas and collects scenarios for various users, they can frame those scenarios within the perspective provided by their vision story. The scenarios flesh out details needed to ensure all the little details that go into a great design are incorporated into their design.

Using their research, the banking system team might decide to focus on a persona, Dianne, who is a single mother living in a small apartment and works as an paralegal in a large law firm. The team would provide essential details, like her income, rent, and other fixed expenses. They’d also identify the expenses common with having a new baby.

Using this information as their basis, they could create a series of scenarios from the vision story. One scenario might describe the moment when Dianne decides to start saving for her newborn’s college expenses. Another scenario could describe a month when Dianne’s expenses are high enough that they start encroaching on her savings plan. A third scenario could describe how Dianne might use the financial calculators to make adjustments to her savings plan.

Each scenario ties directly back to the vision story, which, in turn, ties directly to the promise story. When the team starts working on features or design elements that fall outside of the existing scenarios, they can use the vision story to guide them back. (Or, if necessary, they can adjust the vision story to incorporate the new features.)

User Stories Connect Design to Development

The promise, vision, and scenario stories set the groundwork for developing a cohesive set of user stories. User stories are how Agile development teams choose what to focus on with in their sprints. They dictate what will get built.

Many teams use a similar format for their user stories: “As a <⁠role⁠>, I want to <⁠activity⁠>, so I can <⁠outcome⁠>.” These are easy to construct when we have solid scenarios to work with.

For example, our savings helper system can have users stories such as:

As a banking customer, I want to estimate how much money I’ll need for tuition in 18 years, so I can make a savings plan.

As a banking customer, I want to calculate how much I need to save each month, so I can start putting that money aside.

As a banking customer, I want to receive notifications when my discretionary spending money starts to run low, so I don’t put my funds for fixed expenses and my savings at risk.

The development team can use these stories to create the functionality to realize the promise of the design. Because the team put all the hard work in when creating the promise and vision stories, it’s easy to see how the user stories map development efforts directly to how the team will meet its promise to the user.

Hear It; Tell It

For this to work, everyone needs to know the stories as well as they know childhood stories like Little Red Riding Hood or Hansel and Gretel. Every member of the team should easily recount the story, almost identically to how any other team member would tell it.

You can’t make this work by writing the stories and shoving them in a PDF on a server. They have to be frequently discussed amongst the team. They also have to be the ones telling the stories frequently. It’s the repetition of the stories that’ll make them come alive.

It’s not unusual for teams to hold design reviews. However, how often do those reviews compare the design to the scenarios behind them? What would happen if, in preparation for the review, everyone talked about the promise, vision, and scenario stories that are the basis for the design work?

Keeping the Stories Relevant

Giving the stories a constant presence throughout the project is essential to ensuring the promise stays top of mind. Drawing the connections between the work being done today and the promise story the team wants their users to tell will help keep the work relevant.

What stories are your users telling today? Simple interviews and other basic research can give the team a baseline on where the product or service sits in the hearts and minds of your current customers and users. From there, the team can establish where they’d like to be.

When a team integrates the promise of their design into their day-to-day design work, they are on the path to producing something great.

Every UX Leader Needs A Unique UX Strategy Playbook

May 29, 2018

I could tell the question I’d asked was a completely foreign idea, just from the look on the UX team manager’s face. She was sharing her frustration about her product teams asking for the UX team’s help, but not letting them do their job.

Some product teams were great, she told me. Those teams would bring her UX team in early, ask them for direction, exploring the problems, listen to research results, and make shifts in the product direction accordingly.

But other product teams were bringing her team in too late, dictating exactly what the design should be, and get upset when the user research showed those designs wouldn’t solve any customer problems. She’d tried to get these product teams to bring her folks in earlier, but they kept waiting until they’d locked the design down.

That’s when I popped the perplexing question: “Are you allowed to say ‘No’ when a product team asks for user experience help?”

“Why would we want to do that?” she asked.

I explained how saying ‘no’ was an advanced approach for dealing with product teams that waited too long. The basic idea is to tell them you’ll only work with them if they bring your team in early enough. Otherwise, they’re on their own.

The approach works because it puts pressure on the product teams that aren’t cooperating. It shows those team leaders they need to change their habits to get the help of the UX team.

Saying ‘No’ is a UX Strategy Play

Shifting an organization to become more design driven is a long game. And like any long game, it’s made up of a series of plays, each one advancing the UX team towards the goal.

Saying ‘No’ to UX work is one of those plays. There are lots of plays. We’ve identified more than 90 so far, and we’re adding new ones every month.

UX strategy plays range from providing regular usability testing, to introducing design studio workshops, to shifting the roadmap from a feature focus to a customer-problem focus. Each play helps the UX team, the product and service teams working with the UX team, and the rest of the organization move towards delivering better designed user experiences in products and services.

Plays Have Tricky Timing

This UX Team had been executing a different play for a while: Always say ‘Yes’ when asked for UX help. When an organization is starting down the road of learning about design, taking on any UX work is the right thing to do. It’s basically the opposite of the saying ‘No’ play.

When nobody in the organization understands why they should think about their product or service’s user experience, volunteering to show them is the right play to make. Jump in and demonstrate value.

Later, when teams understand the value, this play loses its power. That’s when the shift to the saying ‘No’ play comes in.

Saying ‘No’ tells the organization as a whole that the UX team won’t invest their time in product teams who refuse to reap the benefits of good design practice. They’ll only make the investment in those product teams who come to the project prepared to do it right.

It takes executive support to shift from the Always ‘Yes’ play to the Saying ‘No’ play. That’s why I asked the team manager. Did they have the air cover from above? When a rejected product team complains that the UX team isn’t cooperating, will an executive put pressure on that product team to change their ways?

A UX team can’t start with the Saying ‘No’ play. Nor can they make the switch before they’ve executed plays to ensure they’ve got the executive air cover. The timing is tricky and needs good planning to work.

Building a Dynamic UX Strategy Playbook

This is where a solid UX strategy playbook comes in. The playbook contains the plays the UX leadership is executing now and the plays they’d like to execute next.

The UX leadership adapts their playbook as the situations change. If the company goes through a merger, or a new competitor enters the market, the new circumstances may cause the team to modify the playbook to match. Similarly, the playbook needs to change as the organization becomes more design savvy, shifting the UX team’s role as a service provider to the role of training product teams how to solve their own design challenges.

Each product or service team matures their design efforts at a different rate. Many UX teams find their playbook needs a range of plays, choosing specific plays for the product or service team they’re currently collaborating with.

Almost all UX leaders have some type of playbook they’re working from. Many, however, rarely talk about how their playbook has to be dynamic and change as situations demand. Leaders often get stuck continuing to execute plays that are no longer working, failing to adopt new plays that would help them move forward.

The best UX leaders are more explicit about their current playbook, sharing it with their team and others in the organization. They adapt to new situations and are constantly evaluating what’s working and what isn’t.

A dynamic UX Strategy Playbook can be an amazingly effective tool. It gives the organization a clear path to becoming design infused, as the UX leadership drives product and service strategies. As UX teams mature, the playbook becomes an essential guiding force to fulfilling their mission.

Increasing an Organization’s UX Design Maturity: Our Not-So-Secret Sauce

April 11, 2018

Better UX design maturity makes an organization more competitive and more effective at delivering great products and services. While this is easy to say, we’ve seen this is not easy for key executives and stakeholders to understand. Without that understanding, organizations rarely improve.

During the past 30 years, we’ve tried many approaches to increase the executives’ and stakeholders’ understanding. Most approaches have failed. While they’ll often nod their head knowingly, nothing will change in the organization. They proceed to do what they’ve always done and get the same results they’ve always gotten.

Recently, we’ve seen this change. We’ve hit upon an approach that goes beyond idealistic head-nodding. An approach that creates change in the organization. Change that improves the user experience of the organization’s product and services, which in turn, allows the organization to meet the goals of being competitive and effective.

The Not-So-Secret Sauce

We could keep our approach secret. But that’s not who we are.

Instead, we tell everyone. So, here’s how we help organizations increase their UX design maturity. Here are the ingredients for our not-so-secret sauce:

  • shared vision
  • immersive exposure
  • continual learning

The ingredients of our not-so-secret sauce are how we help UX design leaders gain their executive and key stakeholder buy-in. When those executives see the common vision for what the products and services could be, they get excited about making it happen. When the stakeholders are deeply exposed to who the users are and what those users currently experience, they see what needs to be done to reach the vision. Once the executives and stakeholders have that understanding, they’re more likely to put their role power, influence, and resources into growing the organization and learning how to achieve it.

Empowering the UX Design Leader

Think of a sportsball game. In sportsball, when your team runs onto the sportsball field, your team’s leadership must focus on two objectives: scoring a bunch and preventing the other team from scoring a bunch. Everything your leadership and your team does needs to be in service of those two objectives.

If they want their organization to be more mature, UX Design leaders also must focus on objectives: creating the shared visions, delivering immersive exposure,and creating a culture of continual learning. Everything they and their team does needs to be in the service of these three objectives.

We Start with a Shared Experience Vision

What will the experience of using our awesome product or service be like 5 years from now?

This is the question we teach UX design leaders to start with. We tell them: Let’s assume we can deliver something awesome that your customers will love. What’s will be different in their life when they have your awesome product or service?

We’re starting with the end in mind. We’re painting a picture. We then work to have everyone in the organization to fall in love with it. (If they don’t, we keep tweaking it until they do.)

The beauty of starting with vision is it plays to our strengths. Great UX design leaders are inherently great storytellers. The vision is a great story.

The experience vision makes our customers and users into superheroes, with our products or services becoming their superpowers. Everybody loves a good superhero story, especially when it involves cool superpowers.

What makes a great experience vision work is how it shows, without telling, what the power of good design is. Anyone who is familiar with what our current customers and users go through will immediately see how a better designed product or service improves their lives.

With an experience vision, we don’t have to bore people with how our design process works. We start by painting a picture of a beautiful, desirable future. The executives and stakeholders will want to shout “We want that! How do we get it?” That’s how we’ll know we’ve succeeded.

Deliver Immersive Exposure

What’s the experience we’re currently delivering to our customers and users?

UX design leaders have known for years about the power of watching users and how those users experience our products and services. There are a few things that motivate change more than watching a user struggle to accomplish a goal we thought would be easy because of our design.

Yet, guided by some wacky notion of efficiency and job protection, many organizations have put their UX research team between the people who truly need the motivation and the users who will motivate them. Isolating the executives and stakeholders from users works against us.

Instead, we’ve been showing UX design leaders a myriad of techniques to get those executives and stakeholder directly exposed to the users and their struggles. Every time these folks are exposed to seeing the users, it builds a desire to make those users’ lives better.