All too often companies are focused on their own processes, wrapped up in a type of organizational navel gazing. They simply don’t know what their customers actually go through.

And, even if they can identify root causes of problems, logical solutions can cross departmental lines. Fixes may require crossing those boundaries. An organization’s rigid decision-making makes that difficult.

But how do we diagnose the situation and better understand the value creation process?

I propose the term “alignment diagrams” to describe a class of documents that reveal the touchpoints between a customer and a business. These touchpoints are organized and visually aligned in a single graphical overview. Illustrating these touchpoints helps a company shift its inherently inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible from both sides of the fence.

Alignment diagrams are not new. In fact, you’ve already used them. “Alignment Diagrams” is an umbrella term for any such document, including customer journey maps, service blueprints, experience maps, mental model diagrams and more.

Thus my definition of alignment diagrams does not introduce a new technique but rather recognizes how existing techniques can be seen in a new, constructive way. It re-frames their strategic importance.

I have been giving a leading workshop on mapping experiences for about 5+ years. (E.g., I’ll be giving my experience mapping workshop again in NYC on Nov 16). Many students ask for more information on the topic. So I’ve compiled a list of resources I reference or point people to too.

Here you go:

Adaptive Path’s Guide to Experience Mapping” (2013)

This is a free guide to experience mapping from the good folks at Adaptive Path. In less than 30 pages they are able to describe the mapping process with both detail and clarity. This includes an excellent discussion of the value of experience mapping in general.

Mary Jo Bitner et al, “Service Blueprinting: A Practical Technique for Service Innovation,” Working Paper, Center for Leadership Services, Arizona State University [pdf] (2007).

This 24-page paper is very detailed and includes practical information. “Service blueprints allow all members of the organization to visualize an entire service and its underlying support processes, providing common ground from which critical points of customer contact, physical evidence, and other key functional and emotional experience clues can be orchestrated.”

Gianluca Brugnoli, “Connecting the Dots of User Experience,” The Journal of IA 1/1 (2009) 

This is a well-referenced, slightly academic article on cross-channel design. Gianluca provides some practical tips on how to mapping systems. The highlight of the article is his tool, the customer journey matrix. He observes: “The user experience takes shape on many interconnected devices and through various interfaces and networks used in many different context and situations. To achieve their goals through the interaction flows, users tend to combine an increasing number of different applications and tools within wide and fuzzy ecosystems, where technical factors blend in with behaviour and intention.”

Ram Charan, What The Customer Wants You To Know (2007) 

Ram Charan is a business power-house, having consulted the biggest names in many industries. This is a slim volume that is very accessible. He makes a strong call for a re-imagined sales process, one that focuses on your customer’s customer in what he calls “value creation selling.”

Silvana Churruca, “Experience maps, user journeys and more…UX Lady [blog]  (2013)

This blog post highlights some of the key elements of experience mapping in a good overview. She covers layouts, content, elements and complexity with many examples.

 “CX Journey Mapping Toolkit” 

This is an excellent collection of guides, tools and templates for journey mapping in general, created and maintained by designers at Oracle.

Steve Denning, “Why Building A Better Mousetrap Doesn’t Work Anymore.Forbes (2/2014) 

In this article, Steve Denning discusses the value of ecosystems. Stand-alone products aren’t enough anymore, he believes. Companies must instead think across products and services, conceiving them as a connected system of experiences. He writes: “The winners will be determined not only by building a better mousetrap, but also how that mousetrap fits into the things that customers are trying to get done is their lives, in other words, their individual ecosystem. The quandary for companies is how to meet the idiosyncratic needs of millions of different customers?”

Hugh Dubberly, “A System Perspective on Design Practice

(2012) 

This is a video of a talk Hugh gave at Carnegie Melon University in 2012. While he doesn’t talk about experience map or alignment diagrams directly, he does advocate the models are needed for systems design. The tool he highlights is more of a concept map, but nonetheless underscores the need for designing at the system level with abstractions of the system documented in some way.

Chris Ertel and Lisa Kay Solomon, Moments of Impact (2014) 

This is a comprehensive book about how to harness the talent of a group of people in a focused way to make strategic decisions. Don’t waste time in yet another 2-day strategy offsite where everything and anything gets discussed but without decision.

Kim Erwin, “Consumer Insight Maps: The Map as Story Platform in the Design Process. Parsons Journal for Information Mapping (2011) 

