A UX strategy workshop
led by Jared Spool USA & Europe   ·   2019

UX Strategy Stories

The Strategies Behind Effective User Research

April 19, 2019

The key for teams to deliver more innovative, well-designed products and services is clear. We can describe the key with one word: exposure.

The more our team members are exposed to the users of our designs, the better our designs become. When team members don’t have enough exposure, they make poorer design decisions. Those poor decisions lead to designs that frustrate our users.

Frustrated users will jump at the opportunity to use a better-designed product or service. To be competitive, we want our products and services to be the ones our users jump to use.

To make this happen, we need a deep understanding of how our designs frustrate our users and where our designs can be improved. To get that deep understanding, everyone on our team must be exposed to our users while they’re using our product.

Everyone needs exposure

Everyone involved in making and influencing design decisions need this exposure. It’s not just the designers. We must expose our developers, product managers, stakeholders, and other influencers who guide the decisions we make to our users. Even that executive who regularly swoops in and poops all over our design (a process known as the seagull maneuver) needs exposure.

When someone influential doesn’t have enough exposure, the decisions they make are not based on what the users need. They are based on opinions.

At best, those decisions are based on what they themselves might need. At worst, the decisions are based on guesses. Unfortunately, it’s unlikely those decisions are the right decisions.

The maturity of our user research efforts determines the number of avenues we can use for exposing our team members to our users. As our user research efforts become more mature, there are more ways to see what our users need from us.

Strategies to increase exposure

During our 2-day Creating a UX Strategy Playbook workshop, an entire afternoon is dedicated to exploring the strategies organizations successfully employ to increase user exposure on their teams. Design leaders at the workshop explore dozens of strategies, to identify the ones most likely to work in their organization.

Here’s a small sample of the strategies specific to increase exposure. How many of these strategies could your team be doing better?

Strategy 1.03: Initiate a usability testing program - While many teams already have established usability testing efforts, there are still many who don’t do this regularly. See how decisions have an immediate effect on how users interact with your designs.

Strategy 2.02: Institute a field visit program - Get into the user’s environment to see how the work they do and how your design makes a difference.

Strategy 2.03: Socialize exposure - Make sure everyone in the organization sees how increased exposure improves the design of products and services.

Strategy 2.20: Institute identifying customer problems using the Kano model in regular field study synthesis - Focus the team’s research analysis on reducing complexity, meeting expectations, and creating delightful experiences.

During the workshop, we’ll explore many other strategies specifically geared toward increasing the exposure of team members. Here are a few more:

Strategy 2.16: Institute a formal discovery phase for every project
Strategy 2.29: Institute including executives and key influencers on field visits
Strategy 3.19: Integrate multi-variant tests with qualitative research to learn why variants work
Strategy 3.39: Institute program for everyone to answer support emails and calls

These are just a few of the 130 strategies we explore in the Creating a UX Strategy Playbook workshop. During the workshop, you’ll identify which strategies are most effective for your team. You’ll assemble an action plan in the form of a playbook that details exactly which strategies will work best.

If you want to deliver more innovative, well-designed products and services, this is the workshop for you. You can read more about the strategies and how the workshop works at Playbook.UIE.com.


We limit every workshop to 24 participants. Because design leaders often bring their peers from development and product management to help choose their best strategies, the workshop fills up quite quickly. Register today.

A Favorite User Research Trick

April 12, 2019

“So, what do you think?”

That’s the question I posed to the executive stakeholder as we came out of an informative research session.

“It was about what I had expected,” the exec replied. How could that be? The participant in the session just exposed major challenges I knew none of us had considered before. How could that be something the executive expected.

This kept happening. We’d go into sessions that uncovered remarkable findings and the executives who observed would emerge claiming it was exactly as they expected. We listed all of the things we learned while the stakeholder struggled to acknowledge there was anything they didn’t expect to hear.

Asking for expectations up front

I made a change to my routine. While the observers were gathering before the next session, I described everything we knew about the participant we were about to meet. Then I asked each observer, “What do you think we’ll see in this session?” I walked through each of the research questions we’d plan to investigate and asked what they thought we’d learn from the participant.

I saved the executive for last. They had just heard the wide variety of guesses everyone was making and could now safely add their own to the list.

And guess what? The session didn’t go as anyone expected, even the executive.

When we emerged, I asked the exec what they’d thought of the session. “Wow, that was a huge surprise. It wasn’t at all what I had expected.” They went on to list all the things they had learned from the participant. Success!

Overcoming bad training

In many organizations, executives are trained to never show surprise. It’s part of the organization’s culture of pretending everything is always under control. Executives are supposed to be the ones in charge, they’re expected to know what the outcome will always be.

Of course, executives don’t always know. Nobody can always know. And the entire point of user research, whether it be user interviews, usability testing, field studies, or some other method, it to inform us of the things we couldn’t possibly know otherwise.

Every so often, someone gets it right!

I’m surprised when someone accurately predicts what we’ll learn. It’s happened a few times.

I keep an eye on that person. If in subsequent sessions, they continue to predict what we’ll learn from the participants, we’ll want to take advantage of their insights. They’re obviously in touch with the users in some magical way.

Having someone with this knowledge and experience on the team is truly valuable. We can trust them as a Subject Matter Expert. They’ll be a valuable resource.

Of course, we’ll continue to ask them to make predictions, to learn where the boundaries of their knowledge and experience extend. Everyone has their limits.

Part of our regular research protocol now

I now ask “What do you think we’ll see in this session?” before every session I conduct. And I rarely get ”it was about what I expected” as an answer because we have documentation showing it wasn’t at all what they expected.

I’ve found this to be a useful technique for helping every observer head into each research ready to experience a broader understanding of who the users are and what they need. This is key if we’re to deliver better-designed products and services.


Solid User Research is a critically important capability to becoming a design-led organization. In our 2-day, intensive Creating a UX Strategy Playbook workshop, I’ll work directly with you and your team leaders to craft your ideal strategy to ensure your teams have the best UX research skills and experience.

We cap each workshop off at about 24 attendees. This gives Jared plenty of time to work directly with you on the ideal strategy for your team. Learn how your team can deliver better-designed products and services.

How a Team Matures Its User Research Integration

April 10, 2019

The order came down from high up (or wherever orders come down from): We need to implement an export data function in the app. That’s all we knew. Except there was a rumor of a big deal being held up until someone got their export data function.

The stage of our team’s user research maturity will determine how we’ll handle the user research for the export data function request. The more mature a team’s integration is, they more data and insights they have to make smart design decisions.

Stage 0: No user research integration at all

Starting out, our team hasn’t built up any user research capability yet. The developers go ahead and implement an export data feature based on what they think the requirements are, making guesses for anything not specified. They design something the way they themselves would like to use it. (A technique we call self design.)

It isn’t until the feature is delivered and users start using it that we get any feedback at all. What feedback we get likely comes from support calls or sales engineers, reporting back what they’re hearing from the customer.

The feedback is likely distorted and incomplete, so any recommendations or fixes that come from it aren’t effective. The most likely scenario is the feature stays in its initial design until some future feature requires a change.

Stage 1: Basic usability testing

Our team now conducts usability tests on new features. Once the developers give us something to put in front of folks, we gather up several users and ask them to give it a try.

When the participants show up, we jump right into a session. We give them some tasks to perform, based on what we imagine how our users will employ the export data function.

As they try to export the fake data we’ve created for them, we capture all the places where the interface confuses them or prevents them from accomplishing the task. When we’re done, we write a report.

Like Stage 0, our developers first took a crack at building what they thought would be a good response to the requirements. We used what they built for our test. Our testing sessions tell them if they were close or not.

Of course, we need to wait until there’s code written and stable enough to test. And there’s a good chance that there’s a hard deadline to ship the feature soon. That means we have to rush to get all the testing done that we’d like.

When the developers’ initial design didn’t work well for the users, there’s a big discussion about whether we ship what we’ve got anyways. (We do.)

Stage 1.5: Usability test tasks come from support

Our team starts working closely with the support and customer success teams. We hear directly from them about what our users are trying to do with the export data function. More importantly, we hear where it’s not working well.

As we conduct more usability tests on the functionality, we use this information to help us craft our tasks. We focus our research on problems users contacted support about, to ensure we better meet their expectations.

Stage 2: Interview-based task design

We upped our usability testing game. Instead of crafting test tasks based on how we imagine users will use the export data function, we use interview-based tasks instead.

Now, when recruiting participants, we screen them to ensure they’re likely to use the export data function in our design. Upon their arrival, we start the usability testing session with an interview. During that interview, we probe to understand how they might use the export data function. We work with them to jointly create a test task, which we then ask them to complete.

Even though no two users will use the same tasks, we learn much more about the export data function and what our users are trying to do. If we can do this testing early enough in the feature’s development, we can influence a better fit for the design.

Stage 3: Basic field research

Time to experiment with getting out of the building and heading to where the customers are. We are not trading in our usability testing program for this new field study work. That’s still happening. By doing both, we make our insights richer by better understanding the contexts around features like export data.

We’ve broken through the corporate politics that try to separate us from real users in their own environment. Now we can see where and how our users work with our design.

When we arrive for a field study, our research participants show us what they’re currently up to. Because the export data function is not something our users frequently need, the chances are slim that we’ll see them use it. However, we may see many upstream or downstream activities.

Researching in the “wild” lets us see more of what our users’ lives and work environments are like. We can feed this into the tasks and environments we design for our continuing laboratory studies. Even though our exposure to the export data function usage is limited, we’re learning a ton about our users overall.

Stage 4: Focused field research

We’ve upgraded our field research know-how to identify and recruit those field study participants who will use the export data function when we visit. Now we see what leads up to exporting the data, and what they use the exported data for.

Because we can focus in on the right users at the right moment, we can see a broader sample of issues that arise. We’re seeing more subtlety and nuance in how people use our design than we’ve ever seen before. In turn, this helps us identify what works best for our users.

Stage 5: Longitudinal studies

We now continually study the end-to-end experience of our users. We don’t wait to be told from above that there’s a need for the export data function. We know about it before they tell us. Our research told us there was a need before the customers mentioned it to the sales folks.

Our research techniques have become more nuanced. We improve our ethnographic methods with some deep hanging out with our users and customers. We experiment with storytelling listening techniques, such as collective story harvesting and World Café. We exercise our data science skills, deriving meaning from by crafting custom telemetry from our designs.

All this advanced research informs our entire team, feeding insights to prioritize their work. It provides a shared understanding so other team members are clear on the intention of the design. The better they understand the design’s intention, the more likely they’ll create something that matches it.

Stage 6: Strategic user research

Up until this point, our research efforts primarily focused on the current functionality. Yet, with our deep knowledge and understanding of the full user experience, we now play a strategic role throughout the organization.

Our research has become instrumental in picking strategic priorities for the product as a whole. The ethnographic field techniques are showing us where we can create a competitive advantage, not just from holes in our own experience, but from gaps competitors haven’t identified either. These strategic insights become the basis of the themes on our product’s roadmap.

Our research also feeds into the overall vision of a product’s experience, helping us understand exactly what work is left for our teams to do.

It’s team maturity, not organization maturity

These are the individual stages each of our organization’s teams go through. Each team goes through this process at their own rate.

Even if you’re a researcher that’s assigned to multiple teams, you’ve probably noticed your teams each have a different pace of increasing the user research integration into their work. Reducing friction for growing their research capability is the best way to help them speed it up. For example, you could build a centralized capability for recruiting, making it easier for teams to select participants for studies on short notice. (Studies are always on shorter notice than we’d like.)

Because every team is at a different stage of maturity, there’s no real advantage to assess the overall organization’s maturity. It’s better to track the progress of individual teams and identify what might nudge them to the next stage.

Beyond technical skills

At every new stage, our initial focus is on the new technical skills we must master to be good at our jobs. Yet, it doesn’t stop when we’ve mastered certain techniques.

We also must learn how to make our research valuable to the teams we work with. They need to feel our research is invaluable to their work.

We want to discover what piece of research will be so beneficial that our teammates will demand more. We need to learn what will make them so hungry for our research, they feel they can’t live without it.

Research can’t be a separate function

Outsourcing your research is like outsourcing your vacation. It gets the activity done, but it doesn’t realize the value. If only your researchers are doing the research, you’re doing it wrong.

For research to be truly valuable, everyone on the team has to be part of it. Everyone should be a part of the planning and have a say in who our participants will be and what we want to learn from them.

Every member of the team needs to observe the research and be part of the synthesis of the outcomes. They need to feel ownership in understanding the problems users have and potential solutions.

We can’t achieve this if we’re the intermediary between the rest of the team and the users. They need direct and constant exposure to the people they’re designing and developing for.

We need to teach them how to truly see their users and learn how to make great design decisions as a result. We’ll know we’ve succeeded when the team comes to better design recommendations than we would ever have made ourselves.

Researchers need to be research leaders

For the team’s user research integration to mature, a major role for the team’s researchers is to constantly be growing the team’s research capabilities. It’s our job to be thinking about how we’ll get to the next stage, while, simultaneously, we focus on how to better work at the current stage. We can’t skip a stage. Each is necessary a step to the next one.

We need to champion a culture of continuous learning—not only for ourselves—but for our teammates too. Every day, we need to celebrate what we’ve learned about our users, those users’ needs and challenges, and the techniques that helped us uncover them.

Much of a successful research practice is building relationships. Relationships with the gatekeepers to the customers, the customer success team, the customers, and their users. We need to earn their trust and respect their own needs. This, after all, are the key traits of a great leader.

User research is about growing and learning. Every day, we get better at what we do and our teams learn more about the people they’re designing for. This is how our organization will deliver better-designed products and services.


Solid User Research is a critically important capability to become a design-led organization. In our 2-day, intensive Creating a UX Strategy Playbook workshop, I’ll work directly with you and your team leaders to craft your ideal strategy to ensure your teams have the best UX research skills and experience.

We cap each workshop off at about 24 attendees. This gives Jared plenty of time to work directly with you on the ideal strategy for your team. Learn how your team can deliver better-designed products and services.

The Truth About UX/UI Designers

March 29, 2019

UX/UI Designers are real. They aren’t a mythical creature, as many are quick to suggest. It’s a real design position filled by real designers, many of whom are capable of great work.

The UX/UI designer works on both the design’s user experience and the user interface. In the right position, they’ll create easy-to-use, effective, and delightful designs. As a collaborative team member, they’ll bring applications and websites to life. Hiring a UX/UI designer is very attractive to small teams, especially when there’s only one available design opening.

Once on board, they specify the overall flow and feel of the design, while getting into the specifics of every interaction. The UX/UI Designer’s expertise contributes to the design’s information architecture, visual design, and interaction design. Some UX/UI designers can even write preliminary front-end code to demonstrate their intention with the design.

If this sounds too good to be true, you’re in good company. There are lots of designers who contend that no such designer exists. They believe nobody can do all those things.

The truth is they are wrong. There are UX/UI designers in the world. Good ones, too.

UI + UX = UX/UI

Any designer is only as capable as the skills, knowledge, and experience they’ve accrued over their career. However, there’s no hard-and-fast rule about which skills, knowledge, and experience they can acquire.

If we think of experience design as five levels of resolution: eco-system design, organization-wide design, application/site-wide design, screen design, and conversation design. To successfully design in each resolution, the designer needs the requisite skills, knowledge, and experience to get the most out of that resolution’s specific tools, methods, and principles.

A UI designer focuses on what’s on each page or screen of a design. They draw on their expertise to know how to layout the information on the screen. They design effective forms and dialogs to guide users to efficiently and effectively interact with application or web site.

A UX designer employs different expertise, looking at the entire application or website works as a whole. They design the navigation, the overall interaction model, and how the user accomplishes their overall goal.

A UX/UI designer has the skills, knowledge, and expertise to work at both the application/site-wide resolution and the screen resolution. They can zoom into the screen resolution when that’s what’s required, then zoom back out to the application/site-wide resolution to work on the bigger picture.

Expertise is Not a Zero-Sum Game

There’s a common belief that anyone who tries to do both UX and UI design won’t produce quality work The old mantra “Jack of all trades. Master of none.”is often recited in these instances.

This thinking assumes that learning is a zero-sum game. That if you’re a UX designer, then you couldn’t possibly also do UI design work well. You’d never have enough time or opportunity to learn the necessary skills to master both effectively. This just isn’t true.

Think of it this way: It’s quite possible to be both a highly-skilled UX designer and an excellent ukulele player. (In fact, there are several excellent ukulele-playing designers in our community.) Putting in all the hard work to master the ukulele doesn’t make your design skills deteriorate. Why would learning UI skills suddenly deteriorate your UX skills?

When skills overlap, there’s added benefit. There’s not a whole lot of overlap in the skills needed to master both the ukulele and UX design. However, there’s a fairly large overlap in the skills needed to master both UX design and UI design. Mastering what’s necessary at an additional level of design resolution will make you a better designer, not a worse one.

There’s nothing special about UX and UI skills. We could easily be talking about service design skills or chatbot design skills.

Skills are something anyone can learn. Put in the effort, get lots of practice, and find a good teacher and mentor. You’ll successfully learn all of the skills you need.

Designers with the right motivation and find themselves in the right opportunity can put in the hard work to master both UX and UI skills. You frequently see this with hardworking designers in organizations where they’re essentially a design-team-of-one. They have no option other than to build up their UX and UI skills together.

The Challenges of Hiring UX/UI Designers

It’ll take time to master both UX and UI design. When you’re looking to hire someone, you’re looking for someone who has been working in design for a while.

Not every designer has developed both of these skill sets. The pool to recruit candidates from is much smaller than when you’re seeking a UX designer or UI designer. The smaller pool will make hiring more difficult.

While UX/UI designers are in growing demand, there are not many available. The laws of economics dictates that they should demand a higher salary than their more plentiful counterparts. It may even be higher than if you hire both a UX and a UI designer separately.

This all means looking for a UX/UI designer will take longer and cost more. If you’re in an geographic area where there are very few people with both UX and UI skills or your salary budget is too small, a UX/UI designer may be outside your reach.

A Growing Number of UX/UI Designer

Every year, more designers are acquiring the expertise they need to tackle both UX and UI work. As teams become smaller and more agile, there are more opportunities for designers to expand their capabilities. This will steadily increase the number of available designers capable of doing both UX and UI work.

Teams currently staffed with both UX designers and UI designers would benefit by providing growth opportunities to acquire their complementary skills. By expanding everyone’s skills, the team itself becomes more agile. This is an effective way to deliver better designs faster.


As your team grows, you’ll need a strategy that ensures you’ve got the right design delivery capability. In our 2-day, intensive Creating a UX Strategy Playbook workshop, Jared Spool will work directly with you and your team leaders to craft your ideal strategy. Together we’ll ensure your team always has the necessary skills they need to deliver their best designs possible.

