Understanding the Business

Written by: Kim Goodwin

Boxes and Arrows is delighted to share this excerpt from Kim Goodwin’s excellent Designing for the Digital Age. When I recently taught a class on user experience design, I found few good resources on gathering business requirements. I was so happy when I cracked open Kim’s book and found exactly what my students needed. And thanks to her generosity, and Wiley’s, we are able to reprint the chapter in its entirety.
~Christina Wodtke, January 2013

 

While we designers like to think of ourselves as advocating for end users, we’re ultimately responsible for helping our customers: the employers or clients who hire us to help achieve certain organizational goals. This means every project should begin with understanding what the product or service is meant to accomplish. Is it primarily intended to build brand equity, reduce operational costs, or generate revenue? Blue-sky design won’t be helpful if the tool is only meant to save the company $100,000 a year but may be just the thing if it has the potential to bring in tens of millions.

Why is the project important? What’s driving the launch timeline? How ambitious a design is the organization capable of digesting? If you’d like to see your design make it out into the world instead of gathering dust on your shelf, these questions and many others about the business should be your point of departure.

Understanding the business starts with stakeholder interviews. As discussed in Chapter 2, stakeholders are the people in your organization (or your client’s organization, if you’re an outside consultant) who fund, build, test, market, sell, and support the product, plus anyone else who will influence the product’s direction. Who these people are varies from company to company, but the most influential are usually a product marketing or product management executive, the technical lead, and—in an ideal world—an executive to whom both of those people report. Sales people are as influential as marketing in some cases, less so in others. Enterprise software companies often have influential professional services organizations (people responsible for customization and implementation at customer sites).

You may also need to include someone from corporate marketing to discuss brand ideals and interpretation of the identity in the product. Subject matter experts may be stakeholders, also. In most companies, QA and support have very little authority or influence, but they often have useful information (and it’s always helpful to be on their good side, anyway). Don’t forget to account for other influencers, such as a consultant who has the CEO’s ear or a long-time employee who is not in a management role but is an opinion leader. Table 5.1 lists these stakeholders and the information they can offer.

Table 5.1 Typical stakeholders to interview

Role Typical titles What they know about
Product marketing lead Product manager, product marketing manager, program manager, director or manager of online marketing (for Web sites) Business case, mandate for the product or service, customer characteristics
Technical lead Director of engineering or R&D, architect Existing technical parameters, capabilities of the engineering team
Executive In large companies, a director or VP of products or marketing (for Web sites) In small or single-product companies, a CEO Any of the above, plus a perspective that hopefully balances objectives (marketing) and capabilities (engineering)
Sales VP or director of sales Customers
Brand steward Founder or CEO in small companies, director or VP of corporate marketing or brand strategy in larger ones What the brand means and how it’s evolving, where brand guidelines can be bent
Subject matter expert Usually found in the product marketing or product management group Domain, users (to some extent)
QA Manager or director of QA Another perspective on engineering skill level
Support Technical support or customer service manager Most common problems people have with the product
Professional services Manager or director of professional services or consulting Domain, customers, users (to some extent)
Other influencers Variable; typically consultants or long-time employees Variable

 

It’s crucial for the design team to establish relationships with these stakeholders as early as possible. Some of these are the people with the initial vision for the product, which will obviously drive what you do. Others may not be decision-makers, but can get you off on the right foot when it comes to the business issues, the domain, and sometimes even the political landscape (“You should probably know that Jim’s hot button is….”).

Early interviews are also an opportunity—sometimes your only opportunity—to build credibility and establish a line of communication with the stakeholders. It’s possible they’re still thinking of the design team as the people who will make the product pretty or fill the “easy to use” checkbox on the requirements list. By engaging the stakeholders at the right level, you can demonstrate that your work will be of far more than cosmetic value.

Identifying Stakeholders and Scheduling Interviews

If you’re an insider, you may already have a good idea who the influential stakeholders are. You may also think interviewing them is not necessary, but avoid this trap; hearing that executive’s point of view filtered through middle management isn’t the same as hearing her thoughts in her own words. If you’re a consultant, ask for your designated project owner’s help in identifying stakeholders. Give that person the list of roles that are usually important to involve; then advise him to include anyone else who has information you might need or whose opinion has the potential to derail the project later.

The number of stakeholder interviews varies quite a bit from company to company; a small startup may only have two or three, whereas a large corporation might have 50 stakeholders for a highly visible, political project, such as an intranet or corporate Web site.

In reality, you’re not likely to have 50 people who have significant influence on the direction of the project, but some organizations don’t do a good job of distinguishing between interest in the project and influence over its direction. If you don’t have time to interview them all, prioritize individual meetings with the decision-makers, top influencers, and people who have vital information, then conduct a brief group session with the rest.

Prioritize individual meetings with decision-makers, top influencers, and people who have vital information.

Conduct stakeholder interviews in person when possible; it’s easier to develop a rapport when you’re face-to-face. Also, it gives stakeholders a chance to assess your credibility and good will, which are important to establish early on.

Try to speak with stakeholders individually. When it’s necessary to group a few stakeholders together, keep them grouped by role (e.g., talk with several engineers and then several salespeople, but don’t mix the engineers and sales people). You need to hear about who is frustrated with whom and what the range of viewpoints is.

When scheduling stakeholder interviews, plan on having the whole design team attend, since every one of these discussions is likely to contain vital information. Allow for about an hour with most stakeholders, sometimes two hours with a technical lead or subject matter expert. Also plan on longer interviews if you and the stakeholder are not fluent in the same language; you will at least experience some long pauses as you both think through your communication, even if you don’t require a translator. Ask the stakeholders ahead of time to gather any white papers, specifications, or other information you think might be useful. The following sample invitation provides an example request for stakeholder participation.

Example of an invitation to stakeholders
As you may know, my colleagues and I are responsible for the product’s design. We understand that you are ultimately responsible for marketing Product X. We’d like to schedule a one-hour meeting with you next week to discuss the project. We’ll ask questions about your vision, goals, and concerns, as well as the role you expect to play in the project. We’d like to take advantage of your expertise, too, so we’ll have plenty of questions about XCorp and the industry. We would also appreciate it if you could share any useful documents, such as MRDs, white papers, or competitive product information.

Within your team, outline the key topics you want to cover with each stakeholder. After each team member has done several projects, you’ll find that preparation is minimal, since the information you need from each sort of stakeholder is fairly consistent from one project to another.