Consumer Insight Maps are lesser known deliverables and not really experience maps. They fall into the category of alignment diagrams, however, because they seek to align customer traits with business outcomes. Parts of them even look like mental model diagrams, with stacked boxes of behavior, but there is much more detail and context around them. In her own words: “The user experience takes shape on many interconnected devices and through various interfaces and networks used in many different context and situations. To achieve their goals through the interaction flows, users tend to combine an increasing number of different applications and tools within wide and fuzzy ecosystems, where technical factors blend in with behaviour and intention.”

Joel Flom. “The Value of Customer Journey Maps: A UX Designer’s Personal Journey,UX Matters (Sept 2011).

This is a good case story around the use of customer journey maps (CJMs) at Boeing. There’s also a good illustration of a CJM with an interesting layout and form. Look at this article if you need some arguments for convincing others to use CJMs. The author was first skeptical of their use, but concludes: “By producing journey maps that illustrate an optimal customer experience, we enable stakeholders and executives to identify, prioritize, and maintain focus on the changes that matter.”

Dave Gray et al., Gamestorming (2010) 

Gamestorming is an indispensable collection of activities and exercises in interactive workshops. There are detailed instructions and examples with each. There’s also an excellent introduction about designing and running workshops, in general, which is a big part of the experience mapping process: getting everyone on the same page with the alignment diagram as a catalyst.

Luke Hohmann, Innovation Games (2006) 

Like Gamestorming, this is a collection of innovation workshop techniques focused on “game-like” techniques. There are lots of exercises that use metaphors (e.g., Speedboat, Design The Box) and interactive techniques (Buy A Feature) that get results through serious play.

Jim Kalbach and Paul Kahn, “Locating Value with Alignment Diagrams,” Parsons Journal of Information Mapping, 3/2 (April 2011).

After my talk at the Euro IA in Paris (2010), where I first introduced the notion of “alignment diagrams,” Paul Kahn and I authored this piece explaining the concept and its relevance to various disciplines.

Jim Kalbach, “Alignment Diagrams: Focusing the Business on Shared Value,” Boxes and Arrows (Sept 2011).

This follows in the footsteps of the piece I co-authored with Paul Kahn, but is more practical in nature. I conclude: “alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face. At a minimum, alignment diagrams start a conversation towards coherence, bringing actions, thoughts, and people together to foster consensus. More importantly, they focus on creating value—for both the customer and the business.”

Jim Kalbach, “Principles of Alignment Diagrams.” ExperiencingInformation.com (Jan 2012).

In this blog post I outline what I consider the key principles of alignment diagrams. There is no specific technique for alignment diagrams; rather, they are a class of documents already found in the design canon. It’s the principles behind them that tie them together, and once you grasp these, it should open doors for a variety of approaches depending on the situation.

Jim Kalbach, “Project Canvas” (2011) 

For some reason, defining projects formally is difficult or tedious for many people. As a result, setting your goals and intents at the outside of projects gets skipped over.

Mike Kuniavsky, Observing The User Experience (2nd ed, 2012) 

Experience mapping requires some type of primary investigation. This is an excellent resource into the ins and outs of user research.

Birgit Mager “From Shareholder Value to Share Values.” Touchpoint 4/3 (Feb 2013)

This is a lesser-known article with an important message. Birgit Mager has been a pioneer in service design for the past two decades. In this article she stresses the need for focusing on value creation beyond just financial growth.

Peter Merholz et al., Subject To Change (2008)

This is an excellent book on UX strategy from a group of folks from Adaptive Path. With a sense of urgency they call for an elevated importance in experience design in general. “The experience is the product,” they declare. See my review of this work.  http://experiencinginformation.wordpress.com/2008/05/12/book-review-subject-to-change/

Jess McMullin, “Searching for the Center of Design.Boxes and Arrows (Sept 2003)

Jess makes a call to think beyond user-centered design and embrace value-centered design. This principle underlies the basic notion of an alignment diagram: “Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction.”

Alexander Osterwalder, Business Model Generation (2010)      

After researching business models for his thesis work, Osterwalder made a big splash with his business model canvas. This book shows you how to use that canvas in detail. But it goes beyond that and discusses principles of business design. The dual nature of the business model canvas – frontstage and backstage, as he says – make it a type of alignment diagram by definition.

Andy Polaine, Lavrans Løvlie & Ben Reason, Service Design (2013).

This book provides a compact overview to service design as a field, with hands-on tools and tips for practitioners. Chapter 5 discusses service blueprints in some detail and positions them as a key activity is the service design process.