We cap each workshop off at about 24 attendees. This gives Jared plenty of time to work directly with you on the ideal strategy for your team. Learn how your team can deliver better-designed products and services.

Zooming In and Out of UX Design Resolutions

March 26, 2019

In 1968, world-renowned designers, Ray and Charles Eames, created a 7-minute short film called Powers Of Ten. The film starts with an overhead shot of a couple taking a picnic in the park. A narrator explains we’re seeing a 10+00 meter view.

Through an amazing progression, the camera starts to pull back, showing us views from 10+01 meters, then 10+02, 10+03, and so on, until we’re looking at the Milky Way galaxy at a resolution of 10+21 meters. The camera then reverses direction, zooming back in, until we see cells, DNA, molecules, atoms, and finally electrons at a resolution of 10-14 meters. The movie is mesmerizing and a technical wonder for its time, especially considering that this was before the advent of computer-generated animation.

Ray and Charles Eames Power of TenRay and Charles Eames Power of Ten. Courtesy and © 1977, 2019 Eames Office, LLC (eamesoffice.com)

Every time the camera zooms to a new power of ten, we’re treated to a completely different view of the world we live in. The camera never shifts its view horizontally or vertically. It’s always focused on the same point. Yet, what we see never looks the same twice.

The resolution of each zoom level has changed, by a factor of ten. Each pixel now shows us different information, at a different visual resolution.

At the 10+00 meter view, we can clearly see the blanket. Yet, at 10+05, the blanket has completely disappeared from view and we’re now looking at the city of Chicago and Lake Michigan. The blanket’s been encoded into a single pixel in that view of the city.

Starting with Screen Experiences

We can think of user experience design also as a series of resolutions. They aren’t as precise as the Eames’s Powers of Ten. However, each resolution is pretty distinct on its own.

Back in the 1970s, before we called anything UX, those of us who worked on building easy-to-use systems focused primarily on the screens. The computers of that age were primarily mainframes and minicomputers. Users would enter data through dumb terminals, often referred to as “green screens.”

We wanted to make sure each screen was efficient, effective, and usable. We studied instances where mistakes commonly happened. We iterated over the screen’s design, to ensure that the operators could enter data quickly and comfortably. Users were often trained, so making the system self-evident was less of a priority.

Next Up: Application and Site-Wide Experiences

Unbeknownst to us, we were working at a low level of resolution. It would take us more than a decade before we’d zoom out to a new resolution.

When personal computers came about, the dumb terminals went away. The designs we created now had more than a single screen. They formed applications and websites that our users had to navigate.

The screens were still there, but now we had to help our users. It’s far less likely they received any training. This required that we change the way we worked from the screen resolution.

We now had to think about the design of menus, wizards, and profiles. Concepts, such as progressive enhancement, helped us keep the overall flow moving and the level of detail tailored to users’ needs. Our designs had to become intuitive and obvious as to what to do next.

Zooming Out to Organization-Wide Experiences

When mobile devices became more prevalent, our users found themselves often interacting with multiple applications or web sites as part of their total experience with our organization. We could no longer focus on just the single application or site. We had to think about experiences that spanned multiple applications and multiple sites, along non-digital touchpoints, like our salespeople, guest services, or support centers.

In what we now call Service Design, we moved to a resolution that expands the users’ experiences across a greater time and distance. The digital components of the experience still need design at the application/site and screen levels, but the challenges we’re tackling at the organization-wide level are very different.

At this level, we’re dealing with different organizational departments and their business needs. We’re coordinating the user experiences, not just for a single customer, but for all of our customers, users, employees, and partners.

Each Resolution Demands Different Tools and Methods

Much of the Powers of Ten film is about how the park looks from space. The images shown fall into the world of astronomy.

Astronomers have a range of telescopes they use. These include small tripod-mounted telescopes for home use, observatory-sized telescopes, big radio telescopes, and even space-based telescopes like the Hubble.

Each of these telescopes does a different job. As they get larger and more sophisticated, the telescopes can look deeper into space, picking up details that others can’t see. What the astronomers can see changes based on the power of the telescope.

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

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

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

Like the astronomers, we need to adjust and change our tools when we want to work at a different resolution. These different tools require new methods and techniques. The change in scale requires us to think differently about what we’re building.

Challenges Change at Different Resolutions

In addition to changing tools, the challenges we face also change. Let’s say we wanted to work on reducing pollution from human waste.

The Powers of Ten film starts with a couple having a park picnic at the 10+00 meter view. At that resolution, the big pollution challenge is dealing with litter. We might consider how many waste cans are placed in the park and how often they should be emptied.

When the Powers of Ten camera backs out to the 10+05 meter view, we’re now looking at the entire city of Chicago. There’s still a pollution challenge, but at this scale, we need to think about it differently. We would work on city-wide waste and landfill management. We would address how much garbage a city like Chicago generates and how we’ll manage its collection and disposal. It’s a very different problem than how many waste cans go into the park.

At the 10+07 meter view, we’re now looking at all of North America. The pollution challenge will focus almost entirely on climate change issues. And when we pull back to 10+08 meter view, we can now see the entire planet and the objects floating around it. Now we need to contend with the growing problem of space junk.

UX Design Challenges Also Change

No matter which challenge we would pick, the nature of the problem and potential solutions will change depending on the resolution level. This is just as true with design resolutions.

When we’re focused on a single screen, we’re paying attention to whether our users can enter the data efficiently without making mistakes. We want to assure that any information presented is easy to understand and matches what the user needs to achieve their objective.

When we zoom out to the application/site-wide level, we’re ensuring the flow between screens is logical. We want to reduce the number of steps and make it easy to navigate.

And when we are working at the organization-wide level, we’re focused on coherence amongst interactions throughout the entire customer journey. We want to find ways to make the changes from one touchpoint to the next seamless.

Each change in resolution requires a different set of skills. They are all still UX design skills, but because the problems and tools change, the skills necessary to solve those problems and operate those tools will change.

Designing in an Ecosystem

In their film, the Eames showed us 36 resolutions by simply zooming the camera out and then back in. So far, we’ve talked about 3 UX design resolutions. Might there be more?

Out beyond the organization-wide resolution, there seem to be design challenges created when no single organization is in charge. This is different from most service design problems, where a final authority can use their role power to make a decision. For example, a large electric utility company working to improve the customer’s journey has a single CEO who can be the decider on whether a UX investment should be made.

Yet, what happens when we don’t have a single point of authority, such as a CEO, who can make the decision? What if we need to get different organizations to work together, with no single authority in charge?

For lack of a better name, we’ve been calling this the ecosystem-wide resolution. It’s a resolution we’ve only started seeing a few years ago.

The Internet of Things is an ecosystem that’s emerged. We now have smart light bulbs, microwave ovens, and thermostats and each vendor of those things makes its own control application. That means, if a homeowner has three light bulbs, each from different manufacturers, they need to know which app controls which bulb.

How might we design a coherent control system when we don’t have any authority over what other manufacturers make? This is a fundamentally different problem from working under a single point of authority at the organization-wide resolution. We need to develop skills in persuasion that we’ve not needed before.

Designing When There are No Screens

After the Powers Of Ten film zooms out to the galaxy resolution, it quickly zooms back into the picnic scene. The film continues zooming in, showing the person’s skin cells.

Is there a resolution that smaller than screens? We think this is where new work being done in voice and chat might come in.

Voice and chat deal with words, not screens. In some ways, it’s just a new interpretation of the command line interfaces from days of yore. But there’s a new twist, we’re now applying artificial intelligence and machine learning to it.

Again, our challenges for creating great designs at the Voice/Chat resolution are different from designs at the screen resolution or the application/site-wide resolution. The tools need to be changed here too.The old tools from our existing resolutions do not prove to be as useful.

Resolutions Change How We Think About Our Teams

The Eames film showed us there was a connection between what we think of as outer space, our planet, cells, and atomic science. These aren’t discrete sciences, but interrelated disciplines. You can’t work in one without understanding the others.

We didn’t really understand that applications and websites were different from screens until we’d gotten a handle on designing for screens. At that point, we realized we still had hard problems to solve. Yet, the tools and techniques we’d created for screens weren’t helping us with those hard problems. We had to develop new ones.

Now, as new resolutions appear, we can see that we need to develop our skills and techniques to handle them. We can be prepared for the switch.

Having teams ready to handle the new resolutions gives us a competitive jump over those organizations that aren’t thinking that way. We may not know what those new resolutions will require from us, but just knowing they’re there helps us get an advantage. We can use this knowledge to deliver better-designed products and services.


Get your team ready to handle the different design resolutions of your organization with a comprehensive strategy. Join us for our Creating a UX Strategy Playbook workshop to build a strategy playbook covering your user’s entire experience.

Through our partnership with Thoughtworks, we’re now offering workshops in Europe, in addition to Center Centre’s facilities in Chattanooga, TN. See the schedule and agenda at the workshop website.

Build Up Your Team’s UX Design Capability.

March 22, 2019

We’ve found what makes great design leaders different from the rest. Great design leaders put substantial effort into inspiring, coaching, and developing the skills of the teams they’re leading. In the process, they build a culture of continuous learning, which in turn, continuously builds up their organization’s UX design capability.

The more UX design capability the organization has, the more likely they’ll deliver well-designed products and services. It’s a win-win situation. Teams become more capable and the organization delivers better user experiences.

A Workshop Focused on Building UX Skills

While studying the strategies successful design leaders employ, we’ve found they focus much of their time building up the UX design capabilities of the teams they work with. More than 30 out of the 130 strategies we’ve identified are dedicated to building the UX skills in their organization.

That means we dedicate almost one-third of our 2-day intensive Creating a UX Strategy Playbook workshop to focus on the strategies you and other design leaders can implement to grow your team’s UX design skills and strategy. There isn’t any other workshop we’ve seen that goes into this much depth.

Strategies for Building UX Design Capacity

For example, we noticed that many design leaders employ a strategy of constantly monitoring the UX competencies of each of their UX team members. By keeping close tabs on what each team member’s strengths and weaknesses are, design leaders can tailor opportunities for each team member to grow.

Some strategies are simple, like having team members put their work on the wall. They then institute regular critique sessions, which allows team members to review each other’s work, and share their process and influences. When the more seasoned UX designers on the team are constantly sharing their work, the less-skilled team member can reflect on how they’ll improve their own process and techniques.

Engaging in activities like open design studios, helps team members new to design, see a process that generates new ideas and explores alternatives to different design solutions. Because practice and reflection is built into every design studio, it creates is a fantastic opportunity for designers to grow. Plus, they are fun!

Building Skill Growth into Day-to-Day Work

One aspect of our research we found really interesting, is that we don’t see design leaders hosting training workshops or employing the infamous brown-bag lunches as successful strategies. These out-of-context training attempts rarely provide benefits to team members.

Instead, successful design leaders are adept at building skill growing activities directly into everyone’s daily routine. They look for opportunities to add practice and reflection into their team’s work-in-progress.

This creates an environment of experiential learning, which is proven to be faster and more effective than conventional classroom-style training. Team members see opportunities to apply their new skills directly to the work they’re neck deep in. They get a chance to practice new skills and reflect on how they might improve. Everyone gets better.

Create Your Team’s Skill-Building Strategies

Bring your team’s leaders to our Creating a UX Strategy Playbook workshop and put together your own playbook of team development strategies. When you return to work, you’ll know exactly what it takes to improve the skills of your team.

Register for one of our upcoming workshops here. We’d love to see you there. Grow your team’s capability right away.

Where Do Most Folks Learn UX Skills?

March 15, 2019

In our Creating A UX Strategy Playbook workshop, we do an exercise I absolutely love. It’s easy and fun. You can try it with your own team.

I start by asking everyone in the room to write down a list of five to eight things they’ve accomplished at work over the last week on a blank page. Any major accomplishment they’re proud of works. This usually takes a few minutes, as they go through their calendar and try to remember what they’ve done.

Once they have their list, I ask them to write a number from zero to a hundred next to each accomplishment. The number represents how well school prepared them to complete that accomplishment.

If the things they learned in school completely prepared them for the work involved, they give that accomplishment a shiny 100. If school didn’t prepare them for any aspect of that work, they give it a big zero. Or they estimate some number in between.

What Did School Prepare Us For?

After they give a number to every accomplishment, I ask them to stand up. Once everyone is standing, I tell anyone whose highest accomplishment is a 10 or less, to sit back down. I’m always surprised when one-third of the room immediately sits down. For these folks, school didn’t prepare them for anything they’d accomplished that week.

I then say anyone whose highest number is a 20 or less can sit down. Then a 30, 40, and 50. Usually, by this time, two-thirds of the room is now sitting down.

I continue with a 60, 70, and 80. At this point, there’s usually one or two people left standing. Maybe 4. Rarely more.

I’ll ask them what their highest number was and what the accomplishment was. Often, what helped them with their accomplishment was some advanced course they happened to take. Maybe they learned how to create a user research moderation script, a particular statistical method, or a method for designing a set of icons.

Finally, I’ll ask them what the second highest number was on their list. More often than not, it’s zero. Out of all their accomplishments that week, school only helped them with one.

If We Didn’t Learn At School, Where Did We Learn UX Design?

We learn most of the skills and knowledge we need every day at work. Even for those of us who went to a school that taught UX design, most of what we need can’t be taught through formal education.

So much of what we need is specific to the organization we work in, the people we work with, and the products and services we work on. We need to learn who the users are and what they need from our designs. We need to learn how to best deliver that work.

When someone new joins our team, they need to learn what we already know. When we bring in colleagues from other parts of our organization, we need them to come up to speed on how we got here. Everyone needs to know our process and how we perform our specific UX design techniques.

What we think of as ‘textbook skills’ aren’t the most important or critical parts of our work. It’s everything we learn after we finish school that determines what we’re capable of accomplishing.

Is Our Workplace Designed to Help Us Learn on the Job?

Most of what we learn is picked up on the job. How well have we designed our workplace to support learning?

Design is the rendering of intent. If our intention is to have the best skilled and knowledgeable teams, have we done a good job of rendering that intention?

We’re seeing more design leaders take an intentional approach to creating a culture of continuous learning. They hold design critiques, create mentorship opportunities, and make sure design work is visible and “on the wall” so others can see each designer’s underlying process.

UX designers find accomplishing work is easier when everyone they work with has developed their own design expertise. When our developers, product managers, and stakeholders have a better understanding of what makes a good design good (and what makes bad designs bad), they’re more likely to appreciate our design work and can even help make better decisions themselves.

As our teams grow, design leaders need to ensure everyone can contribute effectively. This means everyone will need to grow the necessary expertise to make those contributions.

Where will everyone gain that UX design expertise? On the job. It’s up to us to make sure we’ve designed the best workplace to make that happen.


Building a culture of continuous learning will empower your team to deliver the best products and services possible. Your team will learn new skills and better practices, making your organization more design mature. Create an action plan to boost your team’s design skills and expertise at our Creating a UX Strategy Playbook workshop.

These workshops fill up quickly. We limit the space so Jared Spool can personally spend time with each team that attends. If you’d like to get Jared’s insight on build your team of self-described unicorns, you’ll want to reserve your spot right away.

Driving Product Teams To Become More Design Mature

March 12, 2019

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

In an ideal world, we’d assign a couple of UX folks to be full-time members of those product and service teams. These UX folks would work alongside the developers, product managers, and other team members. They’d keep the needs of the users top of mind, ensuring every aspect of the product or service delivers a great experience.

However, in the real world, teams would squander those resources. Most teams we work with aren’t ready to have full-time UX folks assigned to their projects.

That means, as design leaders, our real job is readying those teams to deliver great designs at a more effective level. We must increase the design maturity of those product and service teams.

The Five Stages of UX Design Maturity

Through our research, we’ve identified five common stages that product and service teams go through, as they become more UX design mature:

Stage 1: Dark Ages – The team is entirely focused on meeting the business and technology challenges, without considering the user’s experience at all.

Stage 2: Spot UX Design – An emerging design leader within the team struggles to deliver products and services with improved user experiences.

Stage 3: UX Design As A Service – Executive support to form and grow a centralized UX design team comes to the organization.

Stage 4: Embedded UX Design – Teams bring on their own UX design capability, separate from the centralized UX design team, to deliver enhanced user experiences.

Stage 5: Infused UX Design – Non-design members of the team have developed sufficient UX design expertise to, alongside the team’s UX designers, deliver market-leading user experiences.

We find there’s a tendency for design leaders to want to assign a design maturity to their entire organization. They’ll tell us, “Our company is somewhere between UX Design As A Service and Embedded UX Design.”

It’s not useful to think of maturity this way because each team inside the organization will be at their own maturity stage. For example, in a medium-sized organization, it’s not unusual to have a team or two make it all the way to Embedded UX Design, while many other teams are in the UX Design As A Service stage, and still some other teams at the Dark Ages stage. Some teams are producing great products while others have no idea that user experience is something they need to think about.

By knowing which stage a team is at, a design leader can tailor how the organization’s UX designers provide the best assistance. The designers can meet the team where it’s at, enabling the team to deliver the best designs.

Design During The Dark Ages

When a team is in the Dark Ages stage, they are consumed by shipping something that technically works and meets its business objectives. If they’re thinking of users at all (and often they’re not), they’re thinking: If users want it, they’ll figure it out.

A team at the Dark Ages stage needs a gentle introduction to user experience. The team members need to realize there are people out there who have to use what their team is delivering.

Exposing team members to real users can often be a positive awakening. Seeing how users interact with their design helps them realize their decisions have consequences. The team members may not know what to do to improve the design yet, but just knowing something can (and should) be done is an important step.

Trying to rush is the biggest trap a design leader can encounter with a team at the Dark Ages stage. If a design leader comes rushing in playing the UX Police with standards to follow and procedures to adhere to, they’ll alienate the team who will shut them down.

It’s important for the design leader to realize the team will transition on their own schedule. The best thing to do is to help those team members realize they’re making design decisions.

Those design decisions have consequences. By making smarter design decisions, they can get improved outcomes. That awareness is what helps a team in the Dark Ages progress to the next stage.

Arriving At Spot UX Design

Teams arriving at this second stage try, for the first time, to deliver a product with a better user experience than what they’ve delivered in the past. This is the first time the team has shown an interest in their users.

Smart design leaders can take advantage of their team’s desire to improve their user experience. Design leaders can show how iteration with user feedback can improve a design over time.

Because the team has never previously paid attention to any design issues, there are usually glaring issues that are easy to fix. Teams find basic UX design principles very helpful at this stage.

One commonly effective technique at this stage is to restate the team’s business goals in terms of user experience goals. For example, if the team has chosen an objective to increase new account sign-ups, the design leader can show problems users have during the sign-up process. Connecting how an improved UX can help the team attain their business goal shows the team how UX is a tool they should add to their business toolbox.