Beware invisible executives. A friend of mine calls them “torpedoes”—previously unseen stakeholders who can sneak up at high speed and blow the project out of the water. The product manager may seem to have total authority, but that’s only true as long as the CEO or other senior manager agrees with the project’s direction. If an executive sees something he doesn’t like or understand, the project could experience a 180° turn at any point.

Identifying the final authority can be difficult; the project owner is often oblivious to the potential for executive intervention. Listen closely in stakeholder interviews to identify likely issues. For example, “We tried to go that direction, but Dan hated it,” should prompt you to ask, “Who’s Dan? I haven’t heard his name before….” Another option is to ask each stakeholder you interview if there are any key influencers not already on your list.

Once you have identified these people, it can still be tricky to get the project owner to let you talk with them. I use examples from past projects to make my case.

On the negative side, I describe a couple of projects in which senior executives who were excluded for months disliked the final design because they hadn’t been part of the thought process that got us there. In one case, we smoothed things out within a few days, but the other took several months of comparative usability testing before we could move on.

On the positive side, I describe another project in which the client’s internal project team had shown idea after idea to an executive, only to have him reject every one of them. As a result, they tried to “protect” our design team by excluding that executive from our interview list. We insisted on doing something the internal team hadn’t done: we spent an hour asking him about his concerns, objectives, and ideas. It didn’t take long to understand why he had rejected the earlier designs. When we later presented our initial concept, he said, “That’s what I was looking for!” If we had not understood his concern, we might have gone down exactly the path he didn’t want to see.

Officially “Kicking Off” the Project

For some reason, the business world is rife with military and sports-related language: deploy a product, kick off a project, employ tactics…perhaps it’s because in business, just as in sports and the military, we have to rally the troops and get everyone on the same page of the playbook? Regardless of what we call it or why, an official project kickoff meeting is useful for several reasons. It:

  1. Draws everyone’s attention to what may be a major effort.
  2. Sets expectations about how much of their time will be required and when.
  3. Gets all of the key stakeholders in the same room at the same time to discuss goals, deliverables, assumptions, and timelines.
  4. Exposes the whole team directly to the executives’ vision, often for the first time.

Depending on how familiar the project is and how large the team is, a kickoff meeting will take anywhere from one to two and a half hours. After introductions, start by re-capping your understanding of the project’s goals and parameters, then walk everyone through the project plan and a high-level overview of the method. Often, there are multiple people in the room who weren’t involved with defining the project’s parameters (or the decision to hire a consultant, if you are one), so chances are this is information they need. Highlight the dates of critical meetings (such as the presentation of findings, personas, and requirements, as well as the design framework discussion) and ask everyone to reserve them, since you’ll need a full complement of stakeholders involved at each key decision point. See Figure 5.1.

5.1example-sched
Figure 5.1 Example of a project schedule overview from a kickoff meeting.

The research plan might engender controversy if it’s already been determined. Hopefully, the most knowledgeable stakeholders have had a hand in its creation, but in most organizations, everyone has an opinion. Make a note of any suggested additions or changes to the plan, then check in later with your project owner to determine what, if anything, you should do about them.

Whenever possible, have a group discussion centered on a few basic stakeholder questions. This is easier with some groups than with others. In a small group of stakeholders who are comfortable with one another, a simple facilitated discussion can be very effective. A group that’s large or very conscious of what the most senior person in the room thinks may call for more elaborate facilitation tools.

Write several essential questions on large sheets of paper and tape them to the walls, then give everyone a pen and some sticky notes to use in responding to the questions. Any of the questions from later in this chapter might be useful, but good starting points include:

  1. What is the product?
  2. Who will use it?
  3. What do users need?
  4. What customers and users are most important?
  5. What challenges do we face?

You can get creative with this and use different colors to distinguish hopes from concerns or facts from hypotheses, but don’t make the color coding so elaborate that people have to think much about it. Once you’ve gathered everyone’s thoughts, walk through them with the group, pointing out where there seems to be consensus. Use contrasting points of view as a basis for discussion with the large group, then pursue those topics further during the individual discussions.

Once the kickoff meeting is done, you’ll proceed into stakeholder discussions. It’s ideal to start with one or more of the executives primarily responsible for the vision, followed by several other stakeholders. Consider saving your project owner or one of the primary vision-keepers until the end, since that provides a good opportunity for clarification if you’ve heard a wide range of responses.

Conducting Stakeholder Interviews

Have one team member lead the discussion so the stakeholder doesn’t feel overwhelmed. All design team members should take notes, though one person should be designated as the primary note taker. This is usually one of the interaction designers, since these two people attend all of the interviews. When the stakeholder is primarily concerned with brand or physical hardware as opposed to product definition or software, the visual designer or industrial designer should lead the discussion. Team members who aren’t driving the interview should, at a minimum, have a chance to ask a few questions before the primary interviewer changes topics, as well as at the end of the interview.

Getting started

Hopefully, each stakeholder has attended the project kickoff meeting and is already acquainted with the basic goals and timeline of the project; if not, that’s a good place to start the discussion after everyone has been introduced. Before you start asking questions, talk about the way you’ll be approaching the interview. One essential disclaimer is something like, “We’re going to ask some deliberately naive questions. That doesn’t mean we haven’t done our homework—just that we want to hear your point of view.” Without this disclaimer, I’ve seen stakeholders go back to the project owner and ask why they hired such dumb designers who clearly know nothing about the business.

You might also reassure interviewees that you won’t quote them to anyone else, although you are obliged to tell the project owner in general terms when you hear significant disagreements. This kind of anonymity is something an outside consultant can insist upon, but is harder to manage if you’re an insider.

Things to watch out for

When it comes to design, everyone has opinions. You absolutely need to hear these ideas from stakeholders for a couple of reasons; first, there may be value in them, and second, telling the CEO you don’t want to hear her design ideas is unlikely to help your career. Of course, you also need to know what everyone’s pet ideas are so you can explain later why you didn’t take that direction with the design.

However, don’t take these assertions at face value—if the stakeholders had the design problem solved, you wouldn’t be there. Keep in mind that some people—especially busy executives—communicate by proposing solutions when what they really mean is, “I see a problem and I want you to fix it.”