Michael Porter and Mark R. Kramer, “Creating Shared Value.” Harvard Business Review (Jan 2011)

Strategy guru Michael Porter made a big splash with this landmark concept and article. The authors observe: “Companies … remain trapped in an outdated approach to value creation. They continue to view value creation narrowly, optimizing short-term financial performance in a bubble while missing the most important customer needs.” Companies, they believe, must take the lead in brining business and society together for the larger, greater good – the shared value we can all get from good business.

Adam Richardson. “Using Customer Journey Maps to Improve Customer Experience,”Harvard Business Blog (Nov 2010) and “Touchpoints Bring the Customer Experience to Life,” Harvard Business Blog (Dec 2010)

This pair of articles from Frog Design expert Adam Richardson covers some basics of CJMs. The second one dives deeper into touchpoint analysis and provides some good tips and examples of what to potentially look for and map. The important thing about these articles is that they appear in a leading business venue. Pointing to these can help get the attention of stakeholders at different levels

Michael Schrage, Who Do You Want Your Customers To Become (2012)

This is a short ebook with a powerful message. Rather than looking at who your current customers are and trying to satisfy or even delight them, you should strive to transform them: enable them to become somebody or something they currently are not. The simple question, who do you want your customer to become?, reframes your focus greatly and goes beyond just better services and experiences and looks at transformational meaning.

Service Design Tools” (Accessed 2014)

This website is a collection of tools for design, in general. A fair portion of it focuses on a games and activities for groups to use in co-creation exercises. In addition to customer journey maps and touchpoint maps, there is a wealth of tools related to experiencing mapping, in general.

Steve Portigal, Interviewing Users (2013) 

Steve Portial is a recognized expert in user research. This book is a must-read for anyone going into the field to engage in ethnographic research. There is a wealth of practical information and tips in this volume.

Lynn Shostak, “Design Services that Deliver.” Harvard Business Review (Jan 1984)

This is one of the original articles to mention the use of maps, or in this case blueprints, to model a service experience. It provides detail on how to create a map as well as some examples. That this article appeared in the Harvard Business Review is also telling: mapping isn’t just a tool for designers, but also a tool for how to design a business

Christoph Spengler et al, “360° Touchpoint Management – How important is Twitter for our brand?Marketing Review St Gallen (2010)

Tyler Tate, “Cross-Channel Blueprints: A tool for modern IA” [blog] (2012) 

This is a simple blog post with a powerful message: to design across channels you need a picture of the experience across channels. To do that, you need to blueprint the experience. He gives a simple tool to focus on the cross channel condition that supplements a larger experience map well.

Edward Tufte, Envisioning Information (1990) ; Edward Tufte, Visual Explanations: Images and Quantities, Evidence and Narrative (1997)

Edward Tufte is the leading thinking in information design. These two books are a few of his many tomes outlining fundamental principles of information design. Understanding these concepts helps greatly in creating alignment diagrams.

Russ Unger et al., Designing the Conversation (2013) 

This is an excellent book to help craft conversations of various kinds. The techniques range from interviewing users to holding workshops: a perfect companion to alignment diagraming.

James Womack and Daniel Jones, “Lean Consumption.” Harvard Business Review (Mar 2005)  

James Womack is one of the early proponents of the lean movement. In this article he outlines his framework from “lean consumption”: reducing the number of touchpoints, steps and time consumers take in a service interaction. His research concludes that reduce that time has, without exception, a positive impact on the business bottom line as well. Mapping the touchpoints and steps involved is a key tool to do this.

Indi Young, Mental Models (2008)

Indi pioneered a specific technique of alignment diagram called a “mental model” in the early 2000s. This is a detailed book with step-by-step instructions.

Zero Moment of Truth” 

The folks at Google point to a fundamental shift in consumer behavior: never before have we researched products and service before purchasing them. With reviews and recommendations abounding, we need to re-evaluate what a customer’s journey is. Namely, it likely doesn’t start by reading a product description or spec on your site. Instead, people actively seek out the opinions and experiences of others. This behavior should  be accounted for in experience mapping efforts.

 .

These days it’s expected to be able to narrow search results with filters, e.g., on the left side of the results page. Called faceted navigation, this is a way to improve overall findability of information, particularly on sites with large collections of products or documents. Remember: people can’t buy what they can’t find, and filters help them get there.

The design of real-world faceted navigation systems, however, proves to be more intricate than people first assume. There are many hidden challenges, such as displaying large amounts of metadata and creating simple interactions average users understand. The truth is, once you dig into it there are many details to be aware of.