Like dealing with teams in the Dark Ages, it’s tempting to try to accelerate the team through the Spot UX Design stage. Design leaders need to balance the team progressing at their own rate against introducing basic UX design concepts.

For organizations that haven’t formed a centralized UX design team yet, the next step is to rally executive support to make an investment in UX design. If a centralized UX design team already exists, the design leader’s challenge is to find the resources to move the team beyond Spot UX Design.

Creating An Internal Design Agency

The UX Design As A Service stage begins when an executive invests in creating a centralized, internal design team. That team then supplies UX design resources to the product and service teams.

UX Design As A Service teams always find themselves resource constrained. There are more product and service teams that need help than the centralized team can service. The UX design leadership must decide which teams will get the most assistance.

As new product and service teams emerge from the Spot UX Design stage, further executive support will be required to grow the centralized team. The more design leadership demonstrates how the business wins with better design, the more support they’ll garner from the executive team. That support will generate more resources to give to new teams.

The biggest struggle at this stage for many design leaders is shifting from a reactive approach to design to a proactive approach. The leaders train the product teams to bring them into their design process earlier. Proactive design teams get input on how everyone understands the problems, instead of just executing a pre-ordained (and often substandard) solutions.

Ironically, a major milestone during the UX Design As A Service stage is when a product or service team becomes frustrated with the centralized design team. When that team feels they aren’t getting enough design resources, they’ll start asking for their own designers. At this point, this team is ready to move to the next stage.

Embedded Designers: A 24/7 Design Resource

In the Embedded UX Design stage, the product or service team hires their own UX professionals. These folks report directly into the team’s own management. They are no longer available for work on other products or services.

Embedded UX professionals deliver the team long term continuity. Whereas before, when using centralized design resources, they constantly had to train every new designer assigned to their product. Now, an embedded designer eliminates that frequent, disruptive training.

The embedded designer now can design across multiple releases and versions. They can research and develop a deep domain knowledge about the products and the challenges users face.

The trickiest part of this stage is keeping any embedded UX professionals in the loop with the centralized team. (The centralized team won’t go away, as they have other, less mature teams to continue supporting.) The embedded folks need to hear what’s happening elsewhere in the organization, to create coherence between all of the organization’s products and services.

The embedded UX professionals will work closely with the developers and product managers on the product team. This close working relationship will expose their UX skills, knowledge, and experience to the rest of the team. Over time, that exposure will lead to final maturity stage.

Infused UX: When Non-Designers Design

What triggers this final stage is when the non-designers on the team start making good quality UX design decisions. Those decisions result in outcomes that are now much better than before.

UX design is a learned skill and developers and product managers can learn it. By spending close time with their team’s embedded UX professionals, they start to pick up the basics. Over time, they become design fluent themselves.

This provides real benefits for the organization. The designers no longer need to approve or oversee every design decision. Designers no longer need to specify ever design detail in exacting precision. Good design happens no matter who is making the decisions.

It takes a long time to get to this point, but the benefits are clear. The products and services the team now produces are head-and-shoulders better than anything the team has produced before.

Organizations Benefit When Teams Mature

The evidence in the marketplace is clear. Organizations become more competitive when they deliver better-designed products and services.

To improve the design quality of those products and services, individual teams need to increase their own design maturity. Design leaders play an important role, but that role changes as the teams transition from one stage to the next.

Design leaders need to understand where a given team currently is in their journey. Using that information, they can tailor how they support the team.

It takes a long time to transition teams to the next level of maturity. Yet, when they do, the entire organization benefits.


The mix of maturity throughout an organization is what makes a design leader’s job challenging. No two leaders will face the same challenges. In our 2-day Creating a UX Strategy Playbook workshop, you’ll learn how to adapt your UX strategy to best fit the teams within your organization.

You won’t find a better way to identify the UX strategy your team needs. Choose the right approach from more than 130 strategies that have worked in organizations just like yours. Register today.

UX Strategy: Amplify Your UX and CX Insights

March 8, 2019

Experience is at the core of an organization’s brand. It’s the experience that dictates how our customers and users think about us as an organization. Deliver a great experience and customers sing our praises from the rooftops. Deliver a poor experience and they’ll tell everyone they know how badly we treated them.

Our organization’s products and service teams depend on both our UX and CX efforts to ensure we deliver a great experience. Yet, without a thoughtful, well-tuned strategy to make it happen, the UX and CX folks might as well be yelling into the void.

Amplify Your UX and CX Insights With A Well-Honed Strategy

The best way to craft a strategy that will amplify your UX and CX insights is to benefit from the successes of others. Over the years, we’ve compiled more than 130 proven UX strategies and built them into a 2-day workshop.

When you and your UX/CX leadership attend our Creating a UX Strategy Playbook workshop, you’ll review every strategy. You’ll select the strategies that have the most potential to move the needles of your key initiatives. You’ll identify the most beneficial strategies for your team to put into action right away.

Strategies for Promoting Every Aspect of Experience Design

Over the two days, we’ll focus on strategies to:

  • Communicate an experience vision that builds alignment and support on how great our products and services could be.
  • Win over key executives and stakeholders and gain their backing to execute important strategies.
  • Inform your product roadmap with strategic research that gets to the core of the problems customers need solving.
  • Install metrics that will demonstrate where teams are making improvements and isolate where there’s still work to be done.
  • Identify where teams need to improve their UX design skills to tackle the more complicated challenges.
  • Build up a solid design leadership capability, to carry the vision forward and give product and service teams the support they need.

This is the Strategy Workshop Your Organization Needs

As you leave the workshop, you’ll know exactly what needs to happen next. You’ll have a solid action plan for improving the products and services your organization delivers. And you’ll have a leadership team that’s ready to make it happen.

It took us more than a decade to design this workshop. We’ve condensed incredible insight into 2 days of roll-up-your-sleeves strategy building.

It’s hard work, yet you’ll leave completely energized. This is the workshop your organization needs. The feeling of empowerment and confidence to bring your organization to the next level is something you won’t get anywhere else.

Register Today.


These workshops fill up quickly. We limit the space so that Jared Spool can personally spend time with each team that attends. If you’d like to have Jared apply his vast experience on your organization’s strategy challenges, you’ll want to reserve your spot right away.

Sometimes A User is Just a User

March 1, 2019

Every few lunar cycles, we come across another post decrying how UX professionals should never use the term user to describe the people we’re designing for. The authors assert the term is too generic, dehumanizing, and possibly offensive. ”Users are people who are addicted to drugs!” they exclaim.

In one such post we recently encountered, the author said they’ve switched to always using customer instead of user. They want to ensure everyone on the team knows that the people who use their designs have paid for the design.

In our practice, we have a basic principle: Use the term that helps our colleagues best relate to the people whose lives we want to improve. That could be a customer. It could be a doctor. And, sometimes, the best term is just a user.

Not All Users are Customers

Customer is a great term when a person, in fact, makes a purchase decision. But that’s not always the case.

Take, for example, a roadside assistance application that comes as a benefit of an automobile insurance policy. The users of that application could be the customers of the insurance company. At some point, the purchaser of the policy may indeed be in need of roadside assistance.

However, it could also be one of the purchaser’s family members. Often multiple household members share a vehicle. Not all of them are the customer. Only the purchaser is.

This is an instance where user is a better term than customer, because not all users make purchasing decisions. The distinction between a policy purchaser and a non-purchaser household member doesn’t factor into the design choices the design team needs to make. The few times customer would matter is in an instance when the application demands a policy number, which only the policy purchaser may have access to.

Not all Customers are Users

We researched people using roadside assistance. In that research, we found an interesting use case: A parent who purchases roadside assistance coverage for their college-attending child. The parent wants the peace of mind that their child will be well cared for.

In this common use case, the purchaser isn’t covered by the policy, because they live in a different state from the student. Only the student can use the application.

Customer is a meaningful term here, but it only applies to the parent, who isn’t using the application. In this case, user is still the best term for the person who uses the app to take advantage of the roadside assistance benefit.

When There are Better Terms than User

For the roadside assistance application, we could use the term driver, assuming we believe only drivers use the application. If there’s a chance that the passenger of the vehicle might be the person invoking the service, then it won’t apply.

Again, our goal is to help everyone on the team relate to the people we’re designing for. We want to choose terms that give us the best clarity.

In a recent project involving a medical ultrasound diagnostic device, we found ourselves rarely using users because it didn’t help us make our users relatable. Instead, we chose to get specific about who was using the device.

Most of the time, a trained ultrasound technician operates the diagnostic device. However, it’s designed for a nurse or a doctor to also operate it. In some cases, the patient or their caregiver would want to interpret the images on the display. (For example, when a couple is looking at their unborn child.)

For the device’s design team, user isn’t a useful term because each of these people will use the device in a different fashion. The design team needs details about the role each person plays in the diagnostic session. (This is an instance where personas can be useful.)

Shared Understanding is the Goal

User isn’t always the right term to describe our users. Yet, sometimes it is.

Ironically, we need to think of our design team as our users. What will help them understand who they’re creating the product or service for? If there’s a better word than user, then we’ll certainly use it.

But, we don’t want to make things more complicated than they need to be. Getting our teams on the same page is hard enough. We shouldn’t let our language get in our way.


Design teams are most effective when they’re working with a shared understanding. In our 2-day Creating a UX Strategy Playbook workshop, we’ll work together to craft your UX strategy to deliver better-designed products and services for your users. Even if users isn’t the right word to describe them.

Identify the UX strategy your team needs. Choose the right approach from more than 130 strategies that have worked in organizations just like yours. This workshop will kick your organization into high gear. Register today.

UX and CX: Same Language; Different Dialects

February 26, 2019

The Difference is in Their Origin Stories

Some people will tell you that the difference between the customer experience and the user experience is whether we’re talking pre-sales or post-sales. These people believe the CX is what happens before the product or service is purchased. The UX is everything that happens after the purchase.

Other people will tell you that UX is a subset of CX. These people believe the UX only includes when users are interacting with a digital product or service. The CX is the overarching experience, including any non-digital activities users engage in.

And still other people will tell you that CX is a subset of UX. These people believe CX only embodies the experience paying customers have, while UX includes everyone, whether they made the purchase decision or not.

If senior leadership believes one of these differences, they’ll use that belief structure to dispense responsibilities throughout the organization’s CX and UX teams. However, none of these beliefs seem to determine what makes successful CX and UX teams.

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

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

The Origin Story of CX

The modern customer experience team has its roots in the 1960s Mad Men era. In those early days of advertising, everyone thought a great tagline and jingle was all that they needed to persuade customers to purchase.

Then pioneering marketers discovered that not all customers are identical. People who live by themselves do not purchase the same products as people with children. People who live in cities do not buy the same products as people who live in rural areas. The science of market segmentation was born.

As marketers refined their knowledge, they moved beyond simple demographics to other factors, such as attitudinal psychographics. It wasn’t just about where a customer lived, but their attitudes towards things in their life.

Marketers started collecting more data. Market research transformed into marketing analytics.

In the early 2000s, voice of the customer research became popular. This research worked to identify how to satisfy the needs of customers.

The birth of social media showed marketers that their most effective marketing tool was a great experience. When someone had a great experience, they told all their friends. Word-of-mouth advertising was more powerful than any other medium.

CX was then popularized by industry analysts, most notably at the firm Forrester Research. Executives and senior marketing leaders went to Forrester’s conferences and heard stories of companies benefiting from great product and service experiences. To get these benefits, they created teams to spearhead their organization’s own CX efforts.

The Origin Story of UX

The modern user experience team has its roots in 1960s human factors and ergonomics. In the early days of complex technology, like airplane cockpits and nuclear power plant control systems, we realized that human error was costly. If we could design systems that eliminated errors, we could save lives.

When the personal computer appeared, products needed to become “user friendly.” Usability became a focus for products.

In 1993, Don Norman coined the term user experience. As the web made information available, UX teams took on the job of providing great information architecture, interactions, and visuals in their designs. The focus on apps broadened the scope of UX teams.

The UX team was there to collaborate with product developers and deliver better-designed experiences.. This ensured their products and services provided the most value.

Blurring the Boundary at the Moment of Purchase

From the beginning, CX’s mission was to market and sell products or services. CX teams know they can only succeed if the organization delivers the best experiences possible for their users. And while UX’s origins are focused on delivering those great experience, they can only do that if people buy the product.

There used to be a boundary at the moment of purchase separating CX and UX. What evolved into CX was responsible for everything that happened up until that moment. What evolved into UX focused on everything after that moment.

But that distinction is no longer helpful. That boundary is now blurred.

CX teams are concerned with the design of their products and the experience it delivers. They can’t succeed if they focus only on what happens before the sale.

UX teams are concerned with ensuring their products demo well and have the right features to sell. They can’t succeed if they focus only on what happens after the sale.

Same Language, Different Dialects

Because of the vastly different origins of CX and UX teams, they approach their common goal from very different perspectives with very different skills and tools. It’s as if they’re speaking the same language, but with very different dialects, almost to the point of not understanding what the other is trying to say.

CX has its roots in marketing analytics. CX teams are very comfortable with large sample sizes from surveys and analytical data. They love quantitative models. They are at home with what customers say they like and need.

Meanwhile, UX has its roots in behavioral science, primarily cognitive science and ethnography. UX teams work well with small sample sizes. They love qualitative methods. They focus on how people behave with the product.

CX and UX teams are trying to accomplish the same thing, using different sets of skills. For example, they both try to encapsulate user differences with personas.

But CX personas are very different from UX personas. The former is more about segmentation differences, while the latter is more about behavioral differences. This creates confusion when teams aren’t careful in understanding their origins.

Shifting from Roles to Skills

Some organizations let an unhealthy turf battle form between the CX and UX teams. Effective senior leadership prevents this turf battle by integrating skill sets.

Both CX and UX are critical to the success of an organization that desires to become a market leader. Product and service teams need insights that both the CX and UX perspectives provide.

In the most effective teams, the senior leadership moves the culture from roles to skills. Instead of trying to assign different responsibilities to separated CX and UX teams, they focus on creating a single team with both CX and UX skills and knowledge.

Creating an integrated team, with both the skills of large-sample quantitative analytical modeling and small-sample qualitative ethnographic studies, provides a powerful combination. Integrated teams have a wider toolset to apply to complex challenges.

Integrated teams provide a deeper understanding of what users truly need from the organization, who, in turn, deliver better-designed products and services. After all, that’s the ultimate goal of both CX and UX efforts.


If you want your UX team to work more closely with your organization’s CX efforts, you’ll need a plan. In our 2-day Creating a UX Strategy Playbook workshop, we’ll work together to craft your plan and give you the strategy you need to deliver better-designed products and services.

You won’t find a better way to identify the UX strategy your team needs. Choose the right approach from more than 130 strategies that have worked in organizations just like yours. Register today.

Learn What It Takes To Craft Your Experience Vision

February 7, 2019

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

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

  • When setting organizational priorities, the experience of your users and customers is at the top of the list.
  • Your executives and senior leadership clearly see the value and importance of design.
  • Because your experience vision is based on your research, your organization is focused on building what your users need.
  • Innovation initiatives are steeped in what your customers need, not in whiz-bang gadgetry.
  • Everyone understands what “done” means: when your users are having the experience you’ve described in your vision, you’re done.

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

We start our Creating a UX Strategy Playbook workshop with a full morning learning how to create a strong experience vision for your organization. You’ll see different approaches design leaders have implemented. You’ll even craft your own vision.

We’ll focus on how you can gain executive buy-in to your vision, to help spread the message across the organization and make it a priority. In the afternoon, we’ll discuss how to get the research you need to drive the ideas in the vision, and how that can influence your product roadmap.

On the second day of this intensive workshop, we’ll focus on the skills your teams need to help promote and socialize the vision throughout the organization. Your design team will become essential evangelists, connecting the message in your experience vision to the day-to-day work of their product teams.

See the complete agenda for the Creating a UX Strategy Playbook workshop.

Craft Your Organization’s Experience Vision

We have upcoming workshops in Chattanooga TN, London UK, Hamburg Germany, and Manchester UK. Or we can bring it to your organization.

Bring your team leadership and change the way your organization works. Start delivering better designed products and services today.


P.S.

We limit each public workshop to 24 people, so I can work closely with you on your strategy. Don’t wait, because our workshops fill up quickly. register today.

How We Craft A Great Experience Vision Story

February 5, 2019

Ernest Hemingway once wrote, “Writing a story is easy. Just take out a sheet of paper and stare at it until your forehead starts to bleed.”

Writing a story for an experience vision can be difficult for our teams. We’re trying to predict what using our product or service could be like in the future. It’s hard enough to write about the present. Describing the future can be a daunting task.

Many teams fall into a trap. They believe they must predict what the future world of technology will be like. That quickly spirals into bad science fiction, trying to predict AI, alternative interaction methods, and other tropes best left to Sci-Fi futurists.

An Experience Vision isn’t a Science Fiction Story

For most experience vision stories, we don’t need to invent some new, futuristic technology. We don’t need to spend time exploring and wowing people with something they’ve never seen before. If we tell the right story, everyone will focus on the experience of the user.

Our vision story shouldn’t be set too far in the future. Five years out is good enough. Think of the technology you had five years ago. How truly different was it from what you have now?

Usually not that much. A few new, useful features, but mostly the same.

Remember, Apple’s Siri made her debut seven years ago. The Apple watch is more than three years old. And they weren’t the first of their kind.

Most “New technologies” like voice and wearables have been around for a while. Our five-year future vision should be set in a technological world that seems much like today’s.

We Need To Put The Experience Vision First

At the center of our great experience vision is the users’ experience. When we’re imagining a future story, we’re focused on one question: What’s the best experience for our users we can imagine?

All designers share a superpower. We all have the uncanny ability to solve well-defined problems.

I’ve worked with hundreds of teams. I’ve never met one that when presented with a solid understanding of how users struggle with our design, couldn’t come up with a wall full of great solutions.

Some of those solutions will be good. A few might even be great. Even fewer might be implementable. And, in all of that, there might be one that’s even practical and customers would pay for.

Start With The Experience of Today’s Users

When we understand the problems that frustrate our users, we have no trouble arriving at viable solutions. To craft a compelling, great story about the user’s future experience, we start with the user’s current experience.

We need to spend time with our users, listening and watching how they move through their day in the current world. When we do this, we’ll see what frustrates them. We’ll see where they spend time doing things that our designs could handle automatically. We’ll see how we can make the overall experience more delightful.

It can’t just be the UX researchers who spend time with our users. Everyone who we want to help compose the experience vision (and to subsequently sell it to the rest of the organization) needs to have this exposure.