One of my clients had a running joke about how an executive would see an idea for the hardware design, sigh, flip open his cell phone, and tell them to make the large, complex device more like the phone. The whole team was frustrated because their complex medical device didn’t have much in common with a cell phone, and the executive was frustrated because his team wasn’t getting it.

What he really meant was that they weren’t exploring any ideas with hinges or moving parts, which would allow the bulky device to take up less space when not in use (resolving a common customer complaint with the existing device). The moral of the story is this: When you hear someone propose a specific solution, listen to the proposal, then ask what problem that solution is meant to solve.

You may also hear long lists of constraints, musts, and deadlines, not all of which are as real as people believe them to be. Always ask why the stakeholder believes an assumption to be true. One of the more common assertions is that the product has to be browser-based—in 2001, I think I heard that on every project I did; today, people seem to be a little less thrilled with the idea, but it still comes up. This belief exists either because the customers are asking for it (and no one has asked the customers why they want it) or to avoid the need for individual workstation installation, which can be addressed in other ways.

Deadlines are another good example. Although some deadlines are driven by external forces, such as the need to show something new at a critical industry event, others are arbitrary targets the management team sets because they’re afraid of the product that never ships. If you know what’s driving a deadline, you’ll know whether it might be flexible.

The other thing to look for in stakeholder interviews is points of difference. In a perfect organization (if there is such a thing), all the stakeholders will say much the same things about the product, the customers, and the timeline, but some variation in views is normal. Pay attention to any extreme differences, as these represent both risks and opportunities. The risk is that such divergent perspectives could cause headaches in your future or derail the project entirely. The opportunity lies in using your later research data to help resolve those issues.

These are all the section in the chapter. We hope you’ll enjoy!

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

Designing Screens Using Cores and Paths

Written by: Jim Kalbach and Karen Lindemann

Desire path and desire cycle pathImagine you’re on one side of a grass lawn and you want to reach the bus stop on the opposite side. Do you walk on the sidewalk around the edges or cross in the middle? Assuming the grass is dry and it’s not prohibited, you’d probably take the shortest path and walk across the lawn to the bus stop. If others have done so before, you may see a beaten path that you could follow.

Such unplanned paths connect the shortest distance between two points, and we can find them everywhere in our surroundings. In urban planning they are known as “desire paths” or “desire lines.”[1] They are an indication of the gap between natural human behavior and contrived routes.

Architect Christopher Alexander recognizes desire lines in his renowned book, A Pattern Language (1976)[2]. He gives specific instructions for leveraging them in architecture:

To lay out paths, first place goals at natural points of interest. Then connect the goals to one another to form the paths.

Christopher Alexander

In principle, Alexander’s approach is to begin with the goals—the things people ultimately want—and then link them together in the most useful way.

Typically in web design, the opposite approach is the rule: designers begin with the homepage. They then work out a navigation scheme, which pages at the bottom of the site hierarchy automatically inherit whether it’s appropriate or not. The goal—or the primary content people are looking for or tasks they are trying to get done—turns out to be the last thing that gets attention in the design process.

Inspired by “desire lines”, we can reverse this tendency in Web design. Cores and Paths is a technique to guide you through the process of creating straight paths to the core offerings on your site.

The Cores and Paths Model

Instead of beginning with the homepage and overall navigation scheme, start with the core content and work outward from there.

“Start with the goal.” Information architect, Are Halland, makes this recommendation in his presentation “Cores and Paths: Designing for Findability”[3]. He outlines an alternative approach for web design: instead of beginning with the homepage and overall navigation scheme, start with the core content and work outward from there. It’s that straightforward.

The technique is based on three key elements:

1. The Core

The core is the reason users come to site. From the provider’s perspective, the core is what’s offered on the site. Note that the core isn’t always a page. For YouTube, the core is a video and not a page on www.youtube.com. This makes it possible to have distributable cores, or content that may be found on other websites.

The core may be accompanied by supporting information. Technical details, for instance, can be considered an extension of the core. On sites like flickr a description of a photo as well as the tags user give it are supporting information for the core, which is the photo itself.

2. Inward Paths

How do users get to the core? Sometimes visitors arrive at the core via the main navigation or search of site. But they might also come directly from Google. Other paths are possible as well, such as links from other sites, teasers, entering URLs directly in the browser, and even via rss feeds and newsletters. Thinking about inward paths also considers aspects of SEO, such as what the trigger words do people search with.

3. Outward Paths

Assuming users found what they were looking for, what can they do from there? What are their calls to action? Fundamentally every subsequent interaction should bring some kind of value to the business. This is where conversion takes place. Outward paths can be everything from placing an item in a “shopping cart” to recommending a product to a friend. As with inward paths, there are a variety of options to consider, including links that lead away from the site.

Each of these three elements has a different function. The core is really where value creation for both users and the business takes place. Persuasion plays a big role here: organizations ultimately want users to take some specific action. The inward paths ensure findability. This is how people come to the products and services they are looking for on the web. From a business standpoint, the outward paths are what bring ROI to an organization.

Below is an illustration of the Cores and Paths model, using Amazon as an example (Figure 1). The core is a product, represented here by an image of a book cover and its key details, indicated in the red box. Users find the book in numerous ways, listed on the left. These are the inward paths. Amazon sees a return on investment when users take action on the core, seen on the right as possible outward paths.

The Cores and Paths model for www.amazon.comFigure 1: The Cores and Paths model for www.amazon.com

The Cores and Paths Process

Imagine the following scenario:

You work for a small agency and have been contracted by a bicycle shop to improve their website. The shop currently only has a “brochure-like” website with address and opening times. They’d like to get into ecommerce and be able to sell online. The product line consists of high-end racing bikes and mountain bikes, along with the appropriate accessories for each. There are about 1000 products in total they want to sell online. The shop’s main target groups are professional cyclists and highly motivated amateurs. As a result, the bikes sold are primarily from premium brands. The design of the website should highlight the high quality of their products.

Following the Cores and Paths approach, here’s how to design the website from the inside out:

STEP 1: Define the core

What is the core offering? First, make a list of possible candidates: bicycles, accessories, services, etc. It initially starts with brainstorming so there are no right or wrong answers. After compiling a complete list, decide on a core and its supporting information. In large teams this means getting agreement from team members and stakeholders alike.

In the above scenario, the core is the product—a bike. A photo of the product is a central element to represent the core. The bike features, brand, and product line are types of information that belong to core in this case. Supporting information includes the price and additional technical details.