What’s more, faceted navigation doesn’t stop with search filtering: it can be applied to the design of navigation across the site. People can browse by facets before even searching, for instance. With this in mind, faceted navigation improves the discoverability of your content dramatically throughout the entire user experience.

I’ve developed a course on faceted navigation that I’ve been giving for nearly 8 years now. Many students ask for further resources and information. So I’ve compiled this list of references:

Marcia Bates, “The Design of Browsing and Berrypicking Techniques for the Online Search Interface” (1989)

William Denton, “How to Make a Faceted Classification and Put It On the Web” (2003)

Karl Fast, Fred Leise, Mike Steckel, “All About Facets and Controlled VocabulariesBoxes and Arrows (2002)

——— “1. What Is a Controlled Vocabulary?Boxes and Arrows (2002)

——— “2. Creating a Controlled VocabularyBoxes and Arrows (2003)

——— “3. Synonym Rings and Authority FilesBoxes and Arrows (2003)

——— “4. Controlled Vocabularies: A Glosso-ThesaurusBoxes and Arrows (2003)

——— “Facets and Controlled Vocabularies: An Annotated BibliographyBoxes and Arrows (2003)

Instone, Keith “”Faceted Browsing – How User Interfaces Represent and Benefit from a Faceted Classification System“, SOASIST meeting, Dayton, Ohio

Jim Kalbach, Designing Web Navigation, Chapter 11 (2007)

——— “Faceted Navigation: Showing More Values

——— “Faceted Navigation: Layout and Display of Facets” (2010)

——— “Faceted Navigation: Grouping – An Untapped Potential” (2010)

——— “Faceted Navigation: SEO and Facets” (2010)

——— “Faceted Navigation: Typical Structures for Values” (2010)

——— “ROI of faceted navigation” (2011)

——— “Faceted Navigation: Displaying and Forecasting Magnitude“ 2011)

Kwasnick, Barbara H, “The Role of Classification in Knowledge Representation and Discovery” Library Trends (1999)

Fred Leise, Sarah A. Rice, Amy WarnerDeveloping a Faceted Classification” (presentation at the IA Summit, 2005)

Louie, Aaron J., Eric L. Maddox, and William Washington “Using Faceted Classification to Provide Structure for Information Architecture” Information Architecture Summit, Portland, OR (2003)

Peter Morville, “The Speed of Information Architecture“ (2001)

Jakob Nielsen, “Converting Search into Navigation” (2013)

Greg Nudelman, “Faceted Finding with Super-Powered Breadcrumbs” (2009)

Greg Nudelman, “Numeric Filters: Issues and Best PracticesUX Matters 

Priss, Uta, and Elin Jacob, “Utilizing Faceted Structures for Information Systems Design,” in ASIS ’99: Proceedings of the 62nd ASIS Annual Meeting (1999?)

Ranganathan, S.RElements of Library Classification. 3rd ed. New York: Asia Publishing House (1962)

Andrea Resmini and Luca Rosati, Pervasive Information Architecture (2011)

Tony Russell-Rose and Tyler Tate, Designing the Search Experience: the Information Architecture of Discovery (2012)

Donna Spencer, Card Sorting (2009)

Louise Spiteri,”A Simplified Model for Facet Analysis: Ranganathan 101” Canadian Journal of Information and Library Science (1998)

Jared Spool, “Users Continue After Category Links” (2001)

Steckel, Mike, “Ranganathan for IAs” Boxes and Arrows (2002)

Daniel Tunkelang, Faceted Search (2009)

Peter Van Dijck, “Introduction to XFML” xml.com (2003)

——— “XFML Core – eXchangeable Faceted Metadata Language” (2003)

.

EXAMPLES

Elastic Lists

EXHIBIT 

FLAMENCO

Freebase Parallax 

mSpace

OptimalSort from Optimal Workshop for card sorting

Relation Browser

Scatter / Gather UI 

Trivago TV advertisement (shows the value of facets in a commercial setting)

 

 

UX Strategy Blueprint

12 August 2014

How do we consistently create UX strategy? Tough question.

Part of the problem is in the fuzziness of the term “strategy” itself. Many people blur it with detailed planning. Others consider strategy to be in-depth investigation, such as market research or competitor comparisons. Or, it gets conflated with vision or ambition.

None of these is strategy.

Strategy is about uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome. It’s an interlocking set of choices that aligns activity and shows causality: if we do this, then we expect to see that.