When all the contributors have the same understanding about our users’ current experiences, they’ll join us in creating possible solutions. They can help us answer the critical question: What’s the best experience for our users we can imagine?

They’ll be sold on the solution because they’ll have had a say in its creation. They’ll understand the experience vision’s importance and how it’ll change the way we do business in the future.

Those team members will be our best advocates. With their help, our organization will deliver better-designed products and services. That’s the power of a great experience vision.


Organizations see a dramatic improvement in user experience adoption through a great experience vision. Teams that create and socialize a great experience vision give everyone a hook to hang important decisions on. In our 2-day Creating a UX Strategy Playbook workshop, you’ll learn how to craft a compelling and exciting experience vision for your organization.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Germany. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

The Experience Vision: A Self-Fulfilling UX Strategy

February 5, 2019

The engineer reviewed his options one last time. While he was making an important decision, it was like many other important design decisions. If he made the right one, his work would be lost to obscurity. Yet, if he screwed the design or engineering up, it would be all anybody would talk about.

It was 1990 and the team was a year away from shipping the brand new Apple Powerbook 100. This was Apple Computer’s first foray into what we’d now call a notebook computer. In fact, it was one of the first notebook computers ever made.

The engineer was leading the design and engineering for the power supply component. Creating the best power supply component was the center of his world, even though it’s something nobody else is suppose to pay attention to.

For the last year, he’d been working on several alternatives. Now it was time to decide which alternative he’d use.

In any other job, he’d look at the best practices of his competitors. But, there were no competitors.

In the past, he had a standard set of questions to help him choose the best alternative. Which is cheapest to manufacture? Which would be fastest to market? Which would be most reliable?

Which alternative gets us closer to the Knowledge Navigator?

Apple’s Experience Vision Project

In 1987, Hugh Dubberly’s design team at Apple Computer embarked on an ambitious project. Their job was to imagine what Apple’s products might look like 23 years in the future.

To show what they thought computing could be like in 2010, they crafted a series of stories. All of the stories were about everyday people doing great work with the assistance of cool Apple technology that hadn’t been invented yet, but could be.

For example, one story described a television director scouting out locations. Wearing special glasses, the director would take pictures by positioning his thumbs and forefingers into the shape of a picture frame.

That gesture would signal the glasses to record spoken notes, the location, and position of the camera. The director could choose the best shots from the images and notes.

The 1987 Knowledge Navigator

Dubberly’s team made a few of the stories into short videos. Their most popular video proved to be The Knowledge Navigator.

Apple Computer’s imagined Knowledge Navigator from 1987

In the Knowledge Navigator video, a university professor reviews his upcoming class lecture. He updates his lecture’s underlying research with new data, collected from universities all over the world. (Apple managed to predict the Internet six years before Tim Berners Lee invented it.)

Eventually, he starts a video chat with a colleague at a university on the other side of the country. (Skype also hadn’t been invented yet in 1987.) A flat tablet-like computer assists all of this with some sort of talking AI avatar, high-speed internet, and built-in video—none of which was available in 1987.

Tablets aren’t remarkable today, but back then, they were non-existent. 1987 saw the debut of the IBM PS/2 and the Apple Computer Macintosh II. These big box computers with slow processors took five minutes to boot up.

In the Knowledge Navigator video, the professor opens his device and the AI character immediately starts reviewing the professor’s calendar—no delay. In 1987, people only used keyboards and mice. For many people this was the first time they saw a user do sophisticated actions using only voice and touch.

Apple’s Self-Fulfilling Prophecy

It was a lucky coincidence that the first iPad shipped in 2010, the year Dubberly’s team had depicted their Knowledge Navigator story. However, It wasn’t a coincidence the iPad shipped with most of the Knowledge Navigator’s features. The Knowledge Navigator had become a self-fulfilling prophecy for Apple.

The story caught the imagination of the company. Apple executives proudly showed the video to the shareholders. Everyone in the company was excited to figure out how to build it.

While it would take 23 years to come to fruition as the iPad, the Knowledge Navigator was guiding many of the projects in between. Looking back at the Powerbook, the Newton, the MacBooks, the iPhone, and the MacBook Air, it was clear that Apple was using the Knowledge Navigator to set their direction.

Experience Vision: A Flag To March Towards

Dubberly’s team had created experience visions. Each story described a future vision of the user experiences Apple’s customers could have.

You can think of an experience vision as a giant flag on a tall post in the sand, far away on the horizon. The flag is too far way to walk to anytime soon. It will take years. (In the case of the Knowledge Navigator, it was 23 years.)

Yet, because the flag is visible from where we currently are, we can set a directive: March towards the flag. Everyone in our organization can have the same directive. We’re all marching towards the same point of convergence, even if we’re starting someplace different.

Our marching steps are often baby-sized steps. The Powerbook 100 power supply engineer wasn’t trying to invent the power supply capability of the iPad. He was taking baby steps to make a smaller power supply than what had been in previous Macintosh computers.

It’s All About The Experience

What made the Knowledge Navigator experience vision so effective was how little attention Dubberly’s team paid to the product. Instead, all the attention was paid to the professor’s experience with the product. What was his day like? How could he seamlessly achieve his objective?

(Having now watched the video hundreds of times, I can tell you the professor apparently works in 5-minute chunks and gets his lectures done at the very last minute. Oh, the pleasures of tenure. He also ignores his mother.)

The vision primarily attended to the professor’s experience. It communicated what the outcome of the design needed to be. It didn’t specify how the design would achieve that outcome. If you watch closely, you can see that there’s very little detail on the UI or the mechanics of the professor’s work.

An experience vision represents an experience we can aspire to. We need to contrast that experience to our users’ current experience. In the case of the Knowledge Navigator, they relied on the fact that everyone had current, frustrating 1987 technology on their desk.

A viewer of the video would immediately see the difference in the experience. They could say: Yes, that’s exactly what I want!

The Power Of A Great Story

What makes an experience vision work is a great story. A great story isn’t just heard, it’s also told. It’s passed on.

For an experience vision to work, it needs to be something discussed in meetings. Everyone needs to ask the question What will get us to the vision?

That implies everyone needs to know the story. It has to be catchy and contagious. It has to stand the test of time.

It’s hard to come up with a great story. There’s no formula for success. (If there was, Hollywood would never put out a crappy movie.)

Dubberly’s team created several stories, but only the Knowledge Navigator caught everyone’s imagination. It was the right story at the right time.

What makes a story great is when everyone in the organization can see their own work inside the vision. Even though the Knowledge Navigator video never showed the power supply, the Powerbook engineer could see his own work there. If we can see our own work in the vision, we can imagine the baby steps we might need to get there.

Visions Aren’t Always Science Fiction

Dubberly’s team based their stories on the current research in human-computer interaction. They’d been paying attention to the innovations coming out of research labs like MIT’s Media Lab. They explored what it would be like if these futuristic inventions became commonly available.

However, most experience visions don’t have to tap into future science. We can look to currently available technology that hasn’t made it into our users’ experiences.

A few years back, an insurance company we worked with came up with this comparatively boring vision story:

During a storm, a customer has a tree fall on their car garage, damaging both the house and the car inside. The customer immediately takes pictures of the damage to their car and the building. They upload it to the claim center, which immediately opens a claim.

Within an hour, both an emergency construction crew and a rental car are dispatched to the customer’s home, preventing further damage from the ongoing storm and ensuring the family still has transportation. Within 24 hours, a contractor has been chosen to repair the home damage permanently and their vehicle is in the body shop. The family has received a debit card to automatically cover any out-of-pocket expenses incurred during the restoration process.

This story may not seem as far fetched as the Knowledge Navigator seemed in 1987. Yet, it’s was a good 5-year vision for the insurance company.

They could start taking baby steps right away, starting with using customer-supplied pictures to open claims and implementing an emergency dispatch capability. It would be years before they implemented everything in the story, yet everyone knows what to do.

Creating An Experience Vision From “How Might We…?”

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

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

We can ask, “What’s the best experience we could imagine providing our users?” We look closely at the frustrations and imagine an experience where those frustrations don’t occur.

Next up is to determine the timeframe of the horizon. Apple used a 23-year horizon, but that’s a very long timeframe for a vision.

Most of our experience visions come closer to a five-year horizon. Five years is far enough away that we could see eliminating whatever legacy issues are currently holding us back.

For the insurance company, they could imagine upgrading their old mainframe technology to support customer-supplied damage photos, but they believed it would probably take the full five years. (It only took two, which surprised everyone involved.)

The story now comes together. In 5 years (or whatever horizon we pick), what is the best experience we can imagine delivering? How will people’s lives be better because we’ve removed all the frustration?

The Experience Vision At The Center Of A UX Strategy

The best experience visions are contagious. They take on a life of their own.

You’ll know your experience vision has taken off when other people start explaining it to you, to make sure you’ve heard it.

It’ll really take off when you hear a senior executive, at some organization-wide meeting, use your story to explain where the organization is heading. They’ll be telling the story (probably getting a few details wrong) to everyone, saying “This is where we need to go.”

What happens next is magical. The organization starts to focus less on what the competition is doing. Decision makers ask What baby steps will it take to get closer to our vision?

Your user experience strategy becomes more real when there’s an experience vision to guide it. It shifts from “we need to make great designs” to “we need to make this be our users’ experience.”

The experience vision becomes a visible example of what great design can be in the organization. And that, in turn, pushes the organization to deliver better designed products and services.

Organizations see a dramatic improvement in user experience adoption through a great experience vision. Teams that create and socialize a great experience vision gives everyone a hook to hang important decisions on. In our 2-day Creating a UX Strategy Playbook workshop, you’ll choose the strategies that will work best to get total adoption of your experience vision.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Germany. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

Is User Research Driving Your Product Strategy?

January 25, 2019

I spend time with each team to help them choose the strategies right for their organization’s needs.

Is your team’s user research driving your organization’s product strategy? Here’s how you’ll tell:

Does your organization’s senior leadership understand the value of great design?

Are you producing enough research for every product and service on your roadmap?

Is your user research influencing critical product decisions?

Are new product features actually what your customers need and want?

Is it easy to gain access to users for in-depth research?

Are your team’s research insights directly influencing the strategic direction of the organization?

Are critical decision makers helping to drive your team’s research agenda?

Without the right user research strategy, the benefits of your team’s user research will only go so far. Your team can’t do their job if they don’t have access to the right users. Their research insights won’t make your product better if decision makers aren’t considering their research.

Breaking through to make user research more effective is hard. It often requires tailoring a new approach to the culture and structure of the organization.

We’ll never have enough resources to do everything we want. We need to know how to use the resources we have most effectively.

Breaking Through The Strategy Barrier

We’ve done the hard work, so you don’t have to. We studied how design leaders all over the world have raised the effectiveness and influence of their team’s user research. From this, we cataloged dozens of strategies that teams can put into action right away.

We’ve made those strategies the core of our 2-day intensive Creating a UX Strategy Playbook workshop. You and your team will review each strategy to identify which actions will be the most effective for meeting your team’s goals.

You’ll return to your office with a solid plan of action. You’ll know exactly what you need to do to increase senior leadership’s understanding of your team’s value. You’ll put your team’s customer-focused research insights into the center of critical strategic product decisions. You’ll have no trouble getting access to the customers and users that will influence the future direction of the organization.

Building A Strategic Plan You Can Make Happen

With constrained resources, the strategies you choose are critical. You need to ensure every step you take is going in the right direction.

That’s why I work with every team that attends the workshop directly. I learn what their biggest challenges are and then, together, we come up with a plan. A plan that will increase the influence and effectiveness of user research throughout their organization.

The new strategies you come away with will inspire you. In turn, you’ll inspire the teams you work with. They’ll start producing better designed products and services. Your organization will be the envy of the industry.

“This was a really valuable, transformative workshop. I highly recommend it.” — Terence Nelan from CIT

Join me in Chattanooga, TN or Hamburg, Germany for an upcoming workshop.It will transform how you think about user research strategy. And it will change the way you deliver products and services forever.

In Chattanooga, we still have room for our February 6-7 workshop. The April 10-11 workshop has plenty of room, but it will fill up soon. We just opened registrations for our Hamburg, Germany workshop on June 25-26. Registrations have already started arriving, so don’t wait too long.

Markets are led by companies who know their customers and users better than everybody else. Create a user research strategy that will make your organization the leader in your industry.

I can’t wait to work with you on your user research strategy,

Jared M. Spool
Workshop Leader
Creating A UX Strategy Playbook workshop

P.S.
We limit every workshop to 24 attendees. Don’t wait to register because they fill up quickly. Register now.

Progress Frameworks As A Competitive Advantage

January 23, 2019

A few years after the birth of the web, we embarked on a research project to study the questions people asked in online medical forums. We studied thousands of questions people had posted in forums related to chronic diseases.

As our research progressed, we noticed a pattern starting to emerge. People’s questions changed based on where they were in their journey with a particular disease.

For example, if the person was recently diagnosed, they had all sorts of questions about what the disease was and its implications on their lives. Whereas, if they were well within their treatment process, many of their questions had more to do with those treatments.

In our analysis, we found a dozen different chronic illness stages. In each stage, a person’s questions changed. They would need different information to manage their illness and live a quality life.

Progress Frameworks Help Us Structure Our Research

Now it seems very obvious to us that people’s needs changed as their life with the illness progressed. Yet, at the time it wasn’t obvious at all. Websites providing medical information were constructed like encyclopedias that never took an individual user’s needs into account.

Through our research, we stumbled into creating a framework around a patient’s progress with chronic illness. We could use the patient's progress framework to make sure we saw the entire picture.

What we found was that many information providers only focused on a couple of the stages. People newly diagnosed and those living with the illness were missing answers to their important questions. Using the framework, we could ensure we knew what questions to address and how to structure the information.

There Are Many Progress Frameworks to Help Us

Over the years, we’ve learned about other frameworks. Bob Moesta has popularized a great framework that shows how shoppers progress through a purchase.

Bob Moesta's Product Framework
Bob Moesta’s Purchase Progress Framework

It starts before the shopper even realizes they need to buy a new product and progresses up until the new product owner is getting benefits from their purchase. At each stage of shopping progress, the shopper needs different information about how the product will benefit them. Teams can use this framework to ensure they answer all the shopper’s questions, before the customer even asks.

Anthony Ulwick also has a framework he calls the Job Map. He uses this framework to map out how a customer meets an unmet need.

Anthony Ulwick's framework called the Job Map
Anthony Ulwick’s Job Map Progress Framework

It’s brilliant because, like Moesta’s framework, it starts before the customer has the unmet need. Then, in eight steps, it walks through the stages until the customer no longer has that need. By studying their users at each stage, teams can learn how the customer’s specific needs transition.

Amy Jo Kim has a 4-stage Mastery Path she uses to describe how users learn new products. It extends beyond the oversimplified notion of novices and experts, and is based on her extensive research into how people learn to play and become immersed in online games.

Amy Jo's Mastery Path
Amy Jo Kim’s Mastery Path Progress Framework

Like the other frameworks, Kim’s shows that the user’s needs change as they progress through each stage. The needs they have when they’re first onboarding with the product is different than when they’re later mastering advanced capabilities. Teams can use her framework to ensure they’re covering the full lifecycle in their research.

User Research Become Our Competitive Advantage

If we want to produce competitive, innovative solutions, we need to uncover needs that none of our competitors are addressing. In most cases, we don’t need to invent something brand new the world has never seen.

Instead, let’s only look in places where our competitors aren’t looking. We use a progress framework to tell us where to start looking.

In most industries, competitors just copy other competitors. User research can become our competitive advantage, especially when we’re using a progress framework to focus where nobody else has explored.

When we understand our users needs better than everyone else, we can be the market leader everyone else chooses to follow. This is how we’ll deliver better quality products and services than our competition.


In our Creating a UX Strategy Playbook workshop, we spend the first afternoon taking a deep dive into how to make user research a competitive driver in your organization. You’ll walk through more than a dozen alternative approaches, including using customer lifetime journeys and progress frameworks, to uncover critical customer unmet needs before your competitors do.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Germany. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

Jobs To Be Done: An Occasionally Useful UX Gimmick

January 17, 2019

It was puzzling. Jay (not the study participant’s real name) was sitting in front of a desktop computer with an open browser. Yet, it was his phone that he grabbed.

On his phone, Jay immediately opened his bank’s mobile app. Once he logged in, he glanced at his account balances, then proceeded to move a chunk of money from his checking account into his home equity account.

I was puzzled why he didn’t use the bank’s website instead. “The phone app is so much easier,” Jay responded. “I do this transfer every month and I find I can get it done faster using the phone.”

This fascinated me. Jay had used the bank’s website many times. He showed me how he paid bills using it. But when it came to transferring money, it was easier for him to use the mobile app.

Hiring and Firing

Jay needed to make a money transfer. To resolve that need, he chose the mobile app over the bank’s website.

We can frame Jay’s choice as two actions: For the job of transferring the money, Jay fired his bank’s website and he hired his phone’s mobile app.

The choice users make to fire one thing and hire something different is important. Why are they making that choice? If they choose to fire our design and hire someone else’s design, are they trying to tell us that our design is deficient in some way?

Why did they make this choice? The question points to a problem of impedance. In Jay’s case, the website provided some impedance to the job of transferring money. The mobile app resolved that impedance.

If the bank’s design team understood the impedance and what caused it, they’d have several options. They could market the effectiveness of the mobile’s apps transfer capability, to get other customers to take advantage of it. Or they could update the website’s design to remove whatever was slowing Jay down, to make it a more desirable solution in the future.

That’s the power of Jobs To Be Done. JTBD (as the kids call it) is a new approach to talking about choice and impedance. The Job is the progress a user is trying to make. (In this case, Jay is trying to make progress paying down his home equity loan.) The user hires and fires products or services to make that progress efficiently.

Where Jobs To Be Done Came From

Jobs To Be Done was popularized in Clayton Christensen’s books on innovation and disruption, primarily his 2016 Competing Against Luck. (It’s most telling by the subtitle of the book: The Story of Innovation and Customer Choice.) Christensen’s is the best resource we’ve found at describing how JTBD leads to innovative products. It’s what you’d expect from Harvard Business School’s foremost authority on how companies can deliver innovative products.

Yet, Christensen’s book doesn’t describe how to get there. This has spawned a small army of consultants to fill in the gap. Each of them has written their own books, including Chris Spiek and Bob Moesta’s Jobs-to-be-Done The Handbook, Alan Klement’s When Coffee & Kale Compete, and Anthony W. Ulwick’s Jobs To Be Done Theory To Practice.

In each case, the various authors talk about uncovering how the users make choices. Ulwick tends to be more focused on what people do with the product or service. The others tend to be more focused on progress that people are trying to make.

