A UX strategy workshop
led by Jared Spool USA & England   ·   2018

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.

Learn how to match your users’ expectations through a focused and custom strategy playbook. Join us for our two-day Creating a UX Strategy Playbook workshop to choose from more than 130 strategies proven to help UX teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

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.

Learn how to help your organization create better user experiences, including better non-digital user experiences. 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.

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

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.

Want to bring change to your organization?

When you come to the Creating a UX Strategy Playbook workshop, I’ll give you 130 proven strategies to choose from. During the workshop, I’ll work with you to select the best strategies for your team’s current situation. Together, we’ll figure out the right baby steps for you to get started.

Don’t wait to make big changes in your organization: See how at the Creating a UX Strategy Playbook workshop.

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.

I’ll be back in Manchester, UK on November 27-28 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.

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

Learn how to improve your critiquing skills. Bring your design 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.

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.

Originally published on UIE.com

You’ll want to learn how to apply this to your team’s UX design strategy. You can find out during 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.

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.

Originally published on UIE.com

In our Creating a UX Strategy Playbook workshop, we work through several different strategies design leaders have employed to bring proactive UX design to their organizations. Explore how your team can become more proactive at the workshop’s website.

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.

This article was originally published on UIE.com

A great design process needs to serve the overall UX design strategies in play. If the process works counter to those strategies, it prevents the team’s goals from being achieved.

At our Creating A UX Strategy Playbook workshop, you and your team identify the critical UX design strategies your organization needs right now. You’ll leave the workshop with an action plan that will drive what your design process needs to be. Explore how you can create your UX design strategy at the workshop website.

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.

Originally published on UIE.com

Instituting regular critiques 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 teams practice to be more competitive and design focused. You can learn more about the workshop, what you’ll learn, how much it costs, and where you can attend at Playbook.UIE.com.

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.

Originally published on UIE.com.

· · ·

Within the first few moments of our 2-day Creating A UX Strategy Playbook workshop, we have each attendee create a vision story for their product or service’s user experience. The entire process takes 15 minutes or so, and while it’s not the ultimate vision story that team may end up using, it demonstrates how powerful this technique is.

Crafting an experience vision is one of the 130 proven strategies we’ve identified that have helped organizations become more design infused. In this workshop, you’ll pinpoint the 8 key strategies most suited for your organization’s current situation, which will have the biggest influence on your delivering better-designed products and services.

Learn more about the Creating A UX Strategy Playbook workshops at Playbook.uie.com.

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.

That desire plays right into the vision, which cements the mission. Now the executives and stakeholders are on board with the idea. They can see what needs to change between experience present to get to experience future.

Create a Culture of Continual Learning

What does our organization need to learn to deliver great products and services in the future?

Armed with an understanding of what needs to change, the executives and stakeholders now turn to the UX design leaders to discover how to execute. It’s rare that an organization is currently well equipped to make the change. If they were, they would’ve already achieved their vision.

In UX design, we shouldn’t measure progress by the designs we’ve produced. Sure, producing great designs is better than not producing them. However, you only produce a design once, then you move on.

We’ve seen that smart UX design leaders measure their progress by how much their organization has learned. What do they know about their users? What do they know about their products or services? What do they know about the users’ unsolved problems and challenges?

How has that knowledge and understanding changed from before? That’s the sign of real UX design progress. The more the organization has a deep understanding of the challenges and struggles of its customers and users, the more the organization can work to eliminating those struggles and overcoming those challenges.

Increasing the UX Design Maturity

That’s what makes an organization competitive in the marketplace. That’s what makes the organization’s delivery of services more effective.

Those smart UX design leaders not only help their own team learn these things, they work to help the entire organization learn them. They use what they learn from their immersive exposure efforts to identify what those challenges and struggles are. They use the shared understanding of the experience vision to point out what life could be like for customers and users.

This is the not-so-secret sauce that increases the organization’s UX design maturity. With every baby step, the organization gets just a little closer to being more effective. It’s solid design leadership that gets them there.

This not-so-secret sauce has worked well for us, so we’ve made it the organizing framework behind our two-day Creating a UX Strategy Playbook workshop.

Homework for the UX Strategy Playbook Workshop

April 5, 2018


I'm very excited you're coming to the Creating a UX Strategy Playbook workshop. We have a jam-packed day and half put together for you. You're going to love it.

Let's get started now.

There are four things I need you to do to get ready for the workshop. Don't panic if you can't get all of these done perfectly. Do what you can, and we'll have room in the workshop to adjust for what you don't get to. The homework will ensure you get the most out of the exercises.

1) Beyond the UX Tipping Point Video

In the workshop's first section, we’ll look at your organization's design maturity. To understand how I'm thinking about design maturity, I'd like you to watch this presentation:

Beyond the UX Tipping Point (77 minutes)

Video access, slides, and transcript.

The important part to focus on are the three maturity scales: The growth of understanding, the growth of organizational design, and the maturity of the marketplace. We'll refer to these in depth during the workshop.

2) Building A Winning UX Strategy with the Kano Model