Analysis and planning, while necessary inputs and outputs in the strategy creation process, are not the core of strategy. You can’t analyze your way to strategy: the answers don’t magically emerge from data. And detailed roadmaps don’t provide the rationale for the activity they organize. Strategy does. It connects analysis and planning with an intentional logic that guides decision making.

The UX Strategy Blueprint is a simple tool to help you define a UX strategy. Try it out:

Download the UX Strategy Blueprint 

UX strategy blueprint

Keep in mind that strategy is hierarchical. It cascades from the top down. Effective UX strategy aligns upwards.

Regardless of level – corporate, product, team or personal strategy – the crux of strategy work relies on the same set of elements, outlined below. Using this schema allows you to not only articulate a UX strategy consistently, but also map it back to superordinate strategies.

Elements of UX Strategy

The elements in the UX Strategy Blueprint are based on existing research in the field of strategy. First, it borrows from Henry Mintzberg’s five Ps of strategy from his landmark book Strategy Safari. These are combined with Roger Martin and A.G. Lafley’s five questions of strategy in their recent book Playing To Win. (Both books are highly recommended).

The intersection of these two frameworks yields six common facets. Each is given a box in the Blueprint, formulated specifically for generating UX strategy. Below each of the six headers are guiding questions, as well as examples of the types of information required.

Here’s how to interpret each element in the UX Strategy Blueprint:

  • CHALLENGES.  Strategy implies the need for change, a desire to move from point A to point B. What are the hurdles to doing so? What opposing forces must you overcome to be able to reach the desired outcome? For instance, in user experience design you may face challenges around coherency if, say, you’re trying to integrate several web properties after an acquisition.  Or, you may be fighting severe usability issues or a deteriorating image. Ultimately, strategy is about problem solving. What problems are you solving for? Focus on customers and users, but you may also have internal challenges you want to list here too.
  • ASPIRATIONS. What experience do you ultimately want to deliver? Go beyond the generic goals like “be consistent.” Instead, strive for something more aspirational. For example, you may want to differentiate your service through a specific type of user experience, which would drive adoption. More importantly, consider how you will impact your customers’ work and daily lives. How does your solution transform what they capable of doing and who they ultimately are? Your aspirations should inspire your teammates.
  • FOCUS AREAS.  Strategy is about trade-offs. Indicating your focus areas helps concentrate effort on the things that matter most. Note this doesn’t necessarily mean you’ll be ignoring everything else not listed, just that the elements listed here are of higher priority. Indicate your primary focus for these five topics in a straightforward, factual manner:
    • USERS – Who will use your solution? If you have personas, list the ones that are most relevant to the success of this strategy.
    • REGIONS – What are the countries, languages, and cultures that are in play?
    • SERVICES – What products, services, platforms, and technologies are included in the strategy? Scope out the ones that aren’t.
    • USE CASES – Indicate the key scenarios of use at a high level. For instance, in ecommerce settings will you focus on finding products, the purchase process, or both?
    • AREAS OF UX – What areas of UX will make the most difference? Highlight aspects such as information architecture, interaction design, visual design, content strategy or branding, as well as attributes of usability such as control, learnability, or discoverability, among others.
  • GUIDING PRINCIPLES.  This is perhaps the trickiest but most important part. In business strategy, the guiding principle indicates how you’ll win against competitors. For UX strategy, the guiding principles are the approaches you’ll take to overcome the challenges and solve the problems you’re facing. This can include a particular sequence of activities, like “mobile first.” But strive to be even more specific. What rules of thumb must be in place to reach your aspiration? What mantras would you give design teams to consistently execute towards the same goal? Remember: strategy provides consistency in behavior. How will you get everyone paddling in the same direction?
  • ACTIVITIES. What types of UX activities are needed to implement the strategy and achieve your aspirations? This includes such things as user research, concept development, sketching, screen design, prototyping, and testing, as well as creating patterns or guidelines. Team development and skill development can also be recorded here. Note that this section shouldn’t read like project plan, rather it’s an inventory of the types of activities required to reach your aspirations. Keep in mind you may need new capabilities to execute your strategy. That’s OK: strategy isn’t a re-configuration of existing skills and resources, rather how you’ll maximize chances for success.
  • MEASUREMENTS.  How will you know your strategy is on track? How can you show progress and success? Often benchmarking and comparison is needed. This means you’ll likely have to measure aspects of your user experience (e.g., satisfaction) before and after work begins. Ultimately, your measurements should support the business goals. Try to find metrics that show the positive impact UX has on business. Be specific with goals like “increase sales by 5% by streamlining checkout” or “reduce calls to the support center by 15% by providing better self-help online.”
    You’ll probably find overlap with the information you provide for these six elements. That’s a Good Thing: strategy is an interlocking set of choices you make to overcome adversity and reach a desired position. Still, try to avoid direct repetition in wording. The overall logic should make a coherent storyline.