(This difference has created a bifurcation in the JTBD community, which can get contentious at times. That contention makes it hard to understand what JTBD offers at times. Several UX professionals have told me they turned away from JTBD, because they were turned off by the turf wars and excessive salesmanship of the consulting practices.)

The Framing of Jobs To Be Done

The believers of JTBD tell us that when teams don’t know what their users hire a job for, they’re likely to make poor design and marketing decisions. In JTBD, marketing and design find common ground to ensure their product or service addresses the customer’s (or non-customer users’) unmet needs. This could be useful.

Not too long ago, in a study we did of insurance agents, we noticed several of them turned to spreadsheets for creating price quotes for their customers. They told us they’d chosen to build and use their own spreadsheets, instead of tools their insurance company’s IT department had built, because the IT’s tools were overly complicated.

We could frame the agents choice as firing the IT tools and hiring their spreadsheet. The customers’ Job to be Done is getting the customer an insurance quote quickly.

In other studies we’ve conducted over the years, we observed customers trying to resolve issues. Many of those customers chose to call a toll-free support center number and talk to a human customer service representative instead of using the available online knowledge center. Those customers told us they preferred the human interaction because it gave them confidence in the issue’s resolution.

We could frame these customers’ choice as hiring the call center representative and firing the knowledge base. The customers’ Job to be Done is resolving their issue with confidence. A Job to be Done is another way to frame an unmet need. It puts it in the simple context of a service.

Jobs To Be Done Forces A User-Focused Approach

Christensen’s basic argument is you’ll create something innovative by focusing on the job the customer needs done, especially if it isn’t being done by a current product on the market. You’ll solve a customer’s unmet needs in a way that nobody else has. Christensen is using JTBD to promote a user-focused approach to innovation.

What’s great is we now have a Harvard Business School authority promoting talking to customers. Christensen spends an entire chapter scolding business leaders for being too inward focus. He tells them to listen primarily to what he calls passive data, instead of the normal data that the organization is swimming in.

Passive data is hard-to-get qualitative data that will go beyond the market data. Christensen doesn’t say it, but passive data is what we would call user research. He argues you need to get out of the building and talking with customers, to uncover the true jobs those customers need to do.

User Research: JTBD’s Mystery Step

One of the best features of all these books on JTBD is the volume of case studies. Christensen’s book is full of them, as is Klement’s and Ulwick’s. Spiek and Moesta produced a podcast that’s filled with them.

We noticed pretty quickly that every case study followed a basic template.

Act 1: We meet the executive or senior stakeholder who is convinced they understand why customers are choosing their product.

Act 2: The executive/stakeholder discovers Jobs To Be Done.

Act 3: Because of the Jobs To Be Done work they did, the executive/stakeholder changed up the product or its market positioning.

Epilogue: Profit!

What intrigued us was the lack of specificity for whatever happened between Acts 2 and 3. Only Spiek and Moesta go into any depth of how they determined what the customer’s jobs are. Everyone else leaves it as a mystery step.

Spiek and Moesta use an interview process. In one podcast episode, they reveal their technique by sharing an interview they did with a course attendee about the experience that attendee had buying a mattress. (Christensen reprints the 8-page transcript of this interview in his book.)

In his book, Ulwick unironically outlines an 84-step process he calls Outcome-Driven Innovation. (Really. It’s 84 steps. No joke.) But he only describes the actual research in a single step:

Step 12: Conduct customer interviews to define the core functional Job-To-Be-Done. (The following 72 steps are a variety of activities to validate the team did step 12 correctly.)

This lack of discussion suggests that JTBD is user research agnostic. Any amount or quality of user research will produce the same results.

We know, from years of design practice, that the quality of user research matters. Inadequate or poor-quality research will not uncover strategically important unmet needs. Leaving the research details undefined opens a door for process issues down the road.

The Problem with Jobs To Be Done

It’s this lack of definition on how teams conduct user research that makes JTBD problematic. Not because we don’t know how to do it. We know a lot about researching unmet needs.

Suzanne Bödker’s Activity Theory first started talking about this in the mid-80s. Karen Holtzblatt and Hugh Beyer’s Contextual Design gave us techniques specific for products and services in the 90s. There are decades of work behind applying modern ethnographic techniques to everyday product and service design.

More recently, we’ve seen work in Indi Young’s Mental Models, Jeff Patton’s Story Mapping, Dan Brown’s work on discovery, Gerry McGovern’s Top Tasks, and tools like Jeff Gothelf’s Lean UX and Jake Knoff’s Design Sprints. All of these practices are about surfacing and focusing on unmet needs of customers.

The lack of definition is problematic because it sends the message that research isn’t a critical part of a JTBD approach. Reading Christensen, it would be easy to think that uncovering the job is simple and take virtually no time.

It’s disappointing that Christensen, in this well-written book that’s likely to catch the attention of many senior executives, never mentions of any of this work. He treats his Jobs Theory as if it was something wholly new and recently invented. (For him, it may seem that way. Maybe we haven’t done a good job of promoting our field of knowledge to those outside, like business school professors, who might benefit from that knowledge?)

None of the consultant’s books mention the expertise that many UX professionals have. Some, in trying to protect their consulting revenues, go so far as to try to position JTBD as a faster, better, and more effective alternative to UX, which makes it even more problematic.

(Jim Kallbach is working on a new JTBD book. We love Jim’s work and are confident he’ll do a great job of showing how JTBD can integrate into modern UX design practices in a way that the current books haven’t done.)

Jobs To Be Done is a Sometimes Useful Gimmick

Professional magicians, dating back to Houdini’s time and before, have used the term gimmick to describe a device used to perform an illusion without requiring any skill in the art of performing illusions. With a gimmick, you just turn a nob, press a button, or engage the device in some form and, voilà, the audience sees the desired magical effect. The audience never knows the gimmick was engaged. That’s part of the magician’s secret.

If you’ve ever seen a children’s first magic set in a toy store, that’s a box of gimmicks. Professional magicians use them too. Anytime you’ve seen someone sliced into pieces and then reassembled in front of your eyes, well, the performers used a gimmick to make that happen. (Sorry if I spoiled that illusion for you.)

There are non-magical gimmicks too. For example, a magnifying glass is a device that lets its user focus in on the detail of a small part of the world. You don’t need special vision skills to see that detail. Just hold up the glass and new details are revealed. (Like magic!)

JTBD’s framing of hiring and firing is a gimmick. It’s a device for revealing and gaining a shared understanding of the behavior behind unmet needs. That has its uses. (And it seems like magic when it works!)

When a team is inwardly focused and creating features or imagining benefits without finding out what customers really need, JTBD can help. It can get the team members all thinking what those unmet needs really are. It’s a nice way to force a user-focused approach to design.

Two Problems with Gimmicks

A problem with gimmicks is, you can’t use them all the time. We can’t walk through the world with a magnifying glass on our face. Nor does the hiring/firing framing work for all types of needs.

What are the jobs a banking customer would hire or fire the bank’s website for? That will differ, based on the specific user and their needs. Remember, Jay hired his bank’s website for bill paying but fired it for money transfers. What would he do for checking balances, seeing if a deposit cleared, determining if he can afford a new monthly car payment, figuring out how much he can spend on his upcoming vacation, or any other of the multitudes of activities.

Jobs to be Done can’t help with most complex products and services in the world today. Sure, we could apply it to specific features or functions (and maybe we should more often than we do).

Another problem with gimmicks is, you can’t learn to achieve the same result without it. Gimmicks while useful, will become a crutch. All professional magicians will use a gimmick now and then. However, the best magicians can perform illusions with common objects. They can borrow a common object, like your phone or your ring, make it disappear, and then, magically, make it reappear in a place you didn’t expect.

To perform that level of magic, they need to learn and hone their crafts of manipulation and misdirection. Using a gimmick doesn’t help them learn or hone these crafts. It’s a completely different set of skills.

The same is true of design. The gimmick of Jobs To Be Done only works in certain situations. However, we have to build innovative products that deliver compellingly great user experiences even when JTBD isn’t the right approach.

To get those results, we have to learn a different set of skills than JTBD. At best, JTBD is just a distraction from the real skills we need. At worst, it takes our team in a completely wrong direction.

We need to be careful declaring, as Christensen and his disciples have, that Jobs To Be Done is the be-all-end-all innovation process. Christensen’s case studies make his book great, they also make it seem like JTBD is simple to do.

The lack of acknowledgment that design and research play a role in Christensen’s process of innovation makes it problematic. Design and research are not only seen as unnecessary, we don’t even have to acknowledge these practices exist.

Informing our Jobs To Be Done Practice

Jobs to be Done has its uses. We need to understand the contexts where it delivers value and identifies alternatives when the situation is too complex to use it.

Jobs to be Done can’t stand on its own. We need to support it with the expertise we’ve gained over the last few decades while creating our design research practices. Before learning how to apply JTBD to a project, we’re recommending teams learn and start practicing the techniques from these UX design leaders:

There’s a trove of expertise there. It’s the background a UX professional should have when exploring the current Jobs To Be Done approach. With this expertise under their belt, they’ll see that JTBD is an occasionally useful gimmick and know exactly when they need to employ it.


The quality of your team’s user research matters. If you don’t have a strategy to identify and improve the quality of research you’re team is producing, you may be leaving design value on the cutting room floor. At our 2-day Creating a UX Strategy Playbook workshop, you’ll assess where your team is at and pick the best strategies to take your team to the next level.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Europe. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

Getting Closer To Your Users And Their Needs

January 15, 2019

There’s a game many of us played during our childhood. I’m betting you remember it.

In a group of many people, one person starts by whispering a phrase into a second player’s ear. The second player then whispers what they heard to the third person. This repeats until the message has transited through the entire group. Then the last person tells the first person what they believe the phrase was.

The last person’s phrase never matches what the first person said. In the United States, we call this the Game of Telephone. (In other countries, I’m told the game has other names, some of which seem culturally offensive, like Chinese Whispers or Russian Secrets. Whatever it’s called, the game is still the same.)

Unfortunately, the Game of Telephone isn’t just a children’s game. It’s what we adults do in our organizations, especially as we get bigger.

Communication Breakdown

When companies are small—startup small—we communicate frequently with our design’s users, often out of necessity. To survive with limited resources, we pay close attention to what the users want and what the customers will pay for. If we don’t, we run out of money and time.

As companies get larger, those close bonds start to break down between the users and the team designing the product. More intermediaries come into the picture. Eventually, there are many, many people playing the Game of Telephone. Our users far away at the start and our product design team all the way at the end.

The end user is frustrated, so they tell their manager.

The manager tells the person who purchased the original product.

The purchaser asks their salesperson from your company if there’s a way around the frustration. (There isn’t.)

The salesperson tells the sales manager.

The sales manager tells the VP of sales.

The VP of sales tells the chief product officer.

The CPO tells the head of product for your division.

The division head of product tells your product manager.

The product manager writes user stories and then creates Jira tickets.

You pull the Jira ticket and wonder how this ever became a thing.

We have a ticket that says “intelligent data export,” “forecasting,” or some other thing we don’t understand. We have no idea what the message started as. What was the problem the end user had that caused them frustration?

The way to win at the Game of Telephone is to eliminate the people in the middle. That’s true whether it’s children or companies playing the game.

Design Leaders Must Squash Message Distortion

Some companies manage to avoid this. Intuit, for example, has always had a strong cultural battle against message distortion. When Scott Cook founded the company, he instituted a policy where every employee had to meet and watch customers frequently. It’s part of their performance reviews. It’s baked into who they are.

At organization’s where it’s not baked in, design leaders need to make it a top priority to constantly push through the distortion field. They must find ways to get in front of their users. They must ensure key personnel—those who will make important design decisions, like product managers and developers—have regular, direct exposure to what frustrates and delights their users.

As an organization grows bigger, natural forces will continually try to insert people into the middle. Design leaders fight those forces by constantly highlighting the benefits their teams has made through direct exposure. Showing what they’ve learned from user research and how that research improved their products by making it their top priority.

The Game of Telephone doesn’t have to be the norm in the organization. It takes continual work to prevent the middle people from distorting the message. Design leaders who successfully keep the Game of Telephone at bay enable their organizations to deliver better designed products and services.


P.S.

There are many strategies design leaders can employ to keep the Game of Telephone at bay. Choosing the right one depends on their team’s current situation and the objectives of their organization. At our 2-day Creating a UX Strategy Playbook workshop workshop, you’ll choose the strategies that will work best for your organization. We look into strategies on how the team can break down the questions to build a shared understanding of the customer’s problems.

In 2019, we’ll be offering the workshop in Chattanooga, TN and in the UK and Europe. Seating is limited to 24 people in each workshop. You’ll want to make sure you and your team have seats reserved. Don’t delay, register today.

Creating Your 2019 Action Plan for UX Strategy.

January 8, 2019

It’s January. Time to be thinking about what new outcomes you’d like to see at the end of the year. How can you encourage your organization to deliver better products and services?

Imagine you could review the strategies that other successful UX teams have employed to make their organizations more design mature. You’re in luck, because that’s exactly what we do in our Creating a UX Strategy Playbook workshop.

In this workshop, you and your team’s leaders will craft your 2019 action plan for delivering better products. You’ll review more than 130 strategies other organizations have successfully employed.

For each strategy, you’ll ask yourself, could we do this? You’ll assess the kind of impact the strategy could have. You’ll determine if it would be easy or hard to implement.

The strategies with the most impact and are most feasible become the basis of your action plan. They’ll be what you’ll take home with you. They’ll be what you focus on for 2019.

When you and your team put these strategies into motion, you’ll see immediate improvements. Your organization will have new respect for the value of design. Your teams will deliver products and services with better user experiences. Your organization will become more design mature.

That will happen when you come to our Creating a UX Strategy Playbook workshop. There’s one coming up very soon. February 6-7 in Chattanooga, TN.

Can’t make the February workshop? We have one every two months in Chattanooga, TN. We’ll be announcing our UK and European dates for 2019 shortly.

Don’t delay. Put your 2019 UX Strategy plan into action right away. Sign up for the workshop today.

Dividing User Time Between Goal And Tool

January 3, 2019

Designers have to worry about two types of time their user spends interacting with their design: Tool Time and Goal Time.

Imagine the user wants to put together a presentation in Microsoft PowerPoint. They’ll spend some time refining what they want to say to their audience: What’s the key message? What are the right details? Are they being too confusing? Should they communicate with words, images, or charts? Other time they’ll spend making things bold, green, and flashy.

The difference between goal time and tool time is the increase in quality gained by spending the time. When the user is working on refining a presentation’s content, they are investing in goal time. The more goal time they can invest in, the better the quality their result.

In contrast, tool time, when extended doesn’t add to the quality of the result. If it takes twice as long to change a bulleted list to be a numbered list, the presentation won’t be better quality.

In fact, we can cut the amount of tool time in half without seeing any degradation in quality. That means, we leave more time for the user to put towards goal time.

When Mihaly Csikszentmihalyi talks about Flow, he’s talking about the ultimate goal time. Not all goal time achieves flow, but when it does, that’s when we see the best quality improvements. Creating a design that helps users reach the flow state is what we should strive for.

Flow is easily interrupted. Mihaly says it takes 20 minutes for someone to get into the flow state, but only seconds to lose it. Tool time activities, when they take too much attention, can break flow or prevent users from ever attaining it.

Imagine a woman visiting a website about pregnancy, fertility, and conception. She and her partner have been trying to have a baby for a while, but without success. Now she’s looking for information that could help them achieve this important goal.

The time she spends reading helpful articles is definitely goal time. If the articles are informative and well written, she’ll spend more time reading and become more knowledgeable. If she achieves flow, she’ll spend hours on the site without even realizing the time has passed. And, she’ll be happy about it!

However, the site’s navigation, the process for registering (so sponsors can send her “relevant” advertising emails), and fluff-piece articles that don’t say anything are just tool time. Working to minimize the time our user spends on these elements will only improve her overall experience, making her more likely to come back to the site and recommend it to her friends.

Do you know what parts of your design are tool time elements? Could you reduce or eliminate these elements without reducing the quality of the user’s results? Do you know where goal time comes in? Could you find ways to increase the user’s exposure to this part of the experience?


Learn where your users are spending goal time and tool time on your products and services. Implement a proven UX strategy specifically focused on this task and others important to you and your team. Create your custom UX strategy playbook during our two-day Creating a UX Strategy Playbook workshop.

Four Articles for a New Year

December 27, 2018

As we mature our UX craft, we’re realizing long-standing design leadership myths that have guided our work don’t really hold up to scrutiny. We have to be more deliberate about how we deliver value in our work.

It’s not a coincidence that our four most popular articles of 2018 look behind these myths to find the truth on what work practices make a difference. This is how our field matures, increases the design maturity in our organizations, and delivers better products and services to the world.

As you read these articles below, you’ll see that we’re no longer just collecting up any idea that might work. Instead, we’re forming an important foundation to what it means to produce great designs.

Net Promoter Score Considered Harmful (and What UX Professionals Can Do About It)

We were a bit taken by surprise how much discussion this article created. From our perspective, executives relying on NPS are grasping at straws for a way to tell how well their organizations are doing.

However, when you open the hood, you’ll find that there’s nothing in how Net Promoter Score data is collected or analyzed that stands up to inspection. UX professionals are caught between a rock and a hard place, trying to deliver a simple summary their executives could understand about the very complex interactions their organizations have with customers.

In this article, I explore why NPS doesn’t make sense once you start tearing it down and what UX professionals can do about that problem.

Continue reading on UIE.com.

Yes, Alan, There Is An ROI For UX Design

”How do I show the value of UX to my executives?” is probably the most common question we hear. When we’re trying to grow our efforts, we need our executives to understand what value they’ll see in return.

When Alan Cooper went on a rant, declaring that any executive who asks is probably not interested in hearing the answer, we realized we needed to talk more about how we explain value. There are very clear returns on investment for delivering well-designed user experiences, but our field doesn’t always know how to talk about them.

In this article, I explore how to formulate the answer to the value question. Design leaders need to be prepared for this question, so they can get the resources they need to do the job everyone needs them to do.

Continue reading on UIE.com.

Proactive UX Design: A Big Leap Requiring Baby Steps

Almost every organization’s UX design practice starts as a reaction. It’s a reaction to a sudden realization that without a better user experience, the organization won’t produce competitive results. Most of the advice around getting a UX design practice started in an organization is how to build a reactive UX design practice.

Yet, our research comparing successful and struggling organizations has shown that, at some magic moment, the design leaders need to change their tune. They need to move the organization, albeit slowly, in a new direction. They need to change into a proactive UX design practice.

This article talks about that inflection point of change. And we explain how successful design leaders have moved their teams into this new world of proactive UX design.

Continue reading on UIE.com.

Users Don’t Hate Change. They Hate Our Design Choices.