In the workshop's second section, we'll look at the process by which features are added to products. We'll break them down into the categories defined by what's known as the Kano Model. You'll want to watch this video to see how that model works.

Building A Winning UX Strategy with the Kano Model Video (48 minutes)

Video access, slides, and transcript.

We'll be focusing on experience rot, meeting expectations, and the approaches to delight. In the workshop's afternoon section, we'll look at your design process and see how these components of the model affect it.

3) Pick 3 mission-essential ongoing or recent projects

As we work through your UX strategy plays, we'll want to have some concrete examples to work with. Think about your organization's mission. What are three ongoing or recent projects which feel essential to that mission?

Here's what we'll need to know about those projects:

  • What was/is the outcome that makes it essential?
  • How long has it been going on? (And how much more do you think they have to do?)
  • How will the organization determine if it was successful?
  • Who is on the team directly? Who are key stakeholders?
  • Is UX design an important part of this project’s success? How has it been a part?

You don’t need to write up anything formal. Just some quick notes for you to reference during the workshop.

If you're coming with co-workers, you could pick these as a group in advance. However, it might be more interesting if each of you picked your own three projects, then compared notes to see if you have the same viewpoint of your organization. (That alone could be very informative.)

4) Assess your UX team's skills

In the final section of the workshop, we’ll look at the strategic plays for strengthening and growing your UX team to meet the future demands of the organization.

Read the article, Assessing Your Team’s UX Skills, then do a rough assessment of the skills of your UX team. We’ll go over your assessment, looking for places where the team can improve and places where you'll want to focus your future hiring efforts.

Again, if you’re coming with co-workers, you could do the assessment in advance as a group. It also would be interesting to see if you would rate the team the same way as your co-workers, so you might want to try it independently first.

I know I’m very much looking forward to the workshop. I hope you are too! See you soon.


Figuring Out Your Design Decision Style

April 1, 2016

Suddenly, it got meta. There we were—the team and I—trying to decide which styles of design decisions the team would use from now on.

Deciding how to decide things sounds like we were in one of those corporate stalling tactics, like talking about having a planning meeting to talk about planning meetings. Yet we weren’t stalling. We were making an important decision about how the team would work together.

At the time, this was a fairly new team. The bulk of the team had worked together for a little longer than a year, with a couple of new additions in the last few months.

In that period, the team found themselves reacting to what the company needed built. They had become a service team that made quick and obvious product improvements.

From the team’s work, the company had realized the successes that come from focusing on experience design. They were directly responsible for happier customers, lowered support costs, and increased sales. The company’s executive team saw these results and was hungry for more. The team needed to become more proactive.

Making Smart Design Decisions

Like many teams I work with, they had learned to work together through an ad-hoc process. They never decided how they’d make decisions. They made each decision based on whatever information and opinions they had at the time.

For small, quick projects, I’ve seen ad-hoc decisions work pretty effectively. However, over time, the decision process starts to look like a drunken sailor’s walk, meandering in different directions with different approaches every time they face a new decision. When you’re building a team and trying to have a larger affect on the organization, this approach won’t get you there easily.

In our research, we’ve seen the most effective design teams are very deliberate about how they make decisions. They pick a decision-making approach early on, get everyone on board (including senior management), and then stick with it throughout the project.

The team’s Director of User Experience had seen me give a presentation about our research. He now wanted his team to choose the right decision style for their future work. He invited me to help work through their choices.

We collected the team together. These were super talented folks, with a wide variety of backgrounds. Like many teams, there were a few members with strong opinions about the right way to do things. Others were more open to exploring approaches. We gathered in a conference room and started the conversation.

The Cheap Style: Unintentional Design

“Ideally, whatever we do should be cheap and easy,” the Director of UX told the group with a big smile.

“The cheapest style is Unintentional Design,” I responded. “But they wouldn’t need any of you to do it.” Unintentional design is what emerges when a team only pays attention to the technical implementation or the specific needs of the business.

A simple example of unintentional design is an error message written quickly as a placeholder by a developer, expecting someone will write something better later, but nobody does. For example, in the most recent release of Healthcare.gov, leaving the gender field empty gets an error message simply stating “Sex is required.” Nobody decided this was the right error. But a message was needed, so in the rush to get it out the door, that’s what got shipped.

When nobody pays attention to the user experience details, they evolve on their own, creating frustration and confusion for users. The emerging poor user experiences are haphazard and unconsidered. They raise support costs and users hate them, making word-of-mouth recommendations hard to come by.

However, it’s inexpensive to implement unintentional designs. As I told the team, “Once you remove quality as a requirement, building your product gets a whole lot easier and cheaper.” Talented designers aren’t needed if you’re willing to let any experience emerge out of the rubble of the technical design.

“Ok, that’s not going to work for us,” the Director said with a smirk.

The Expensive Style: Experience-Focused Design

“What about Experience-Focused Design?” one of the senior team members asked. “I heard you talk about that. It sounds exactly like what we should be doing.”

Experience-focused design is when the team focuses on the total experience of the users. In addition to designing the interactions of any applications or web sites, they design the users’ experiences leading up to, between, and after those interactions.