How To Use the UX Strategy Blueprint

Building UX strategy is a creative endeavor. Explore different options, asking “what if?” and “what would need to be true?” With the UX Strategy Blueprint, there is initially no risk in trying out alternatives: cross things off, move sticky notes around, rework ideas, crumple it up and start over again. Strategy is designed.

It’s best to start with the challenges and aspirations. After that you may find yourself bouncing around between the boxes. That’s fine. The Blueprint exposes the dependencies in strategic choice, letting you see all of the elements at once.

There are several situations in which you can use the UX Strategy Blueprint:

  • BRIEFINGS.  Bring a print-out of it to briefings. The Blueprint serves as a great checklist of questions to ask. Your notes will also be concise and captured in a single overview.
  • WORKSHOPS.  Hang a poster-size version of the Blueprint in kick-off meetings or strategy sessions. Use sticky notes to fill it out as a team. This guides the discussion and keeps the exercise focused, as well as builds consensus.
  • REFERENCE.  Post the completed Blueprint in the office for ready reference. This keeps your strategy in sight at all times.

The UX Strategy Blueprint can also be used online. There is a version of it, below, with open input fields, so you can capture the elements digitally as well. Or, try uploading an image of it as a background within an online collaboration board (e.g., Mural.ly, TUZZit.com) and apply virtual stickies as you go.

UX Strategy Blueprint (with input fields)

Once all of the elements have been agreed on, consolidate the strategy. A good, succinct strategy should only be about two pages long. Give it multiple forms to illustrate your intent to different audiences. Create a presentation, document and a graphic, as needed.

Share the strategy as often as possible. It’s hard to over communicate: print it out, hang it up, start every meeting with your strategy slide, use it as dummy text in wireframes instead of lorum ipsum. Reiterate.

Developing strategy is a craft, one that involves exploration and choice but also systematic thinking. The UX Strategy Blueprint helps you see all the moving parts in a single overview. In doing so, it simplifies strategy, making an abstract concept more tangible for all involved.

In financial terms, “debt“ is money borrowed by one party from another. The borrower can spend money they currently don’t have with an obligation to pay it back later, usually with interest. So, the borrower is willing to trade off added cost (interest) for immediacy (spending money now).

Debt allows us to buy things we couldn’t otherwise afford with cash, like a house or a car. It lets us invest our future, for example by funding an education or a business start-up. When the equity of our investments exceeds our debts, we come out ahead in the long run. Score!

But too much debt is a Bad Thing. If not repaid in a timely manner, the interest can surpass the debt. This leads to economic ruin. So it’s the management of debt that’s key, not avoiding it entirely.

debt

Technical debt” is a term programmers have been using for over a decade. The metaphor is simple: in software development, there are quicker ways to implement technology that are often messier and cut corners. There is a trade-off of immediacy over comprehensive system development.

But if left unchecked, these trade-offs ruin the overall technical system. Here’s why: with each future effort, programmers stumble over shortcuts in the system made previously for the sake of speed. This increasingly slows them down, which is like paying interest on a loan. Eventually, new development is unprofitable and not worth it all.

Ward Cunningham first used the metaphor “technical debt” to explain the refactoring work programmers strive to do. See his web page “Ward Explains Debt Metaphor for more. Be sure to watch the video.

UX DEBT

I’d like to encourage the use “UX debt” as a way to reflect the accumulation of learnings about improvements to the design of a product or service that go unaddressed over time.* UX debt is the difference between the desired user experience and the delivered product or service. Left unchecked, a backlog of UX debt can lead to a downward spiral of negative experiences.

I’ve been using the phrase “UX debt” in my past and present work, and it seems to resonate with people, making the notion of trade-off clear. And the language we use makes a difference. For instance, during a recent product UI review with my ex-colleague, Uday Gajendar, now UX design director at CloudPhysics, we were able to effectively characterize the build-up of neglected improvements as “UX debt.”

Debt – financial, technical, UX or otherwise – is inherently invisible. This makes describing it and quantifying it difficult. The banking industry has very clear means of doing showing how much you owe. The UX field should work on similar mechanisms to make visible the consequences of cutting corners over the long run.