After deciding on and prioritizing these details, sketch the core (Figure 2). Don’t sketch the entire page with navigation and a logo: just focus on the core. Customers may want view details of the product up close, so consider how they will interact with the images even at this stage. Think about the experience visitors will have with the core once they find it.

Sketch of the core and supporting informationFigure 2: Sketch of the core and supporting information

Keep in mind that users will also be visiting the site from smartphones and tablets. And they may also post an image to Facebook or Pinterest. This is an example of a “distributable core.” So sketch how the core might transpose to these different contexts (Figure 3). Again, do this without sketching the page chrome or navigation—just focus on the core.

Versions of the core in different possible contexts.Figure 3: Versions of the core in different possible contexts.

From this you’ll see how the core and supporting information behave in different situations. You may have to go back and forth between the versions updating them iteratively.

STEP 2: List all possible inward paths.

What are all the ways that users can reach your core? Obvious things come to mind at first: site search, the main navigation, Google, and links from other websites. But more paths come into play as you brainstorm: links from comparison shopping sites and even references from offline media, such as a printed catalog.

For each inward path in your list, also write down the design requirements that must be met. For instance, SEO and landing page optimization is necessary for visitors coming from Google and other search engines. (See Figure 4)

A list of possible inward paths and the key requirements for eachFigure 4: A list of possible inward paths and the key requirements for each

STEP 3: List all possible outward paths.

Determine the paths away from the core. As in STEP 2, include design requirements for each outward path. This allows you to rank the outward paths in terms of importance to the business, providing clarity for the design in later on. (See Figure 5). Because outward paths ultimately provide value to the business, rank these according to business goals. A clear call to action button brings the user to the checkout process in this example. And if the customer can’t decide right away, a link to a wish list or to recommend the product to others is a second priority.

List of prioritized outward pathsFigure 5: List of prioritized outward paths

Up to this point, we’ve neither looked at the homepage nor have we thought about the navigation. Yet, we’ve addressed important design decisions, such what a mobile version of the core product might look like and how people will interact with the primary content of the site. After making these into higher-fidelity mock-ups, these initial representations could even be tested with users.

STEP 4: Put it all together.

Only after you’ve designed the core and listed the inward and outward paths should you start looking at the homepage and at the navigation. The goal at this point is to bring the user in the simplest, most-direct way possible to the core.

Design the homepage of the site, as well as gallery pages and search results. Sketch several alternatives. While doing this, keep the elements of Cores and Paths in mind: what is the core, how do users get to it, and how will the business see conversion?

Sketch of the homepage – a first draftFigure 6: Sketch of the homepage – a first draft

In this scenario, to get users from the homepage to the core the three product lines of the shop appear in the main navigation: “racing bikes,” “mountain bikes” and “accessories.” Since brand is also important to the target groups, a separate point for “brand” is also included. A prominent link to a shopping cart and checkout process is also located in the header.

Sketch of the gallery page with filters and sorting optionsFigure 7: Sketch of the gallery page with filters and sorting options

Below is a template we used to capture all of the points and steps described in this article (Figure 8). Download the template at the end of this article to try Cores and Paths out yourself!

A template for Cores and PathsFigure 8: A template for Cores and Paths

Summary

The Cores and Paths process improves design in several ways:

Identifies gaps. Questioning the purpose of the primary content upfront helps uncover gaps in the initial briefing.

Prioritizes design elements. Breaking down key elements helps prioritize how they appear in the overall design.

Focuses Design. Cores and Paths provides a clear direction to follow for the whole project team.

The difference between Cores and Paths and other approaches may seem subtle at first. But the impact is great: now, the core offering stands firmly in the middle of your design. All other elements in the site design serve the purpose of bringing both users and the business to their goal.

Footnotes

[1] “Desire path”, Wikipedia: http://en.wikipedia.org/wiki/Desire_path

[2] Christopher Alexander, A Pattern Language, 1976 (Amazon.com)

[3] Are Halland, “Core and Paths: Designing findability from the inside out”, EuroIA Summit, 2007: http://slidesha.re/dnwrLX

Integrating UX into the Product Backlog

Written by: Jon Innes

Integrating UX into the Product BacklogTeams moving to agile often struggle to integrate agile with best practices in user-centered design (UCD) and user experience (UX) in general. Fortunately, using a UX Integration Matrix helps integrate UX and agile by including UX information and requirements right in the product backlog.

While both agile and UX methods share some best practices—like iteration and defining requirements based on stories about users—agile and UX methods evolved for different purposes, supporting different values. Agile methods were developed without consideration for UX best practices. Early agile pioneers were working on in-house IT projects (custom software) or enterprise software [1, 2].

The economics are different in selling consumer products than when developing software for enterprises—UX matters more for consumer products. Jeff Bezos cares if users know how to click the button that puts money in his pocket more than Larry Ellison cares about any button in Oracle software. Larry makes money even if people can’t use his software. Oracle sells support contracts and professional services to fix things customers don’t like. Amazon and other online businesses can’t operate like that. They have to get the UX right, or they go out of business fast. User experience factors rarely get the same level of consideration when the end-user is not the same person as the paying customer [3].

Agile teams and UX problems

I’ve encountered two problems common among agile teams when helping them improve the user experience of their products or services:

  1. UX work is frequently overlooked during the release and sprint planning efforts.
  2. Teams often fail to measure the UX impact of their iterative efforts.

These two problems become more serious when combined.

When UX work goes undone and the impact is not measured, the team doing the work has no idea what is going on. The feedback loop is broken. Both agile and UX methods emphasize iteration, but productive iteration requires good feedback loops.

You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user. The User Experience Integration Matrix (UXI Matrix) addresses these problems by tying UX to the project backlog.

Integrating UX into the product backlog

You can conduct development iterations (the focus of agile) or design iterations (the focus of UX), but if you fail to measure the impact of the iteration, you won’t see the real benefits of an iterative process. You will have no real idea if your offering is any closer to meeting the needs of the end user.

Scrum (one of the most popular variants of agile) advocates you create a Product Backlog, a collection of stories that describe user needs. The team iteratively refines the requirements, from rough (and often ill defined) to more specific. This is achieved using stories from a user’s perspective, which have conditions of satisfaction associated with them. This concept is adapted from UCD’s scenario based design methods. In my view, this is far better than other traditional approaches to documenting requirements that are often detached from user’s goals.

