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

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.

PS

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.

UX Strategy Playbook Workshop: Bring the Right People Along

July 31, 2018

Jared talking with a design leader to help him build out his organization’s UX strategy.

Jared guiding a room full of multidisciplinary product teams to choose their organization’s UX strategies.

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.

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.

Prototyping

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

Hello,

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.

Jared

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