Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 21 2012


Designing Screens Using Cores and Paths

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 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

Figure 1: The Cores and Paths model for

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 information

Figure 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 each

Figure 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 paths

Figure 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 draft

Figure 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 options

Figure 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 Paths

Figure 8: A template for Cores and Paths


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.


[1] “Desire path”, Wikipedia:

[2] Christopher Alexander, A Pattern Language, 1976 (

[3] Are Halland, “Core and Paths: Designing findability from the inside out”, EuroIA Summit, 2007:

February 03 2012


Integrating UX into the Product Backlog

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 NamePossible ValuesDescriptionPersonaPersona’s nameIdentifies the persona a user story applies toUX complexity1 to 5 (or Fibonacci numbers if you’re into that sort of thing)Estimates design effort separate from implementation effortStory verifiedY/NIs this story fiction or fact? Is it based on user research or customer input?Design completeY/NIs the design coherent enough for development to be able to code it (or estimate how long it would take to code)?Task completion rates0 to 100%The percentage of users who have been observed to complete the story without any assistance.StaffingResource’s nameWho’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?”


[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:

[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:

Sponsored post

January 26 2012


Are Design Patterns an Anti-pattern?

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.

September 07 2011


Alignment Diagrams

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.


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,

[2] Indi Young, Mental Models (Rosenfeld Media, 2008).

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

[4] James Kalbach, “Customer Journey Mapping Resources on the Web.”

[5] James Kalbach, “Alignment Diagrams: Strategic UX Deliverables,” Euro IA Conference (Paris, 2010).

[6] James Kalbach and Paul Kahn, “Locating Value with Alignment Diagrams,” Parsons Journal of Information Mapping (April 2010).

[7] IBM, “Capitalizing on Complexity,” (2010).

[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).

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...