Various agile gurus [4, 5] discuss how to break down requirements from high-level stories to user needs targeted at specific users. Even if your team follows Jeff Patton’s story mapping method [6], (which I highly recommend) to create structured hierarchical representations, you’ll often find you want to analyze the stories by different factors as you groom your backlog.

I’ve worked with teams who want to analyze stories the following ways:

  1. Order of dependency or workflow (self-service password reset depends on user registration)
  2. Criticality (which of these stories must be done so customers pay us next month)
  3. How much work will they take to complete (show me all the epics)
  4. What related stories do I have (find requirements with related UI patterns)
  5. By role or persona (show me all the stories that impact persona X)
  6. What stories have a high impact on the UX, so we can focus on those?

If the project is small (both in number of team members and number of stories) you might be able to get away with rearranging story cards on the wall. However, in my experience, things inevitably get more complex. You often want to consider multiple factors when reviewing the backlog. A UXI Matrix helps you track and view these multiple factors.

Creating a UX Integration Matrix

The UXI Matrix is a simple, flexible, tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams. To create a UX Integration Matrix, you add several UX-related data points to your user stories:

Column Name Possible Values Description
Persona Persona’s name Identifies the persona a user story applies to
UX complexity 1 to 5 (or Fibonacci numbers if you’re into that sort of thing) Estimates design effort separate from implementation effort
Story verified Y/N Is this story fiction or fact? Is it based on user research or customer input?
Design complete Y/N Is the design coherent enough for development to be able to code it (or estimate how long it would take to code)?
Task completion rates 0 to 100% The percentage of users who have been observed to complete the story without any assistance.
Staffing Resource’s name Who’s owns the design, at whatever level of fidelity is agreed to.

With these columns added, your product backlog begins to look something like the spreadsheet in figure 1.



Figure 1: UX Integration Matrix, a simplified example

Figure 1: UX Integration Matrix, a simplified example

Advantages to using the UXI Matrix

The UXI Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.

Groom the backlog

During release and sprint planning you can sort, group, and filter user stories in Excel:

  • Group by themes or epics, or anything you want to add via new columns
  • A primary persona, a set of personas, or number of personas associated (more = higher)
  • Stories you’ve verified via user research or ones you need to verify
  • Stories you’ve completed but need to refine based on metrics
  • Export stories into a format that can be used in information architecture work
  • Explore related UX deliverables like personas, mockups, and research findings via hyperlinks to them

Note the summary rows near the bottom of the example in Figure 1. Those values can help you prioritize new and existing stories based on various UX factors.

Reduce design overhead

Perhaps my experience is unusual, but even when I’ve worked on teams as small as seven people, we still had trouble identifying redundant user stories or personas. My heuristic is that if a story shares several personas with another story in a multi-user system, then that story may be a duplicate. Grouping by themes can also help here.

Another useful heuristic is that if a persona shares a large list of user stories with another persona, it’s likely the personas should be merged. Most of the time personas that do the exact same things with a product can use the same design, unless of course they have very different skills or something, which becomes evident when reviewing the personas or conducting user research (which all good personas are based on in my view).

Facilitate collaboration

The UX Integration Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process.

Another major benefit of the UXI Matrix format is you can share it with remote team members.

Listing assigned staff provides visibility into who’s doing what (see the columns under the heading Staffing). Team members can figure out who’s working on related stories and check on what’s complete, especially if you create a hyperlink to the design or research materials right there in the matrix.

For example, if there’s a Y in the Design Complete column, you can click the hyperlink on Y to review the design mockup. I’ve worked with teams who like to track review states here: work in progress (WIP), draft (D), reviewed ( R ), etc. (instead of just Y or N).

Track user involvement and other UX metrics

The UX Integration Matrix also helps track and share key UX metrics. One key metric to track is team contact with real end users. For example, if you’ve talked to real users to validate a persona, how many did you speak with? Another good metric is, how many users have been involved in testing the design (via usability tests, A/B tests, or otherwise)?

You can also capture objective, quantitative UX metrics like task completion rates, click/conversion rates, and satisfaction rates by persona. It makes it easier to convince the team to revisit previous designs when metrics show users cannot use a proposed design, or are unsatisfied with the current product or service. It can also be useful to track satisfaction by user story (or story specific stats from multivariate testing) in a column right next to the story.

Review UX metrics during sprint retrospectives

Scrum-style reviews and retrospectives are critical to improving both the design and team performance. However, few teams consider UX metrics as part of the retrospective. During these meetings, it’s helpful to have UX metrics next to the stories you are reviewing with the team.

I ask the team to answer these UX-related questions during the retrospective:

  1. Did we meet our UX goals for the sprint?
    1. Does our user research show that what we built is useful and usable?
    2. Are users satisfied with the new functionality (new stories)?
    3. Are users likely to promote our product or service (overall) to others?
    4. Do we have product usage metrics (via site analytics) that meet our expectations?
  2. Is there existing functionality (stories) that need to be refined before we add new stuff?
  3. What user research should we do to prioritize stories going forward?
  4. Do we have enough staff with UX skills to meet our objectives?
  5. Going forward should we:
    1. Work a sprint ahead to ensure we validate UX assumptions?
    2. Do a spike to refine a critical part of the UX?
    3. Refocus UX work on select user stories or personas?
    4. Improve our feedback mechanisms to capture factors we are missing today?


Annotated example

Figure 2: The UX Integration Matrix inserts key user experience activities and context adjacent to user stories into the product backlog.

Improving your team’s design decisions

Once you start tracking in the UX Integration Matrix it becomes easier to have informed discussions during reviews and retrospectives. I use the UXI Matrix to set UX goals with the team, help prioritize stories in the backlog, track UX work in progress, and to help answer the classic agile problem “what does done mean”; not just for the entire product or service, but for individual stories.

I’d be curious to hear from others who would like to share their experiences with variations of the above or similar methods. On the other hand, if you’re an agile guy that thinks this all is very non-agile, I’ll ask “can you really prove your method creates a better UX without this stuff?”

Start using the UXI Matrix in your next sprint. Download and customize this Excel template to get started:

[1] Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Pearson Education, 2004.

[2] Sutherland, Jeff. “Agile Development: Lessons learned from the first scrum”. Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 2004: http://www.scrumalliance.org/resources/35.

[3] Cagan, Martin. Inspired: How To Create Products Customers Love. SVPG Press, 2010.

[4] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.