Usability tests and heuristic evaluations catalog issues explicitly. This helps. Other measures include satisfaction surveys, such as SUS (system usability scale) and even feedback from NPS (net promoter scores). While useful (and even necessarily) in some organizations, these activities are “heavy” and time consuming. Alternatively, Lean UX methods seek to more rapidly come up with solutions that apply learnings from users.

The key is acknowledging UX debt and managing it actively. Note that this doesn’t necessarily mean getting everything right the first time, but implies getting UX fixes refactored and prioritized quickly thereafter. Paying down the UX debt is the real challenge, not tracking it, particularly in large organizations.

Keep in mind, the user’s experience is not in a closed system. UX debt is influenced by external forces in the market. Regardless of your industry, your website is one click away from someone’s favorite; your app sits right next to other popular apps (including games) on a smartphone or tablet. From a user’s point of view, their experience with your product competes with all other experiences they have. So, UX debt can shift quickly with user expectations: a great idea two years ago may seem outdated today.

“Just add another tab” or “Let’s squeeze a button on the UI” are signs that you’re incurring UX debt. Such short-term tactics may be OK initially. But at some point the overall design system or information architecture breaks. UX design cannot be continuously thought of like dressing up Mr Potato Head without going back and refactoring the UI.

mr potato head

UX debt accumulates almost instantly. Design must be iterative: it’s about ongoing optimization. And your processes must account for that. Very often Scrum and Kanban approaches are blind to UX debt. So also be cautious of we’ll-get-to-it-later promises. Jeff Gothelf sums it up well in the first sentence of his best-selling book, Lean UXThe biggest lie in software is Phase II.

One tactic is to plan a sprint or cycle in the middle of development reserved just for refactoring. Engineers can iron out their system issues during this time, but keep some resources available to fix known UX problems. Precede this sprint with a usability test, and you’ll have direct input on potential problems and fixes. This is commonly referred to as a design spike. In addition, plan time and resources to re-apply learnings back into the product design after launching. “Build > measure > learn” is a loop the implies starting again with “rebuild.”

With UX debt, the currency that’s borrowed is user efficiency and user frustration – things they own, not us. The cost we’re OK paying is reflected in sentiments like: “Sure, we know how to make our product easier to use and better for our customers, but we’re not going to do it.” It shouldn’t be an “or”: we need to manage technical debt and UX debt. It’s worth mentioning that the two may have overlap. For instance, slow load times may be the result of technical debt that also incur UX debt.

Ultimately, addressing UX debt must be a commitment from the organization. For UX designers, the language we use can help gain support. The metaphor “UX debt” illustrates the impact of short-term decisions on the user experience. Remember: if your user experience goes bankrupt, your company just might too.

 
* see more from Will Evans, “On UX Debt” ; Ben Melbourne, “UX Design Debt” ; Glen Lipka, “The UX of Technical Debt” ; Andrew Wright, “User Experience Debt

Below is a list of resources I reference in my workshop on UX strategy. Because UX strategy must ultimately align with business strategy, understanding the business side of things is imperative. Consequently many items below represent some of my favorite sources on business strategy and strategy in general.

This list is by no means comprehensive. You will find additional materials on many of the books cited below, e.g., Roger Martin has many articles and talks based on his book Playing To Win; or there is an entire site dedicated to blue ocean strategy including further references and tools.

You can download the slides from my IA Summit 2014 workshop on UX Strategy here, as well as a PDF template of my “UX Strategy Canvas” – a tool to help dissect and capture the key elements of your strategy.

.

I just gave a talk for World IA Day at U Mich in lovely Ann Arbor entitled “Undiscovered Public Knowledge and IA.” Below are the slides, followed by links to the resources I mentioned in the talk. (Apologies for comical looking fonts: they seem to have gotten messed up when uploading to SlideShare.)


RESOURCES MENTIONED:

Since the appearance of The Lean Startup by Eric Reis, “lean” approaches have taken off like wildfire. As the name implies, “lean” is about reducing waste.

In the case of Lean Startup it’s specifically about reducing waste in business innovation. It’s an entrepreneurial method that seeks to ensure the right market-offering fit. Lean Startup is a new approach to continuous re-invention and how to deal with the inherent uncertainty involved.

But “Lean” has a long history and can mean different things in different contexts. And just saying you’re “lean” doesn’t ensure you’re following the Lean Startup approach.

There are many misconceptions about Lean Startup in software development.