We found it amusing that this was our fourth most popular article this year. It’s a topic we’ve been talking about for more than a decade. Yet, it seems, many organizations haven’t realized the damage they do to their user experiences when they make jarring changes to their designs.

In this article, we tackle the myth that users hate change and that’s why they get angry when we put out a new release, even if the new release has a proven better user experience. (Anyone remember the Microsoft Ribbon?) I explore how to reframe the changes you need to make, so that your users love new updates, instead of mounting a full-scale revolt.

Continue reading on UIE.com.

Value and how to measure it were two of this year’s big UX themes. What will be 2019’s big themes? We can’t wait to find out.


P.S.

It’s not a mistake that these four topics drive many of the discussions we have in every one of our Creating a UX Strategy Playbook workshops. The 2-day workshop is how design leaders put together action plan for the bringing their teams and organizations to a new level of design maturity. We can’t talk about doing that without communicating and measuring our value. So, we dedicate serious time to it in the workshop.

You’ll want to join us at our next workshop. We limit the size of each workshop to 24 people. The workshop is most effective when you bring your product and development leadership teams, so you’ll want to register soon to reserve your seats. Develop Your Organization’s 2019 UX Strategy today.

Avoiding The Wrong MVP Approach

December 19, 2018

“We could make our customers happier and save the company a ton of money, all at the same time.” That was the pitch behind the innovation team’s new idea.

Yet, many at this 120-year-old insurance company weren’t convinced. They thought it could never work.

The innovation team’s idea was conceptually simple: The insurance company’s claims adjusters use photographs to assess the damage and fill out claims reports. Instead of sending professional photographers out to take the pictures of damaged vehicles and homes, they’d let customers send in their own pictures.

The company pays those photographers a lot of money. Plus, there aren’t enough of them, so customers often have to wait. Customers often need to be present when the photographers show up, which means missing work or other responsibilities. The current process is slow, frustrating, and expensive.

On the surface, it seems like a great idea. However, there are questions to resolve. Could customers take photos good enough for adjusters to do their job? These photographers go through extensive training to ensure the pictures capture the right information.

What About An MVP?

The claims processing product team was chartered with figuring out how to make something like this work. In the olden days, they would just dive in and build working functionality, hoping it would work great when launched. But, it never worked great.

To prevent a poor launch experience, the executive team had latched onto this idea of a Minimum Viable Product or MVP. They could create and deliver an MVP quickly, to see if this idea of customer-supplied damage photos might work for the claims adjusters.

What Exactly Is An MVP?

For many organizations, they’ve come to use MVP to mean a less functional, limited implementation application. Build it quick, get it into the hands of customers, and see how they like it.

Yet, a limited functionality version, for customer-supplied claims photos, would still be a lot of work. They’d need a way to upload the photos to the company mainframe systems, used for claims processing. They’d have to build something that attached the photos to the correct customer’s claim records. They’d have to change the adjusters’ workflow to let them know the customer had added new photos. That’s a lot of difficult system-wide changes for something that’s an unproven idea.

This isn’t how MVPs are supposed to work. Eric Ries, who coined the term in his book, The Lean Startup defined an MVP as something that “allows a team to collect the maximum amount of validated learning about customers with the least effort.” The innovation team could learn about customer-supplied photos with a lot less effort than building a limited functionality version. So, they did.

Iterate On The Learning

The team started by breaking down the questions they needed to answer. The first question was, could they get customer-supplied pictures that would be good enough for the claims adjusters?

To answer this question, they simply recruited a small handful of claims agents to help with an experiment. When those agents would get a call from from a customer opening a new damage claim, they’d ask that customer to send in some photos. Maybe those photos would be good enough?

Turns out, they weren’t. The customers didn’t know what the claims adjusters would need, so the pictures didn’t have the right information. (My favorites were the customers took smiling selfies of themselves in front of their damaged home. Fun pictures, but not good enough.)

The team iterated. They asked the same claim agents to repeat this experiment, this time sending the customers specific instructions on what to photograph. The pictures that came back were better, but still not good enough.

The team iterated a few more times. Eventually, they hit upon the right set of instructions to do the job. The pictures coming in from customers were now good enough for the claims adjusters to do their work.

MVPs: No Coding Necessary

Without writing any code, the team learned what they needed: customers could supply valuable pictures. That was only the first step, but it was a big one. (Next up: could they easily get those pictures into the existing claim system?)

MVPs often don’t need code, but teams forget this. Our organizations are so used to solving every problem with software that we forget that we can learn what we need by faster, more effective means.

The teams that use MVPs most effectively focus on what you need to learn first. Then they ask how they can best learn it. Often, you can avoid writing any code altogether.


You’ll want to join us at our next workshop. We’re limiting the size of each workshop to 24 people. The workshop is most effective when you bring your product and development leadership teams, so you’ll want to register soon to reserve your seats. Develop Your Organization’s 2019 UX Strategy today.

Consistency in Design is the Wrong Approach

December 12, 2018

Current Knowledge is a much better way to think about the problem.

Consistency in design is about making elements uniform—having them look and behave the same way. We often hear designers talk about consistent navigation, consistent page layouts, or consistent control elements. In each case, the designer is looking for a way to leverage the usability by creating uniformity. After all, if the user learns to operate the design in one place, why not have that knowledge transfer to the next. This is all good. But wrong.

For example, let’s look at a design decision our friends at Avis.com once made. At the time, they chose to use the asterisk (*) to denote optional fields instead of denoting mandatory fields. Less than 10% of the fields on the entire site are optional. If they were consistent with the outside world, entire forms would have every field denoted with an asterisk. That might create its own problems.

So, Avis.com’s designers did what designers are supposed to do: they made a choice. They chose to be inconsistent with practically every other form on the web. But they were internally consistent with themselves.

The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. “Is what I’m designing consistent with other things we’ve designed (or others have designed)?” is the wrong question to ask.

Instead, the right question is, “Will the user’s current knowledge help them understand how to use what I’m designing?” Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.

If the designers at Avis had asked, “Will the user know how to separate optional fields from mandatory ones?” they would likely have come to the conclusion that using asterisks to denote optional fields might confuse a user or two. They could’ve used a different typographic or visual solution, or resorted to the old-tried-and-true “(optional)” text next to the appropriate field label.

When you think about consistency, you’re thinking about the product. When you’re thinking about current knowledge, you’re thinking about the user. They are two sides of the same coin. We’ve just noticed that the designers who spend more time thinking about the users are the ones that end up with more usable designs.

Why do we gravitate to consistency? Because it’s easier to think about. You don’t actually have to know anything about your users to talk about making things consistent. You only have to know about your design, which most designers are quite familiar with.

Current knowledge, on the other hand, requires in-depth knowledge of the users. And that takes research time and investigative effort. It doesn’t come cheap, like consistency does. But it produces much, much better results.

Funny thing about thinking about current knowledge: when you’re done, your interface will feel consistent. Why? Because it will match the users’ expectations and, where they expect it to behave like something they’ve encountered before, it does.

(This has the interesting side effect of reinforcing the wrong thing. When you run into a site that feels consistent, you’re not likely to say, “Hey, those designers did a good job because they obviously researched what my current knowledge would be.” Instead, you say, “Hey they made things consistent. We should do that.” Thus, the cycle of poor practice is reinforced...)

My recommendation: anytime someone on your team starts talking about making things consistent, change the conversation to be about what the users’ current knowledge is.


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

Service Design: Pushing Us Beyond the Familiar

December 6, 2018

On this day, everything was different. Well, not everything. In fact, almost nothing. But almost nothing can seem incredibly dramatic, especially when you’re a trained observer.

The day before, our user had no trouble with the software application. While we were watching, he used it for hours exactly as the developers had intended.

Here we were, replicating all the conditions from the previous day, yet the way he used the software was completely different. His behavior had, literally, changed overnight.

Our study participant was the owner of an auto repair shop that specializes in mufflers, brakes, batteries, and tires. The application he was using was the customer tracking software, which followed each customer through their visit, tracked his shop’s inventory, and estimated and invoiced every customer work order. It practically handled everything.

Baseline: Friday

The day before had been a Friday. For this shop, Fridays are like most weekdays. Customers come into the store at a regular pace. There’s often a small rush first thing in the morning, and most of those customers have appointments and are already in the system.

On that Friday, we watched the shop owner process new customers. He’d get their name, the make, model, and year of their car, and the symptoms of their problem. He’d carefully and deliberately enter the proper information into the system, which in return, provided a proper estimate of the work.

Most of the time, this estimate turns out to be what the work actually cost, a fact the owner was proud of. Even more frequently, the estimate was lower than his direct competitor, whose shop was on the opposite corner. Another fact that made the owner proud.

The shop owner wasn’t a particularly fast typist. But on this Friday, he didn’t need to be. There were never more than two customers in the shop. He could enter all the data with his two index fingers, just like he usually did.

In between customers, he showed us how he loved the data the system tracked. He could tell that there were seasonal patterns to the types of repairs customers needed. Mufflers came in the spring, tires came in the fall, batteries in the winter. He could predict his inventory and make sure he had everything.

This application made his life easier, he proudly told us. It should. It cost a lot. (He told us that too.)

Chaos: Saturday

When we showed up on Saturday, there was already a line in the parking lot. These folks were new customers, coming to get an estimate on new work.

That’s when the application failed him. Instead of the shop owner poking the data into the application, he’d take a blank from and fill it out by hand. And instead of getting the information the application needed, he’d jot down the bare minimum from each customer.

Within 20 minutes, the waiting room was filled with new customers, all looking for an estimate. To move as fast as he could, the shop owner had to abandon his much loved application. If he didn’t help these folks, they’d go across the street and do business there. He couldn’t afford that and wasn’t letting a piece of software get in his way.

On Saturday, the software application he had praised just the day before was now his enemy. It was preventing him from getting his job done. He was inventing workarounds to bypass it.

Stumbling into Service Design

Unbeknownst to us, we had stumbled into a service design problem. Between Friday and Saturday, the application hadn’t changed. The user was the same user. What had changed was the context of use. Suddenly, something that was previously helpful was now an impediment to the business.

Because all this was more than 20 years ago, we had, at the time, never heard of service design. (In those days, we never used the term “user experience” either. That took a decade to catch on.) Because our work in those days focused on the design of software applications, that’s where we focused our energy.

Yet we couldn’t ignore this bigger picture thing happening to our user. And we didn’t know what to do about it.

Today, we’d know what to do about it. What we’d seen was a classic service design problem, and we now have oodles of techniques and tricks to find great solutions.

Now, many user experience professionals accidentally find themselves working in service design. They stumble into it, just the way we did more than two decades ago.

Service Design Is an Extension of Digital UX Design

Most of today’s user experience work is done on some sort of digital device. It involves an application or web site. Solutions involve moving bits around on a display.

However, that isn’t the “total experience” a user has. Our shop owner didn’t only type data into a computer and produce reports. For him, the digital experience was only a piece of a total customer service experience.

If we’re going to truly create better user experiences, we need to know how to create better non-digital user experiences. We need tools and techniques for doing that, just like the ones we have mastered for our digital user experiences.

Service Design Pushes Us Beyond the Familiar

In digital user experience design, we think about a lot of things. We conduct user research. We work on the visual design, the interaction design, and the information architecture. We focus on the written copy and put together a content strategy to manage it.

In service design, all those things still exist. We still need to learn about who is involved in the service scenario, understanding what their goals are and how we’ll tell what success looks like.

We need to ensure the experience looks good, feels right, and has everything the service participants need. And we need a process that gets the right information into the right hands at the right moment.

Think of an online chat capability for an e-commerce site—a tool customers use to ask about product details.

In a conventional UX approach, we’d focus on the bits. What does the chat window look like? How are messages displayed? What’s the noise or vibration it makes when a new message comes in? All of this is designed. All of it is intentional on our part.

Service design extends this scenario. When we push beyond conventional UX into service design, we now want to think about the experience of what is said in that chat window. How will the customer indicate which product they’re interested in? What will the customer service rep say in return? Is it scripted? Is there a research tool for the rep?

These details of the conversation go beyond conventional UX work, but are the centerpiece of service design work. That shift changes everything. Deep down, it’s the same interaction: using the chat window to find out info about a product. But our scope of design has extended into the service.

Extending UX Practices

Let’s look at user research: Today, many organizations conduct usability tests as their primary user research activity. They put their users in front of their digital designs and watch what happens. From this, they learn what works and what doesn’t, giving them insight in how to make the design better.

In service design, user research is still about learning what works and what doesn’t. Teams practicing service design still glean insight on how to make the design better from their user research. User research goals in service design are familiar to anyone practicing conventional user experience work.

However, to achieve these goals, we must extend our user research practices. Usability tests won’t work, because we’re not watching someone interact with a screen. They’re interacting with others. The simulated laboratory of the usability test won’t tell us the difference between a Friday and a Saturday at the auto repair shop.

For that, we need to go into the field. We need to use a full toolkit of ethnographic techniques. We may want to employ a Day In The Life study, or mobile ethnography. We’ll look beyond just the customer and explore the experiences of all the participants, including stakeholders and ancillary service personnel, such as a wholesale product buyer.

User research isn’t the only aspect of digital UX practice that we need to change when we start doing service design work. We need to look at how we prototype services, how we think about the information organized in the service delivery, how the service looks, and what behaviors we want each party to have when interacting in our designed experience.

It sounds like a lot. It is. But it’s not difficult to master. First, we learn the terminology and tools. Then, we practice them. With enough practice, it will feel natural.

Service Design is Unavoidable Today

Just like 20 years ago when our team visited the auto repair shop, teams today will get pulled into non-digital service design. It’s unavoidable.

As digital technology becomes more integrated into our overall experiences, we’ll need to start thinking about how our customers and employees flow from one area to another. We’re no longer in a world when we can design for just a single isolated online interaction, not thinking about what happened before that interaction or what happens after. And, we’re no longer in a world where we believe that every before-interaction and every after-interaction only happened online.

We’re now in a world where digital and non-digital are merging. And we need to be prepared to design in that overall experience.

Service design is no longer a “nice-to-know, someday we might do this” kind of thing. It’s become a “today, this is how we compete and produce the best damn experience for our customer” kind of thing.

As UX professionals, we need the skills and techniques of service design in our toolkit. Acquiring them will push us beyond what’s familiar to us. And that’s a good thing.


Learn how to help your organization create better user experiences, including better non-digital user experiences. Attend our two-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

Planning The Ideal UX Leadership Offsite Is Hard

December 4, 2018

Imagine you could put together the perfect UX team leadership offsite. Two days full days, where you and your team focus on choosing strategies that grow the importance of design in your organization. Your team would review what everyone is doing well and where the team needs to up their game.

In these two days, your group would explore your team’s work from multiple dimensions:

  • Where can your team have a greater influence on your organization?
  • How would your team advance better design in your organization?
  • Where can you improve the products and services you’ve been working to deliver?
  • How might you improve the capabilities of your team, so they’re better prepared to the handle bigger challenges that the future holds?

Over these two days, you and your team would conduct some serious reflection. There would be some difficult topics to explore and some hard discussions.

With skilled facilitation, you’d navigate those difficult conversations and emerge aligned. Your team will be excited about the solid action plan they jointly created. Everyone has now bought into doing what it takes to get the team—and the entire organization—to the next level.

It’s Hard To Pull Off A Great Team Offsite

Pulling off a workshop like this takes immense preparation. You would need to craft a rock-solid agenda that covers every aspect of how your team works—at the organizational level, with each other at the team level, and as individual contributors.

You would want to assess what you’ve already accomplished, to ensure you and your team have done all you could do. You would need the team to agree to make improvement a priority.

You would need your team to go beyond what they’ve always done. For the organization to attain a new level of design maturity, you would need strategies for tackling new, difficult challenges.

We’ve Done The Preparation So You Don’t Have To

While we didn’t think of it this way when we created it, it turns out our 2-day workshop, Creating a UX Strategy Playbook is a great team offsite. Team leaders have told us they’ve seen more positive results from attending the workshop than any other workshop they’ve put together.

That benefit comes because we’ve done all the hard preparation work. We’ve studied world-renowned organizations, looking at what made them successful. From that, we’ve identified 130 unique strategies that have helped organizations deliver better products and services.

We structured the workshop to get everyone attending on the same page. They spend more than 50% of the workshop in their teams, discussing which strategies would have the most impact. They identify which strategies would be easy and which would be challenging to employ.

From the workshop’s structured discussions, teams emerge bought in and excited about their most effective strategies. When they return to their office and the daily grind, they have a plan to shift their team—and the organization as a whole—to advance the role design plays. And because everyone’s on the same page, they’re doing it together, with a common language and understanding they reached during the workshop.

We set out to create a great way to discuss UX strategy. It turns out our Creating a UX Strategy Playbook workshop is also an ideal UX leadership workshop.

Bring your team and start making awesomeness.


Bring me to you. I visited four companies in November, conducting the workshop for them. In each one, they brought 30-40 UX, product, and development leaders together, to craft an action plan with complete buy-in. They are already reporting results. Let me know if you’d like to explore this option.

A Proven Method For Showing The Value Of Good UX

November 29, 2018

For a while now, this has been the most common question I get:

How do I convince people in my organization to take user experience seriously? I’ve tried giving brown-bag sessions on the importance of UX, but nothing has happened.

They’ve shared every case study they could find. Nothing changed.

I tell them that I’ve never had success with brown-bag intro sessions either. But there is a way to get user experience taken seriously.

When pressed for time, I often give the short answer:

You don’t have to. There’s a high likelihood there’s someone important in your organization who already takes it seriously. They just don’t know it yet.

However, there’s a more helpful, albeit longer answer. And it goes something like this…

Step 1: Start With Frustrations Caused By Poor Experiences

Organizations that aren’t fixated on creating great user experiences are usually saddled with poor user experiences. A great user experience only comes about through constant diligence and attention. If the organization isn’t paying attention, it’s unlikely they stumbled on one by chance.

We can measure the experience that comes from a product or service’s design on a scale that ranges from extreme frustration to extreme delight. At any given moment, the design is either frustrating or delighting the person using it. By definition, a user experience is good when it delights its users and poor when it frustrates them.

Yet, it might not be the direct users—those people who interact with the product or service directly—that a poor design might be frustrating. There are indirect users, often within the organization, that find the design frustrating. Here are some common examples we’ve seen:

Salespeople trying to sell a product that is hard to demonstrate or explain.The sales team is trying to get prospects to fall in love with the idea of a purchase. If a competitor looks simpler or the prospect doesn’t understand how the product or service helps them, they won’t want to sign up. A salesperson, looking to meet their sales goals, would find the product extremely frustrating if it’s causing them to lose sales.

Call-center management responding to a poor design that generates support calls. A product with a poor user experience might put an excessive burden on the call center team. The manager of the call center, always trying to keep their costs down, may very well be frustrated by the increased call volume, even when the answers are easy to dispatch. (“Have you turned it off and on again?”)