[5] Cockburn, Alistair. Agile Software Development. Addison-Wesley Professional, 2001.

[6] Patton, Jeff; “It’s All In How You Slice It”, Better Software, January 2005: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf.

Are Design Patterns an Anti-pattern?

Written by: Steve Turbek

Sewing pattern

Design patterns are generally considered a good thing, but do they actually help run a user experience group? As a user experience group manager and an observer (and sponsor) of design pattern exercises, I’ve come to have serious questions about their actual utility. It’s not that design pattern libraries are bad, but that in a world of limited resources, it is it is not clear that the investment is worth it. Fortunately, there is a better approach: reaching outside the design group to solve the whole problem.

An interaction design pattern is a “general, reusable solution” “to common usability or accessibility problems”. They usually consist of pictures and descriptions of the best way to handle a GUI design element, such as a date picker. Libraries of them are found online (see below) and in many institutions with a user experience practice. Like all tools, they exist to solve a problem; but what is the problem?

They are generally said to help:

  • instruct junior user experience people
  • save time of documenting design details in every project
  • make collaboration with developers easier
  • encourage consistency

The case against design patterns

Pattern libraries have laudable goals, but in practice, design patterns do not support how teams actually work. Practically, the pattern approach assumes that the users:

  • know (and remember 3 months later) that the pattern library exists
  • quickly find the pattern that they need
  • know how to interpret the language
  • know when to apply a particular pattern and how much they can deviate
  • have the time and motivation to continue documenting ideas

Design patterns are not effective training tools.

Patterns, once literally a design on paper that could be copied, in UX are an abstract idea that professionals can reference. You can not copy a UX pattern, like you can copy a sewing pattern. Having someone read a pattern library will not make them a competent user experience designer. It would be akin to teaching writing by reading the dictionary – the “why”s are not answered.

Design patterns don’t replace UX expertise

Design patterns can be a useful reference point for the junior user experience designer. But experienced professionals find ideas and inspiration in the whole world. Should your team invest time in making a pattern library as a training tool, or just change the way they work? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

Should your team invest time in making a pattern library as a training tool, or just hire more experienced staff? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?

Completeness and learn-ability are in conflict.

In order for a pattern to be used, it has to be easily read. But completely describing even the simplest UI pattern (like a two-panel selector) requires such detail as to prevent the person from absorbing it. Additionally, any design pattern I’ve seen inevitable contains “it depends” clauses, which leave the important decisions right back with the reader.

Pattern libraries suffer from a similar problem. Many seem to start by defining the basics, to answer questions like “when should one use radio buttons versus a drop down menu”, but lose steam before they get to the complex pieces. This is ironic, as the complex interactions are the ones that need the most definition, and offer the most creative opportunity. Defining the pattern of a radio button, is necessary for completeness, but not a good use of time or creative energies.

Design Patterns take a lot of investment.

The investment in the library needs to pay off in later efficiency to be successful. But each pattern is essentially a mini design project with extreme documentation and design reviews. Having corresponding template widgets is an additional effort, as is updating the designs when the inevitable rebranding comes along. (I’m already tired just writing this.) If your team uses more than one design tool (InDesign, OmniGraffle, Visio), who is going to update all the versions?

Design Patterns should help non – UX people first

Design patterns reduce work for UX people, but they clearly increase work for developers. Developers operate under time pressures and need a spec to code to. Directing them to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe. The design pattern’s open ended nature requires them to read a general case and code a specific case. Because they are just designs, they can also ignore the ugly complexities in many of the problems, by simply not addressing them.

Design Patterns don’t work with a normal designer’s motivation – indeed, they seek to restrain it. When a person sits down at their drawing program to address a problem, a reference document is several steps away, especially under time pressure. They almost always want to design rather than copy, especially, when it is unclear if a new situation is different “enough” from an existing pattern. On the contribution side, any change will entail a review with peers, which could take weeks to finalize, too slow for a project. Large organizations who most need a pattern library (many practitioners) are least able to build one (complex organizations, conflicting deadlines).

Why do people make design pattern libraries anyway?

I’ve never heard of a business owner or technology lead asking for a design pattern library. They seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

Pattern libraries seem to be made by a UX person who wants to put a stamp on how things SHOULD be done. To establish, once and for all, the right way to do something. The design pattern library could be more akin to building a model train set: like the real world, but controllable. They are like design projects without clients or time pressure. “Just this once, we’ll do it perfect”. A participant at a recent New York IXDA event said with pride that he personally had created several pattern libraries –it was a personal accomplishment, not a business achievement. No one can argue with how a person spends their free time, but teams have to make sure work time is spent wisely.

The downside to this motivation is that individual authors want to create their own collection, which inevitably duplicates the other libraries. Pattern Libraries also tend to be abandoned when the author loses enthusiasm after the initial burst of activity. Even the major sites like Yahoo and Welie have stalled. The last update on Yahoo was 2 years ago; Welie was 4 years ago.

[Pattern libraries] seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?

What is the solution then?

Let’s apply the user centered design process to this situation. Using the goal of “better designed products and increased productivity”, we can identify the three potential audiences of an enterprise Pattern Library: User Experience, the Business representatives, and Technology.

The UX group is primarily concerned with consistency and best practices. This is culture, not documentations and should be managed as such:

  • Culture is built through personal interaction. Review, Review, Review. Regularly meet to share work, and best practices.
  • Patterns do not mean your design sense can go on auto-pilot.
  • Build a collaborative culture referring each other’s work. (“Joe worked on something like that.”)
  • When a new design challenge appears, get a bunch of people to talk it over, get “good enough” agreement.
  • Document decisions quickly and spread widely, for example on a wiki (so any one can edit it).
  • Focus on content first, make the pretty library template as a reward for reaching 20 patterns.

Business and Technology are primarily concerned with getting work done and reducing costs. The biggest efficiency gain is reducing development time, focus on giving developers the tools and guides they need. The biggest issue is that typically, UX people do not code. The solution is to get out of the design cave and work with people who do.

Create a design ecosystem instead of documentation.

People do not RTFM. Period. It is hard to get people to engage with any documentation on their own. They are happy to read the details about what they want, but are put off by finding it inside a large document or library. The solution is to create an ecosystem where each piece reinforces the others. iPods were well-designed devices, but they succeeded because of the ecosystem (devices +iTunes + stores + accessories). Music was easy to find and buy, and easy to put on the computer. The overall experience of the ecosystem is what determines the success. When you say the answer is a document, rather than a community, it turns people off and limits their contribution.