#1 Lean Startup is an engineering process. (No, it isn’t)

Lean Startup does not mean getting code out faster. Instead, it’s what happens before you build anything for commercialization. Look to agile and extreme programming for faster development, not to Lean Startup.

The cause of this misconception stems from how progress is measured, namely with learning. Ries writes in The Lean Startup :

Lean Startup asks people to start measuring their productivity differently. Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build–the thing customers want and will pay for—as quickly as possible. In other words, the Lean Startup is a new way of looking at the development of innovative new products that emphasizes fast iteration and customer insight, a huge vision, and great ambition, all at the same time.

Lean Startup often feels uncomfortable to production teams. Ries warns:

I predict that you pretty quickly will get feedback from your teams that the new process is reducing their productivity. They will ask to go back to the old way of working, in which they had the opportunity to “stay efficient” by working in larger batches and passing work between departments.

…When I worked as a programmer, that meant eight straight hours of programming without interruption. That was a good day. In contrast, if I was interrupted with questions, process, or—heaven forbid—meeting, I felt bad. What did I really accomplish that day? Code and product features were tangible to me; I could see them, understand them, and show them off. Learning, by contrast, is frustratingly intangible.

So remember: Lean Startup is all about getting the right value proposition, not cranking stuff out.

#2 Lean Startup means “just do it.” (Wrong!)

Many people think Lean Startup implies a lack of structure and rigor. Ready, fire, aim! On the contrary, Lean Startup requires discipline – a lot of it. But don’t conflate this type of discipline with traditional management techniques, which are often the cause of innovation failure in other contexts.

In The Lean Startup, Ries explicitly warns against the just-do-it attitude and reacting negatively to this new kind of discipline:

Entrepreneurs have been trying to fit the square peg of their unique problems into the round hole of general management for decades. As a result, many entrepreneurs take a “just do it” attitude, avoiding all forms of management, process, and discipline. Unfortunately, this approach leads to chaos more often that it does success.

What’s more, just moving quickly doesn’t ensure that you are following Lean Startup. You have to go through all the motions: What is your vision? What are your riskiest hypotheses? How will you test and measure your assumptions? When do you pivot? And so forth. That takes time, attention, and some elbow grease.

Lean Startup is a highly focused, team effort, not building whatever can get done fastest.

#3 An MVP is a lightweight version of a full functioning product. (Usually not)

The “P” in MVP (minimum viable product) is misleading. Keep in mind that customers don’t know what enables your product or service behind the scenes. From their perspective the product is what they see and experience. And that can often be faked.

Remember, your goal at first is not to build something but to learn. So an MVP should be the smallest thing you can do to validate or disprove hypotheses.

Ries writes in a blog post on MVPs:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP. In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

You need to get the right MVP to test. Recounting a real-life consulting situation, Steve Blank – a father of the lean movement – describes it well in his post “An MVP is not a Cheaper Product, It’s about Smart Learning.” Instead of building hardware and software to test an idea, Blank recommended the team rent the hardware and crunch the numbers by hand. Then give the results to the end consumer and see if they find it useful. No development needed at all, and the turn-around time for learning is days, not weeks or months.

Broadening your definition of MVP to “the shortest path to validated learning,” as lean expert Anders Ramsey defines it, will reduce a lot of waste upfront.

#4 User testing will just slow you down (Er, um…that’s the validation part)

With Lean Startup, progress is measured by learning, not meeting deadlines or budgets. And you will not learn by sitting around a table rationalizing your decisions.  As much as you’re convinced your product is amazingly awesome, you are not your customer. And you can’t will your enthusiasm on them.

Instead, you need to “get out of the building”, as Steve Blank has famously said. Reis proclaims in The Lean Startup:

Startups need extensive contact with potential customers to understand them, so get out of your chair and get to know them.

But the goal isn’t to get direct answers to your questions: they won’t be able to give a thumbs up or thumbs down on your vision or value proposition like voting. Instead, you must empathize with customers and see the world through their eyes. What’s their mental model of the world? Reis recommends employing techniques from the design canon:

There are many techniques for building an accurate customer archetype that have been developed over long years of practice in the design community. Traditional approaches such as interaction design or design thinking are enormously helpful.

And of course testing your MVP – even if it is a completely fake product – is an essential part of the Lean Startup process. So user testing should ultimately been seen as something that speeds you up because that’s when you learn. If anyone tells you otherwise, they’re not doing Lean Startup.

Follow

Get every new post delivered to your Inbox.

Join 79 other followers