Production managers dealing with lost worker productivity. An internal application (such as a case management system) that has too many steps or is poorly integrated with other tools will force production work to take longer. This creates backlogs and slows down overall productivity.

Development managers watching their teams rewriting the interface code.When the developers get the user interface wrong the first time, they spend time refactoring it to be easier to use. A better informed design process could’ve gotten closer in the first release.

Development managers learning that built-out features aren’t ever used. It was a waste of resources to build functionality into a product that customers aren’t using, either because the feature wasn’t wanted or the product was too complicated for the users to take advantage of the features.

In organizations with a history of producing poor designs with frustrating user experiences, it’s usually not hard to find frustrated indirect users like these. If the designs are frustrating enough (and they often are), the indirect users can become the key to build awareness in the organization.

Step 2: Identify The Frustration Costs

Almost always, when there is extreme frustration coming from a product or service’s design, that frustration shows itself somewhere on the organization’s bottom line:

Frustration costs due to lost sales revenue. Sales are going to competitors, the salesforce is discounting to compensate, or customers are taking a long time to sign up.

Frustration costs due to increased support costs. Call-center representatives are spending time answering calls that come from the user’s poor experience.

Frustration costs due to lost productivity costs. Backlogs are requiring more working hours or preventing the organization from being efficient.

Frustration costs due to wasted development rewrites. Development costs are higher because the team rewrites the same code multiple times.

Frustration costs due to unused feature development. Development costs for never-used features is a resource that could’ve been used to build something else.

With a little digging, we can calculate these costs. If the problem is lost sales, we can ask the sales team to estimate the amount of the sales they’ve lost. Or if the sales team is discounting to win against a competitor with a more delightful design, we can add up the discounts they have to give out to win the business.

If the frustration costs are coming from support calls, we’ll calculate how much those calls cost. We find out the budget for the call center, then divide that by the overall number of calls they get. That gives us the average cost for each call. When we multiply that average by the number of calls needed to deal with frustrating user experience features, we have the cost of that frustration.

We can do something similar with the lost productivity numbers: Figure out how much those personnel are paid and calculate how much time is spent dealing with the waste from the frustrating user experiences, either working with it (production workers) or creating it (developers). Multiply the percentage of time by the total personnel costs and you have a rough estimate.

Often, these rough estimates are all you need to get someone’s attention. After all, if this is the first time the organization is thinking about user experience, it’s likely the costs are pretty high. In one instance, we found that the costs of handling password resets at a large bank were costing the call-center support team $75 million each year. That large number was enough to quickly get the attention of senior bank management.

Step 3: Find the Person In Charge Of Reducing Those Costs

This is where luck plays in our favor. In most organizations, especially large ones, there is already someone in charge of dealing with the costs of frustration. However, they may not realize it yet.

It’s very likely there’s someone already assigned to increasing sales. There’s someone in charge of reducing support costs. There’s someone with the job of making the production work more efficient. There’s someone who is very interested in making developers more efficient.

These people are often easy to find. And they’re rarely in the design team’s direct chain of management. They are often in parallel organizations, outside the design organization.

Once we find them, they’ll probably be surprised that we are thinking about their problem. It’s likely they’ve never thought about how the product or service’s user experience is a root cause of their issue. They’ve either never noticed the frustration, or if they have, they didn’t think anything could be done about it. (Or they were told it was too hard to fix.)

Yet, now we have numbers. An estimate of what this is actually costing the organization. And because our number is focused directly on their charter, they often have the role power and the political influence to make something happen. Suddenly, UX is important.

Step 4: Ask The New UX Champion To Sponsor A Lean UX Project

Chapter 3 of Jeff Gothelf and Josh Seiden’s seminal book, Lean UX: Designing great products with Agile teams, is called “Driving Vision with Outcomes.” They talk about how product and service teams have traditionally focused on features, by driving projects with requirements and deliverables. They suggest there’s another way.

“Lean UX radically shifts the way we frame our work by introducing back the strategic context for our feature and design choices and, more important, how we—the entire team, not just the design department—define success. Our goal is not to create a deliverable or a feature: It’s to positively affect customer behavior or change in the world—to create an outcome.”

Reducing frustration costs are an ideal outcome. And with our new UX champion, we can get support for a pilot project.

Lean UX is an ideal approach. We can start by testing the hypothesis that our rough estimates are close to correct.

We’ll ask our new UX champion for help putting together a multidisciplinary team to uncover where the frustration is coming from. By assembling a small task force with members from all over the organization, we can collect more accurate data about the frustration and ideas about how to start to whittle those costs down.

Calculating the cost of the frustration, wherever it’s coming from, is an ideal metric to drive the project and create a measurable approach to valuing design efforts. By finding a high-ranking champion outside the design team, we get exposure at a key part of the organization. And without wasting a minute in a brown-bag lunch lecturing on the importance of good user experience, we’ve shown the organization how good design can make us more profitable.


Learn how to calculate the cost of frustration in your organization. Attend our two-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

Baby Steps - An Organic Approach to Organizational Change

November 27, 2018

We want to deliver better quality products and services. That means our organization will need to change how it approaches the planning, design, and development of those products and services.

Change is hard. There are two ways to change how an organization works: Big steps and baby steps.

The way many design leaders try to approach change is with big steps. Big steps require we make big plans. We need to get big approvals from bigwigs. There’s a lot of big evangelism we’ll need to do. We’ll likely need a big budget. That means we’ll need to make big promises. We’ll have to arrange a big number of visits. We’ll need to produce big results.

Big begets big. Everybody has high expectations. Things become high risk with a lot of attention focused on us.

Let’s say we want our developers and product managers to spend more time observing people using our product or service. Our goal is to increase their exposure hours.

We could go the big step way. We make this big plan about how we’ll get every developer and product manager in front of customers. We’ll need to appeal to the bigwigs to get big permission to take these folks away from their current work.

We’ll have to put together a big budget for all the travel and visits. We’ll need to make a big list of customers to go visit. We’ll need to make some big promises on how this will benefit the quality of the product. We’ll need to show some immediate big results to prove this is working.

That’s a lot of big risks we’re taking on. What if it doesn’t work?

Never Underestimate The Big Power of Small Changes

Or we could tackle the change with baby steps. We could do what LaiYee Ho did when she was leading design at Wink. She didn’t put together big plans.

Instead, LaiYee went on a few low key visits with a willing compatriot—a QA engineer who was really curious. She didn’t have to convince anyone but her immediate boss. She didn’t need a big, upfront plan. She just needed to get out to one or two visits.

Those visits were a complete success. That QA engineer came back completely jazzed. He helped her sell the idea for a few more visits to a few more developers. Those developers also found the visits amazing and their excitement grew. It was contagious.

Baby-step by Baby-step

Within a surprisingly short amount of time, LaiYee found herself orchestrating visits for all sorts of team members. She didn’t have to promise future results because the results were already happening. She just needed to make sure others at Wink knew about them. That was easy because team members were going around sharing all of the exciting things they were learning from visiting customers.

This is how change works when you use baby steps. Each baby step is a small risk, which goes unnoticed until something good happens. Then people get excited about the change and want to be part of it.

Baby steps are easy to repeat. If things don’t go perfectly, the next baby step is easy to do a little differently. This makes baby steps easy to sustain. Everyone’s confidence builds. And that creates excitement for the change.

We Don’t Need Big Steps To Make Big Changes

Taking baby steps like LaiYee’s show us how to introduce change and lasting influence into our organization organically. That’s how we ensure our organization delivers better products and services.

Now you know how to do it. Go forth and make awesomeness.


Want to bring change to your organization?

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

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

UX Strategy Playbook Workshop: Bring the Right People Along

November 21, 2018

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

Implementing an effective user experience strategy for your organization will take more than a good effort from your UX design team’s leadership. You’ll need the support and understanding of every group involved in the product’s definition and delivery. You’ll see the most success from your UX strategy when the leaders of those teams buy into a plan you collaboratively come up with.

Some design leaders try to accomplish this by creating their strategy in isolation, then deliver it to the other product team leaders as a done deal. This approach rarely gets buy-in from those other team leaders. We’ve found a better approach: bring all the leaders together to hammer out a strategy everybody feels ownership of.

You’ll get the most out of our Creating a UX Strategy Playbook workshop when you bring the right people along.

Seeing the Benefits of a Strong UX Strategy

The great thing about our workshop is you can bring folks with any level of understanding about UX design. Even those who have only a vague appreciation of the benefits of good design. It’s ok if they walk in thinking that UX design is something that happens at the end of the project to neaten and pretty everything up. We’ll help them get a deeper understanding.

Everyone who comes to the workshop realizes the strategic power of thinking about their users and what they need. They see how UX design is more than nice colors, clean layouts, and modern typography. They learn how a UX design strategy is essential to solving your users’ big challenges, while also dealing with the real-world project constraints.

Don’t worry—this is a business workshop, not laden with designer jargon. Everyone will follow along, because we define every strategy and method. You will all leave the workshop with a common language and deeper insights into UX’s benefits. This will help you implement your strategy when you return to your organization.

For Product Management and Development Leaders Too

The Playbook workshop is about UX strategy, so of course you should bring your UX design leadership. You’ll get even more value when you bring the leaders of product management and development.

For your product leadership, we’ll focus on how a great UX strategy makes a product manager’s job much easier. They’ll walk through the best methods for dovetailing the UX strategy with every key product initiative, strengthening both in the process. They’ll get the ammunition they need to push back on arbitrary high-profile customer requests and unreasonable delivery dates, ensuring their team builds the right product that meets the needs of all users.

The development and engineering leadership who attend will immediately see how a great UX strategy makes their life easier. They’ll learn how their skills and knowledge can deliver better user experiences from the start. They’ll discover why it’s best if the UX design team is brought in earlier in the process.

Bring the Right People and See Great Results

As a design leader, bringing your peers from other parts of the product development organization to the workshop will make a huge difference when you start implementing your UX strategy. You’ll have their commitment to your strategic plan, with support across the entire product team.

Great products don’t happen because the organization hires a Justice League of Super Designers. Your organization will deliver great products because the teams collaborated by following a cohesive UX strategy.

Our Creating a UX Strategy Playbook workshop is the perfect place to strengthen vital team relationships. Attend the workshop together and leave with a team ready to take action and deliver better designed products.


P.S.

Bring your team to next week’s Creating a UX Strategy Playbook workshop in ThoughtWorks’ Manchester, UK office. (Most teams come with four members, so bring your team of four or more.) We also have upcoming workshops on Dec 12-13 and February 6-7 in our Chattanooga, TN USA classroom.

Let’s work to collaborate together and create your team’s cohesive strategy. Register today at the Creating a UX Strategy Playbook workshop website.

Goal Challenges and Tool Challenges

November 20, 2018

For both seasoned professionals and infrequent travelers, booking a flight is a pain in the buttocks. Finding a flight that will meet the needs of the traveler and not cost a fortune can be taxing, even for those who do it every week.

Let’s say you’re trying to fly from Boston to Sydney. There are no direct flights, which means you play games with a connection. Which route is best? Will you get there in time for dinner with your sister? You have an important meeting that morning at the office. Will you have to leave early? You’re hoping this isn’t too expensive.

Hipmunk, a website and app, tries to make the challenge of finding the best flight easier than other travel sites. And, it does a good job of it.

Hipmunk’s designers came up with a novel method for displaying available flights, using ‘swim lanes’ to put each flight up for comparison. Then they sort them by a proprietary ranking system they call Agony. This combination lets you see the best flights quickly by visually scanning all the details.

hipmunk app screenshot
Hipmunk uses swim lanes and sorting by agony to help travelers book the best flight.

Designing for Two Types of Challenges

These days, collecting all the necessary details to make a smart flight purchase is very challenging. These are challenges external to Hipmunk’s team, yet they’ve done a good job of using its novel visual display and sorting algorithms to reduce those challenges. We call these goal challenges because they are inherent challenges the user faces while meeting their goal.

But novelty comes with a price. Because people aren’t familiar with this display of their information, they need to learn how to read it. When it comes time to customize the information, such as to indicate flexibility in departure times or to hone in on only non-stop flights, the user needs a method to control the display. If Hipmunk’s users are distracted while controlling the interface, they can’t pay attention to the thing they came to do: book the best flight.

Hipmunk’s designers don’t want more challenges because of their interface design choices. When they do, we call these tool challenges. Tool Challenges are obstacles created by the designers due to their choices in the design.

An important design goal for any productivity tool is to simplify goal challenges without creating any new tool challenges. Any productivity tool, whether it’s to schedule appointments, identify supply chain backlogs, or discover new chemical interactions, has goal challenges. These tools need to ensure they don’t also add tool challenges.

Turning to Game Design

Designers of Productivity tools aren’t the only ones who have to find the best balance of goal challenges and tool challenges. Game designers do, too.

In game design, you want the user to focus on the challenges inherent in the objectives of the game. Yet, to play the game, it has to be easy to manipulate the game pieces on the board, to ensure the player doesn’t get distracted by the mechanics.

Take a puzzle game like Two Dots. The basic play of the game is simple: draw a connection between two or more dots. Each level of the game adds challenges to accomplish that, which is what makes the game fun for its players.

Two Dots app screenshot
Players connect dots to clear the level. The game designers need to keep other challenges to a minimum.

Two Dots’ designers also needed to put in tools to control the play of the game. These tools let players change levels, turn off the sound or music, and adjust colors if they have color blindness or another visual impairment. These tools must be easy to find and use, not a challenge like the gameplay itself.

Game designers are experts at ensuring goal challenges remain in the users’ focus while minimizing or eliminating tool challenges. By studying how the best game designers have made these trade-offs, we can learn how to improve the productivity tools we’re designing.


You’ll want to learn how to apply this to your team’s UX design strategy. You can learn how during our two-day Creating a UX Strategy Playbook workshop. You’ll create your team’s unique strategy playbook, using proven strategies that have helped teams everywhere deliver better products and services. Learn everything about the workshop here: Creating a UX Strategy Playbook.

We’ve partnered with ThoughtWorks to help you deliver great design

November 15, 2018

Our first Creating a UX Strategy Playbook workshop at ThoughtWorks.

We often struggle when the product managers, developers, and stakeholders we work with aren't as design literate as we need them to be. When these folks make product and service decisions, they might not realize how it affects our customers’ experience. These decisions can unintentionally make designs worse.

During the Creating a UX Strategy Playbook workshop, you’ll learn specific strategies to transform your team’s level of design literacy. With more than 130 UX strategies to choose from, you'll find the perfect ones to embed design education into your team.

Our next workshop is November 27-28, 2018 in Manchester, UK. We keep the workshop small, only a dozen or two dozen folks. You’ll get a lot of my attention to help you work through your organization’s biggest challenges, like challenges around design literacy.

November’s Creating a UX Strategy Playbook workshop is also special. What makes it special? We’re partnering with ThoughtWorks to host this workshop in Manchester, UK!

ThoughtWorks is one of the most experienced organizations at executing smart design. We’ve found their expertise has made them great partners. During the November Manchester workshop, you’ll get a nice, low-pressure way to explore if their expertise would make them a great partner for you and your organization too.

I’d love to work with you during our November Creating a UX Strategy Playbook workshop. Let’s work together to identify the perfect strategy combination for your organization alongside the great folks at ThoughtWorks.


P.S.

November’s Creating a UX Strategy Playbook workshop in ThoughtWorks’ Manchester, UK office is the perfect place to spend two days focusing on your organization’s UX strategy. Join us in November.

We also have upcoming workshop dates in Chattanooga, TN. Check out our December 12-13 and February 6-7.

Four Approaches to Share and Reflect on Our Work

November 8, 2018

“Emily is going to demo her design to the entire team next week.”

“Hey, Satish wants us to critique his latest design work.”
“We’ve scheduled a meeting to review Marsha’s design.”
“Dean’s doing a design walkthrough at 2.”

We throw around these phrases all the time. Do they mean the same thing? Or are there differences? Let’s explore and take them apart.

Terms for Us and Jargon for Them

Here are two conversations for us to compare:

“Hey, what happened?” “Oh, I broke my wrist.”
“Doctor, what’s today’s surgery?” “We need to pin up the left scaphoid.”

Both are talking about the same problem. The difference is the amount of jargon for precision.

If you tell your best friend that you broke your scaphoid bone, you’ll probably just receive a blank stare in return. Most people don’t know that’s one of the eight bones that compose each wrist.

But you’d want your surgical team to be quite aware that it’s the scaphoid and not the capitate or the trapezoid. These words are medical jargon, and they are there to be precise. That precision helps the surgical team get the outcome they desire.

Someone who doesn’t know much about design (also known as a layperson) doesn’t need to know there’s a difference between a review, a critique, a walkthrough, or a demo. They shouldn’t have to know.

Yet, these terms should mean different things to design professionals. When we’re trying to communicate how we share and reflect on our designs, there are different approaches to do it. Each approach produces different outcomes.

Four Approaches to Share and Reflect on Our Work

What could make each approach different? Each one could answer a different type of question:

Design Walkthrough—How does the design match up with the business problems we’re working to solve?

Design Review–Is this design ready for moving forward or are their still issues to resolve?

Design Demo–What is the user’s experience when using this design?

Design Critique–What can we learn from this design we’ve created?

Sure, as designers, we could use these terms interchangeably, but that doesn’t help us. Establishing a consistent usage helps us understand what we’re intending, just like the surgery team wants to know if they’re pinning up the lunate bone or a triquetrum bone. (Who knew wrists were so complicated?)

Matching Up Our Intent—The Design Walkthrough

Probably the most common way we see designers share their work is with a walkthrough. The walkthrough is a simple “here’s what I did and why I did it” discussion about the design.

Walkthroughs can have a wide variety of audience members. It could be other designers on the team, stakeholders, or even customers/end users. These folks want to see the approaches the designer took to solve the important problems.

The walkthrough structure is usually quite simple. The designer shows each design element, such as a screen or a page. They point out the interesting bits and explain the rationale behind their decisions.

Audience interaction is often limited to clarifying questions and pointing out potential issues, though we’ve all seen these devolve into attempts at design by committee. (It can take a strong facilitator to prevent this from happening.)

A good design addresses a specific set of problems. If a team describes and gets agreement on those problems before they do a walkthrough, the walkthrough session will be smoother. When you clearly identify the problems, you help the discussion stay focused on whether this design is providing effective solutions.

Moving Our Design Forward–The Design Review

There are various points in a design process where we have to say, “Yes, we’re ready to move forward.” That’s where a design review would come in.

What moving forward means will depend on the process. Maybe it’s reviewing a concept prototype to decide if it’s worth refining it further. Or maybe it’s reviewing the final layout to turn over to the developer, who will turn the design into production code. In almost any flavor of the process, there are checkpoints to ask if we’re ready to move on.