The ecosystem should be composed of:

  • People: Developers, Designers, and business leads. People who can answer questions, who are motivated by their own job requirements and professional pride
  • Code library and documentation
  • Management demand

A code library beats a pattern library

The code library should be “internal open source”, a shared library enabling developers at a company to share code without worrying about licensing or malware. Instead of the whole org waiting while a centralized team builds the future, let every group contribute.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests, supported by an active development and UX mail lists. Make them easily accessible as web pages, not a document. Style guides and pattern libraries get retained even if they are out of date. Social connectivity is much more important than printing them out.

It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests. This is supported by an active development and UX mail lists.

For each presentation layer technologies you support, there should be in Version Control system, with a Main branch, supported by a core team, and an open Contrib branch that anyone can put components in. Good components are promoted to the main branch, which is released in versions, so updates do not break existing apps.

Components should cover three scales:

  • Basic styling of standard components
  • Custom components, like a date picker or type-ahead
  • Page sized components, such as forms,dashboards, or search result pages
Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone.

How do you get such a library?

In a world of limited resources, one has to boot-strap the Library.

  • Build off of the current running projects. Nominate widgets or functions in an active project as “library-worthy” and have them coded abstractly and contributed to the library.
  • Publish and reward people who contribute to the library.
  • Make a most wanted list and see who has them.
  • Solve problems that you actually have, don’t worry about completeness.
  • Have the patterns in working code samples accessible by anyone in the firm. Instead of pretty pictures, have the code that actually performs how your want it to. Make the options / parameters editable in the sample, so anyone can play with configuring the sample.
  • Look and feel should be a separate code library, released in parallel, so that the design can be upgraded in the future (as it will be) without affecting functionality.
  • For general guidelines, write high level guidelines a sketch or two, but point the developers to ask a mailgroup of designers and front end engineers. When a question gets asked enough that it is annoying, code the pattern.

Management support is critical -if the project is a “nice to have”, it is doomed. Each project should report what they contributed to the library and what they consumed. A developer’s performance evaluation should list what they contributed to the library and what they re-used -Both save the firm money. At a firm I worked at – a single component, taking 2 weeks of two developers’ time, was re-used over 200 times. This saved 16 person-years of effort -this is real money. Not every component will be so effective; the library team should be focused on the business value of each component and the user experience of the eco system. If done right, the design / code ecosystem has the potential to both improve design and save time, something we can all agree on.

Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. Working together with non designers can make everyone’s life easier, and make the final product as good as the design.

Alignment Diagrams

Written by: Jim Kalbach

Alignment diagramsDid you ever get bounced around between departments when interacting with a company or service? This happened to me recently with my credit card: the card issuer and the bank backing it seemed to disagree who was responsible for my problem. Each blamed the other. I got caught in the middle.

My communication with them also crossed multiple channels. For some things I used their website, for others I had to call. There were emails, regular mail and even a fax involved as well. None of it seemed coordinated. Apparently it was my job to piece it together. Bad experience.

Why does this happen? 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 customers actually go through.

What’s more, logical solutions can cross departmental lines. Ideal solutions may require crossing those boundaries. An organization’s rigid decision making makes that difficult.

Here’s where I believe IAs and UX designers can use our skills to make a difference. We have the ability to understand and to map out both business processes and the user experience. Visual representations can provide new insight into solutions that appeal to a range of stakeholders. Alignment diagrams are a key tool to do this.

Mapping The Experience

Alignment diagrams reveal the touchpoints between a customer and a business. Illustrating these helps a company shift its inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible.

The phrase “alignment diagrams” describes 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. 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.

Alignment diagrams have two major parts. On the one side, they illustrate various aspects of user behavior—actions, thoughts, and feelings, among other aspects of their experience. On the other side, alignment diagrams reflect a company’s offerings and business process in some way. The areas where the two halves meet gives rise to touchpoints, or the interactions between customers and an organization.

Below are examples of two diagrams that illustrate the alignment principle.

Example 1: Service Blueprint

The first example is a service blueprint created by Brandon Schauer of Adaptive Path (Figure 1.). This shows the chronological flow of steps for attending a live event, in this case a panel on service design. (See the original details of the event from 2009 [1]).

The top two rows show the phases and physical devices a participant might use. We can call this the “front stage.” The bottom three rows show the activities of the organizer. These are “backstage” activities. These two parts are separated by the “line of interaction,” or touchpoints between participants and organizer of the event.
Service map

Figure 1: An example of a simple service blueprint by Brand Schauer, Adaptive Path

 

Example 2: Mental Model Diagram

The next example of an alignment diagram is a mental model. Indi Young developed this technique and detailed it in her book Mental Models (Rosenfeld Media, 2008) [2].

Figure 2 is a slightly simplified version of a mental model diagram, but it shows the alignment principle well. This example shows a mental model for activities related to “getting up in the morning.” The top half hierarchically arranges user actions, thoughts and feelings gleaned from primary research. These are clustered together into broader “goal spaces” (e.g., “Get Dressed”).

Below the center horizontal line are products and services that support people in these activities. With this alignment, providers of goods and services can see where they address user needs and where there are gaps.
Mental model

Figure 2: An example of a mental model diagram by Indi Young, reflecting the alignment principle.

 

There are other visual styles and approaches to alignment diagrams beyond the above figures. (See the list of Alignment Diagram resources at the end of this article.) Customer journey maps and workflow diagrams are also examples. So there is no single approach to the alignment technique. Instead, you choose the form, the information included, and the way you present them to shape your overall message. It depends on your situation. The important thing to remember is that an alignment diagram shows user behavior aligned to business activity to reveal touchpoints.

Locating Value

An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique.

Businesses ultimately need to earn money. But to do so they also have to provide some value to customers. An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique.

In a previous Boxes and Arrows article entitled “Searching for the Center of Design,” Jess McMullin proposes what he calls “value-centered design.” [3] Instead of focusing solely on the business or solely on users, Jess advocates focusing on how value is created for both. “Value-centered design” is the approach he prefers. He writes:

The basic premise of value-centered design is that shared value is the center of design. This value comes from the intersection of: business goals and context, individual goals and context, and the offering…and delivery.

Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction.

Jess McMullin, “Searching for the center of design”, Boxes and Arrows, 2003.

