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

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