When the goal is to determine if our design is ready, then we conduct a review to go over each issue that could keep it from moving forward. Once every issue has been addressed (either fixed or pushed aside), then our design can proceed on its journey.

Our focus during the review is on the design’s issue list, not the design itself. To generate that list in advance, the team could do one or more design walkthroughs. Walkthroughs would give them a chance to prepare a response to each issue before the review starts, which will make the review session more efficient.

There you have it: use walkthroughs to generate the issue list and reviews to decide which ones still need resolutions. These are two ways to communicate a design, each with a different purpose, structure, and outcome.

Sharing the Experience–The Design Demonstration

Sometimes, it’s easier for someone to understand the design by seeing it from the perspective of using it. That’s when a demo becomes the right way to share how the design works.

What makes a demo different from a walkthrough is the noticeable absence of any discussion about the problems the design is trying to solve. In the demo, the demonstrator (who doesn’t have to be the designer), narrates their experience as they use the design.

Whereas a list of problems drives the walkthrough, a scenario drives a good demonstration. “Let’s say a patient, who is experiencing extreme wrist pain, walks into the Emergency Room’s triage station. We need to get them checked into the tracking system.” Now, the demonstrator proceeds to show what the triage nurse’s experience would be, one interaction at a time.

Demonstrations can be useful, like a walkthrough, for generating a list of issues for an upcoming review. However, it can be harder to do well. Demonstrations don’t lend themselves to interruptions because it breaks the “suspension of disbelief” that puts the audience member into the experience.

If the goal is to generate a list of issues, it might be good to put a demonstration back-to-back with a walkthrough. The demo can show the experience, then a subsequent walkthrough can deconstruct it, allowing for more along-the-way discussion.

Reflecting on the Design–The Design Critique

Every design is an opportunity for the designer to learn something. Maybe they learn about new techniques. Maybe they learn something about the users and their needs. Or maybe they learn how other parts of the design work.

The critique is a fantastic opportunity for the design team to turn inward and take apart a design, learning what makes it tick. Everyone in a well-run critique walks away with a new perspective on design and how to better meet users’ needs. It’s a great way for us to improve on our craft.

Unlike demos and walkthroughs, the intended audience is the design team. Others can join in (and the team should encourage this). But a critique wants to dive into the details of how the design came about, so it’ll get geeky. (They should be warned.) After all, if a developer or product manager is curious about how the design came together, getting an immersive education on the thinking behind it will give them better insight into the process, making it less mysterious.

Critiques are different from reviews because the team isn’t honing in on the issues. Whereas a review likely only focuses on things that need fixing, a great critique session might only focus on things that worked well. After all, how did the developer get it right? What was their thinking? What was their process? What would they do to make it even better?

Of the four techniques, critiques are the ones we do the least. Yet, they are probably the most valuable, as they not only help us understand how to make this design better, but all the designs that will come after.

Variations on a Theme

For each of the four techniques, variations can modify what they accomplish. For example, one team we recently worked with took a walkthrough and modified it to compare the user stories they’d created to the prototype they’d implemented.

As one designer walked through a piece of the prototype’s flow, another designer pasted screenshots on the wall. The business analysts who created the user stories pasted the relevant stories underneath each screenshot. Then, the team could clearly see which parts of the flows were missing comparable stories and if there were stories that didn’t deal with the prototype. It was the first time the two groups had a chance to ensure their work was synchronized.

There are many ways to do each of these techniques. It’s up to the team to pick the method and variation that best suits their needs at the moment.

The Attributes Behind the Techniques

If we look closely, we can see some patterns in these techniques. Reviews and critique are both about reflecting on the design, while walkthroughs and demos are for sharing the design with others. Reviews differ from critique because reviews focus on the future of the design. Critiques focus on how the design got to where it is today.

Similarly, walkthroughs focus on sharing why the designers chose a specific solution, while demos focus on sharing how the design feels to use. Both walkthroughs and demos are about bringing a shared understanding of the design to a larger audience than only the design team. Critiques and reviews are specifically for the design team, helping them get a deeper understanding.

A team can ask basic questions about what they need. Do they have a shared understanding with a larger audience? Do they need a deeper understanding amongst themselves? Answering these questions can help them pick the right technique to use at that moment.

To the layperson, the terms might not seem that different. But to the designer, they precisely describe a technique that will help move the project forward.


Drive your organization to share and reflect on design work more effectively. During my Creating a UX Strategy Playbook workshop you’ll craft a plan for you and your team that delivers value to your customers and your organization.

There are still spots open for my workshops in Manchester, UK November 27–28, 2018, and in Chattanooga, TN, December 12–13, 2018 and February 6–7, 2019. Pick a date that works for you and let’s help deliver innovative experiences together.

Understanding the Kano Model – A Tool for Sophisticated Designers

November 7, 2018

Years ago, when Flickr, the photo-sharing website, first appeared on the scene, the designers delighted their users with a variety of interesting innovations. One of those innovations was something that now seems strikingly simple in concept: a customized home page.

At that time, practically every other website had a standard home page. When a user typed in the site’s main URL, they saw an identical page to every other user.

Flickr’s page was different. When registered users typed Flickr.com into their browser’s address bar, they saw a personalized page complete with their own latest uploads and recent pictures from their friends and contacts. We interviewed users who told us they found the personalized page very exciting, including the happy “Hello” that appeared in a different language each time they visited.

It wasn’t very long before other sites started incorporating similar capabilities. We saw many sites with a personalized dashboard showing recent activity. We even saw other sites copy the multi-lingual greeting prompt.

The interesting thing is, as these innovative features propagated into other sites’ designs, they became less remarkable and less delightful to those sites’ users. These users rarely mentioned the features and never seemed as excited about it as those initial Flickr users did.

The Kano Model—A Tool for Sophisticated Designers

Years ago, we came across the work of Noriaka Kano, a Japanese expert in customer satisfaction and quality management. In studying his writing, we learned about a model he created in the 1980s, known as the Kano Model.

This model predicted users’ reactions as the key elements of Flickr’s personalized home page appeared on other websites. It predicted why users were initially delighted and why the delight faded over time.

We find the Kano Model to be an indispensable tool for designers. Let’s take the model apart, so we can understand why it’s so useful.

The Two Dimensions of Kano: Investment versus Satisfaction

The easiest way to think of the model is on a two-dimensional grid.

Kano Model Axis Only
The two dimensions of Kano: Investment versus Satisfaction.

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality (remember, Noriaka was a quality guy at heart) or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight. (Neutral satisfaction being neither frustrated nor delighted is in the middle of the axis.)

It’s against the backdrop of these two axes that we see how the Kano Model works. It shows us there are three forces at work, which we can use to predict our users’ satisfaction with the investment we make.

Performance Payoff

When blogging first started, a blog author needed to know basic HTML to do anything fancy with their formatting. Many blogs were absent of any style just simple words on the page.

The first blogging systems added basic formatting features, like bold and italics, to their text input fields. These features would give a small word-processing feel to an otherwise bland input tool. Users were delighted.

The designers took the hint. They started adding more word processing-like features. We saw bullets, justification, image insertion, and fancy link capabilities. Each feature took more investment and returned more satisfaction.

Kano Model performance payoff
Performance Payoff-The more organizational investment, the more user satisfaction.

We’ve all seen instances like this. By adding new features or cleaning up the quality of the product, we generate more shouts of delight from a thankful audience. This is the Performance Payoff, the most visible force of the Kano Model.

Every design has a performance payoff as the design team evolves the functionality and quality. Its key designers understand how much delight is generated with each new feature, as it takes more investment to garner more delight over time by just adding features in this fashion.

Basic Expectations

Google Docs changed the game of office software. It eliminated the notion of a file and let your data live in “the cloud.” Google Docs makes it easy to share and collaborate with colleagues because it eliminates the emailing of duplicated files. Everybody works from the same source. Each person sees the same changes instantly.

A downside of editing in the cloud is the need for constant connectivity. If a user is editing someplace where the connection is spotty, intermittent problems occur. Something as simple as saving a draft becomes a frustrating moment for the user, who doesn’t know the state of their document.

Document saving isn’t a feature that will make anyone excited. But its absence or unreliability will frustrate folks immensely.

Kano Model basic expectations
Basic Expectations: The bad frustrates, yet the good doesn’t impress.

This is a defining trait of the Kano Model’s Basic Expectations. Capabilities that users expect will frustrate those users when they don’t work. However, when they work well, they don’t delight those users. A basic expectation, at best, can reach a neutral satisfaction a point where it, in essence, becomes invisible to the user.

Try as it might, Google’s development team can only reduce the file-save problems to the point of it working 100% of the time. However, users will never say, “Google Docs is an awesome product because it saves my documents so well.” Users just expect the software to save their files correctly at all times.

Basic expectations are often related to bugs and reliability. When a Skype conversation is cut off by a bad connection, it can frustrate the people on the call. When an e-commerce application double charges the site’s shopper, that’s frustrating, too.

However, a basic expectation may be something the user is already familiar with, such as automatically receiving a confirmation email after they complete a transaction. Your users may expect your product or service to have features they find in other products or services they frequent regularly.

As a designer, you need to pay close attention to the basic expectations of your users. It’s easy to focus on the new and novel elements of our design, forgetting to look back at how our users are using our existing capabilities while making sure we’re meeting all of the basics.

Excitement Generators

Zappos customers report, while they often purchase using the company’s 4-5 day free shipping frequently, they’ll receive that order within one or two days at no extra charge. This delights the customers, who go on to tell their friends. Zappos has a special relationship with their shippers to accelerate the deliveries. It’s part of their desire to “under promise and over deliver.”

Kano Model excitement generators
Excitement Generators: Design elements and features that delight the user.

There are many ways to add the Kano Model’s Excitement Generators into the user experience. Zappos does it through their delivery operations and customer support, but that’s not the only way.

Groupon generates delight through their clever use of advertising copy for the products they sell. For example, a recent ad for half-price gourmet brownies started with: “Without chocolate, the world would still be under the oppressive rule of the Turnip King and his tasteless parsnip army.” Groupon’s customers regularly say they find the clever copy delightful.

Tripit.com’s users tell us how much they love the travel-itinerary site’s automatic confirmation parsing feature. When the users email their hotel or airline confirmation email to the site, it automatically parses out the dates and locations, adding it to their trip’s itinerary. If no itinerary exists for the reservation dates, it automatically creates one. These Tripit users love that they don’t have to enter a ton of information to get all their reservation details into one, nicely formatted page.

Exploring the users’ context and overall experience helps identify potential excitement generators. These don’t have to take a huge investment. While Zappos invests a lot in their customer service, writing creative copy, like Groupon’s, can be a much simpler method to garner the user’s delight. (Copywriting is hard, and good copywriters are not cheap, but it’s easier to establish a good copywriting practice than it is to move a distribution center within 10 miles of the overnight shipping hub.)

Of course, excitement generators won’t delight users who are frustrated when you don’t meet their basic expectations. Designers need to ensure they are focusing on both ends of the model.

The Migration From Excitement Generator to Basic Expectations

A great model can help us understand what we’re seeing. Flickr’s delightful home page experience, for example, became less delightful when it started showing up in other designs.

One of the predictions that the Kano Model makes is that once customers become accustomed to excitement generator features, those features are not as delightful. The features initially become part of the performance payoff and then eventually migrate to basic expectations.

Flickr’s designers did something delightfully novel by creating a personalized home page, with a customized dashboard that showed the users’ own photographs, contacts, and activities. As other sites implemented similar dashboard-like pages, these users became more accustomed to it. The feature lost its luster.

Today, many users will be frustrated if they don’t see a dashboard page, or if they’re required to log in before seeing it. The feature, once a delighter, is now a basic expectation.

Kano Full Model
The full Kano Model: A tool to predict user satisfaction.

Applying the Kano Model

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

The model becomes a great way to explain to stakeholders and project owners how to tackle hard decisions. It’s a great way to keep teams focused on the right priorities.


Identify your customer’s hidden problems using the Kano model. Bring your team to our 2-day Creating a UX Strategy Playbook workshop and together learn how to institute the Kano Model at your organization.

Together you’ll also create your team’s unique strategy playbook, using other proven strategies to deliver better products and services. Look over our upcoming workshop dates, include our November Manchester, UK workshop in partnership with ThoughtWorks here: Creating a UX Strategy Playbook.

What Makes an Experience Seem Innovative?

November 1, 2018

A few years back, as it has done so many times before, Apple came up with a game changer—an innovation. For its Genius Bar, customers wouldn’t need to form a line to receive customer service. Instead, they could make an appointment for a specific time, show up, and get the help they wanted.

This was a first in consumer electronics retail. At stores like (the now defunct) Circuit City and Best Buy, the ritual was for customers to stand in lines—sometimes very long lines—waiting to meet a store representative.

Everyone assumed the old way of long lines was how you did it. They built their stores with dedicated space to accommodate the lines during busy periods, such as after the holidays. Apple’s new approach meant their architects didn’t need to build in that space, letting them put it to other uses, such as product displays.

Here’s the thing: Apple didn’t invent making an appointment. Yet their approach to using it for customer service seemed completely innovative.

Why was that? If we want to produce innovative products and services, there are lessons to learn from what Apple did.

Innovations Extend the Evolution

Standing in line sucks. There are so many better things we could be doing with our time. But if we step out of the line, we lose our opportunity to get the service we want. We want the result without the wait.

Years ago, some store somewhere (probably a delicatessen) came up with an idea. Instead of making people wait in line, they handed out numbers. When the clerk finished with a customer, they’d call out the number of the next customer. Customers no longer needed to wait in line. They could mill about.

However, they couldn’t go far from the counter. If they missed when the clerk called out their number, it would present a socially awkward moment as they tried to get back into the queue. Numbers are just one step above standing in a line and just slightly less frustrating.

The first doctors’ offices worked the same way. Want to see a doctor? Go to the clinic and get in line. See the doctor when it was your turn. A popular doctor would require you wait a long time before it was your turn—maybe the entire day.

The advent of the telephone gave patients a chance to call ahead and schedule a time to see the doctor. Now the patient could show up at the designated time (and hope the doctor hasn’t fallen behind). This change let doctors use less space for their waiting room and more space for their clinical work.

Unlike doctors’ practices, retail customer service lines hadn’t evolved to the next level. Apple made the logical jump before others. It was only because other retailers hadn’t seen it as a problem to solve that they let Apple beat them to it. Those retailers didn’t see the need to evolve.

Innovation Found at the Point of Deepest Frustration

Apple didn’t invent the appointment and they weren’t the first retailer to use it in the context of retail customer service. The tailoring and fitting services of a few high-end clothing retailers have been using appointments for years.

About a decade ago, Disney installed a similar appointment mechanism in their theme parks to alleviate lines for their attractions. Park guests can get an appointment for a specific ride, like the Tower of Terror, thereby freeing them up from long lines and letting them enjoy other aspects of the park.

Southwest Airlines reduced the confusion surrounding the crazy lines when boarding an airplane by giving everyone a place in line. Similar to Disney’s machine-assigned appointments, Southwest makes it easy for people to know when it’s their turn.

A modified implementation of the appointment is also at the heart of Uber’s city-ride service. Instead of waiting in taxi queues, Uber’s passengers request an available car by clicking on a button on their phone, making an immediate appointment. The phone’s GPS tells the driver where the passenger is waiting and sends them to pick up the fare.

Apple, Disney, Southwest, and Uber borrowed the basics of the appointment to deal with a frustration all their customers faced: waiting in long lines. Waiting is a deep frustration for customers because it’s a complete waste of their time.

By focusing on a deep frustration, the change to appointments has the feel of making a huge improvement. Had Apple focused on improving something their customers didn’t find deeply frustrating, the outcome probably wouldn’t have seemed so innovative. The perception of innovation needs a deep solution.

Innovation Extends Into the Experience Gaps

Tool time is a great place to look for deep frustration. In an experience, tool time is the cumulative moments where the user is dealing with a system requirement that doesn’t advance their goal.

In the entire experience of getting customer service at a store or riding amusements at a theme park, standing in line doesn’t help the customer or park guest enjoy their time. They may see it as a necessary evil and tolerate it, but it doesn’t make them happier. Providing them with an alternative does.

Since customers think standing and waiting is a necessary evil without alternatives, they may not complain about it. Organizations that focus on the specific activities to resolve their perceived customer objective, may overlook the deep frustration from tool time that’s happening in the gaps between those activities.

Teams that study the entire experience look into those gaps to see from where the deep frustration emerges. Addressing that frustration, when no other product or service has done so, will look innovative to the customer.

Delivering on the Promise

Apple’s appointments only delight when the Apple Store staff keeps their promise. If an Apple customer makes an appointment, only to be made to wait at the store, the innovation loses its magic touch.

The organization has to take extra care to ensure their promise is kept. Apple had to build resource management systems into its appointment scheduler, to prevent the system from scheduling too many customers for any given slot. They had to give managers tools for dealing with cancellations, absent service representatives, and walk-in customers with an emergency that can’t wait for a later appointment.

The back-end systems to something as simple as making an appointment can get very complex. Hiding that complexity while delivering on the promise makes the appointment system seem innovative.

No Innovation Before Its Time

Ten years before Apple opened its first store, Best Buy’s stores were fast approaching $1 billion in revenues. The Best Buy folks could’ve tried to come up with a solution to making folks wait in line.

In 1991 the technology landscape was very different than 2001. There was no internet or web-based applications to build a calendar on. Mainframe database systems, necessary to run an application of this scale, were slow and hard to manage. The customer service center to handle all the appointment calls would’ve cost millions to operate each day.

The Apple Store opened at the right time in technology history. By the time the first stores were opening, it was easy to build the appointment system on the new range of technology. (If the stores were to open today, the technology is even cheaper and less expensive.)

The Apple Store had the advantage of being in the right place at the right time. Their design seems innovative because they could use new platforms and a new technology stack to build out their “simple idea.”

What Makes an Experience Seem Innovative?

Who would’ve thought you could innovate around something as simple as waiting in line at a store, a taxi stand, or boarding an airplane? Yet when businesses look at what’s happening with their customers, it’s these opportunities that are most ripe for creating delightful experiences.

The recipe for making an experience seem innovative requires just the right combination of ingredients. Start with a deeply frustrating experience. Then look into the gaps between the activities. Finally, build out the systems to make sure you can deliver on the promise. When complete, you’ll have something that could change how your industry thinks about delighting customers and users.


Instituting mini creative briefs is one of more than 130 proven strategies we’ve identified in our Creating a UX Strategy Playbook workshop. Facilitating productive design discussions will allow team members to know what’s expected from them in delivering your organization's best designed products and services.

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

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.

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