Alignment diagrams let us tell the story of value creation.

Once completed, alignment diagrams serve as diagnostic tools. With them we can spot and prioritize areas for improvement. They also point to opportunities for innovation and growth. Ultimately, alignment diagrams let designers capture and reflect how value is created in a holistic way. When communicated to decision makers, this can have real business impact by changing the focus from how products are made to the experience customers have.

Who Creates Alignment Diagrams?

Modern business challenges are wicked problems. Organizations unknowingly pass this complexity on to customers, resulting in negative user experiences. Alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face.

The good news is you probably already have the skills needed to create alignment diagrams. These include:

1. Conducting Research

Alignment diagrams are not made up. They are based on real data. Face-to-face interviews and observation work best. This includes contacting people on the business side: stakeholder research is part of the alignment technique.

2. Synthesizing Findings

Designers are good at describing abstract concepts, such as an intended experience. We’re able to empathize with users and summarize their perspective well. And we can communicate this back to our business partners in a way they can understand.

3. Visualizing Information

Alignment diagrams are visual stories. Designers are good at representing ideas in graphic form. The visual nature of alignment diagrams makes them compact and immediately understandable.

4. Brainstorming

Alignment diagrams serve as an excellent stimulus for a workshop or brainstorming session. Designers have the skills to creatively brainstorm and lead such sessions.

5. Prototyping Solutions

Exploring different directions is a key aspect of “design thinking.” Designers are well-versed in trying out different options—from sketching to wireframing to prototyping.

Keep in mind that the lines between design-related disciplines are blurring. Service designers increasingly use online services and digital kiosks in their concepts. UX designers must be able to integrate offline support and services into their solutions. IAs need to be able to structure information across channels, including physical spaces. Interaction designers must conceive of workflows and actions across media types and devices.

In the end, alignment diagrams aren’t the domain of one field or the other: they can inform any field. The skills needed to create them, listed above, cross these lines as well.

Getting Started

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.

Understanding the mechanics of alignment diagrams is fairly straight forward. The hard part is getting your foot in the door. Often designers aren’t called in until after a project is already set up. Alignment diagrams, however, really need to impact decisions much earlier in the process—before a project even starts. This means you need to “swim upstream” and reach out to a potentially new set of stakeholders.

For designers in internal teams, you may have access to managers, product owners and other executives who could benefit from alignment diagrams at a strategic level. For external consultants, pitching a case for an alignment diagram effort may be harder: reaching high-level decision makers is difficult. Either way, you’ll need to effectively evangelize alignment diagrams in order to get the time and money to complete one.

Here are some things you can do to get started:

1. Learn about alignment diagrams.

Start by reading books like Indi Young’s Mental Models. Or, check out things like my resources on customer journey mapping on the web [4]. I also have a presentation [5] and an article [6] coauthored with Paul Kahn specifically on alignment diagrams.

2. Sketch draft diagrams for your current project.

What story could you tell on your current project to show where customer value and business value is located? How would best visualize that story in a diagram? Even without any official project scope or user research, you can sketch out a rough map showing the facets of information you’d include, where alignment occurs, and how you would visually convey your message. This is practice in understanding the alignment technique.

3. Complete an alignment diagram “under the wire.”

A formal alignment diagram must be based on real evidence. But this evidence could come from a variety of sources. A high-level customer journey map, for instance, could be created with data from existing research. Or, try adding a few simple questions your next usability test to understand users’ interaction with a service. Create a draft diagram from this data as you do other types of analysis. Present this to stakeholders. It’s likely they’ll find it interesting and ask for more.

4. Find a champion in management.

Seek out business partners who might “get” alignment diagrams. Discuss the possibility of a pilot project with them. For the cost of a normal usability test, for instance, you could create a simple alignment diagram. Unlike outcomes from other types of research, such as marketing studies or usability tests, alignment diagrams do not change very quickly. Be sure to highlight the longevity of an alignment diagram effort to sponsors, and remind them they’ll be able to refer to the information years later.

Conclusion

If you’re interested in learning more about alignment diagrams, James Kalbach has scheduled workshops in Prague and London:

Keep an eye on the Boxes and Arrows Events Calendar for more.

 

Truth is, the business world is becoming increasingly complex. Studies in business complexity show that leaders are unable to cope: they are pulled in different directions and unable to focus [7, 8]. Modern business challenges are wicked problems. All too often, organizations unknowingly pass this complexity on to customers, resulting in negative user experiences.

While they do not guarantee success, 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.

Designers can use their skills to map out value creation and help solve business problems. Empathizing with users and illustrating out their experiences plays a big role. Visualizing touchpoints provides an immediate “big picture” often lacking in many organizations. This can provide a much-needed shift of attention from inside-out to outside-in. Alignment diagrams are a class of documents that seek to address the causes of poor experiences at their roots and ultimately help designers have a real business impact.

 

[1] Brandon Schauer, Service Blueprint, http://adaptivepath.com/ideas/this-thursday-in-sf-service-design-panel-kicker-kickoff

[2] Indi Young, Mental Models (Rosenfeld Media, 2008). http://rosenfeldmedia.com/books/mental-models/

[3] Jess McMullin, “Searching for the Center of Design,” Boxes and Arrows (Sept 2003). http://www.boxesandarrows.com/view/searching_for_the_center_of_design

[4] James Kalbach, “Customer Journey Mapping Resources on the Web.” http://experiencinginformation.wordpress.com/2010/05/10/customer-journey-mapping-resources-on-the-web/

[5] James Kalbach, “Alignment Diagrams: Strategic UX Deliverables,” Euro IA Conference (Paris, 2010). http://www.slideshare.net/Kalbach/james-kalbach-alignment-diagrams-euro-ia-2010

[6] James Kalbach and Paul Kahn, “Locating Value with Alignment Diagrams,” Parsons Journal of Information Mapping (April 2010). http://piim.newschool.edu/journal/issues/2011/02/pdfs/ParsonsJournalForInformationMapping_Kalbach-James+Kahn-Paul.pdf

[7] IBM, “Capitalizing on Complexity,” (2010). http://www-935.ibm.com/services/us/ceo/ceostudy2010/

[8] Booz & Co, “Executives Say They’re Pulled in Too Many Directions and That Their Company’s Capabilities Don’t Support Their Strategy,” (Feb 2011). http://www.strategyand.pwc.com/global/home/press/article/49007867