Disney’s new Magic Band bracelet, for example, is much more than a wearable device. The Disney design teams worked on how the bracelet changed the total experience for their park and resort guests. Every place the bracelet could do magic, like being the key to the guest’s hotel room door or the credit card for any payments in the park, they built it in.

I’ve found working on an experience-focused design project is a common dream for passionate user experience professionals. This kind of work gives the designer control over many of the contextual and environmental elements, from signage to network integration. It’s amazingly challenging and hugely fun. Done well, it changes the lives of the users. Who wouldn’t want to be part of that?

However, it’s also hugely expensive to pull off. Disney spent more than one billion dollars on the integration of the Magic Band. This kind of investment is beyond most organizations.

“Someday, but we’re not there yet.” the Director pronounced.

The Talent Investment Style: Self Design

One of the newer designers piped up. “I liked what you said in your talk about Self Design. Maybe we could use that?” Self design is when each designer creates a product they’d personally like to use.

The first iPhone is a famous example of a team using the self design decision style. The team at Apple didn’t need to go off and do a ton of research about the problems and frustrations people had with their phones.

Each member of the iPhone team hated the old phone they were using. They experienced the problems and frustrations first hand. They created something that would make them happy, in turn creating something that made millions of people happy.

Self design works best when the product is something they use every day. If the team unintentionally introduces a frustrating feature or aspect into the design, they’ll encounter it and fix it.

Self design teams tend to have limited diversity. After all, you need everyone to think the same way to make the product feel cohesive. The teams also can’t grow very much, because adding more designers will introduce variations in perspective, which will introduce rough spots into the designs.

Cost wise, it’s a relatively inexpensive approach. The organization’s primary investment is in the talent of the designers. However, it’s a limited approach. It’s great for a first version of a new type of product, but doesn’t work for ongoing versions of the design, especially when the team needs to introduce features they may never use themselves.

The Research-Grounded Style: Activity-Focused Design

“It’s sounding like Activity-Focused Design may be your best option,” I suggested. Activity-focused design is the closest style to conventional ideas like user-centered design. It’s when the team spends their time researching the users and their activities. The team uncovers the users’ needs and how the product will address those needs.

Using an activity-focused design decision style, the team looks past their own opinions of how the product should work. Instead, they spend time with their users, diving deep into what those users’ objectives are.

With this style, teams use tools like personas, scenarios, and journey maps. They regularly conduct extensive user research through usability testing and field observations. They create prototypes for users to try and iterate through variations on designs.

All that research isn’t cheap. It takes time and resources. It is most effective when everyone—including the product managers and developers—meet the users and see how they interact with the designs. The costs for all this research adds up quickly.

Yet these costs are worth it for organizations serious about meeting the diverse needs of their most critical users and customers. The designers spot frustrations and smooth out the rough edges. They can create delightful experiences that easily differentiate their product from their competitors.

“That’s what we’ve been trying to do,” the Director said, “but when we skip the research, we fall back into self design.”

“Yea, except our designers are not all alike,” added one of the team leads. “That explains why some parts of our product are frustrating users. We’re all approaching our assignments differently, not taking our users into account.”

The Long-Term Style: Genius Design

“I supposed we should use Activity-Focused Design from now on,” the Director declared.

“It’s a good place to start,” I replied, “but you could work your way to Genius Design.” Genius design happens when a team gets to know their users so well that they can accurately predict the results of any research. They learn to become geniuses about their product’s domain.

We see this decision style most often in agencies that are chasing a particular niche market. For example, an agency that works with high-end boutique bakeries would learn everything there is to know about small bakeries and how they operate. They’d study up on the variations and operations. The agency’s offerings could include consulting and expertise on how to run a bakery efficiently, because they’ve learned the best practices of other non-competing bakery clients.

The path to genius design starts with activity-focused design. When the team has studied the users and activities of a variety of their customers, patterns will start to emerge. Over time, the team becomes so versed in the commonalities across customers they can predict what future research will tell them. Those predictions can become so accurate, the team no longer needs to do most of the research. They are now using the genius design decision style.

Genius design reduces the cost of any given project, due to economies of scale. Because the team has learned what’s common, they can develop tools that will meet the needs of a large number of their customers. Using those tools across further projects brings down the overall investment.

Genius design only works when the work from new projects can take advantage of the research and design work from previous projects. If there’s not much overlap in the users and their needs, then activity-focused design is the better option.

A Different Style for Every Team

This team settled on starting with activity-focused design, looking to move to genius design after a while. They believed their future product plans would give them a lot of overlap as they expanded new functionality, which would let them take advantage of what they already have researched.

That won’t work for every team, however. Every design style has a place and time. The competitive landscape, the nature of the product or service, what the customers need, and how mature the UX efforts in the organization will all play a role in the decision.

Teams need to regularly re-evaluate their own decision styles. Are they still using one that’s appropriate for their needs? Are they sticking with it as the projects progress? Is everyone thinking it’s the same style?

The best teams stay on top of how they are making decisions, not just the decisions they are making.

You and your team can learn to make smarter design decisions and so much more at a UX Strategy Playbook workshop. Learn more right here

Stay Updated