A Stakeholder Interview Checklist

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

A Cheat Sheet For Interviewing Stakeholders

If you need a little help in your stakeholder interviews, tape a copy of this summary inside the front cover of your notebook.

Things to watch out for

  • Presumed constraints—ask why they are constraints
  • Jumping to solutions—ask what problem the solution would solve

All stakeholders

  • What is your role in this project?
  • What did you do before this?
  • What is this product going to be?
  • Who is this product for?
  • When is the version we’re designing going to be released?
  • What worries you about this project? What’s the worst thing that could happen?
  • What should this project accomplish for the business?
  • How will you, personally, define success for this project?
  • Is there anyone you think we need to speak with who isn’t on our list? Who?
  • How would you like to be involved in the rest of the project, and what’s the best way to reach you?

Marketing stakeholders

  • Who are your customers and users today, and how do you want that to be different in five years?
  • How does this product fit into the overall product strategy?
  • Who are the biggest competitors and what worries you about them?
  • How do you expect to differentiate this product?
  • Using a few key words, how do you want people to see your brand (both the company brand and the product brand)?
  • What is the current state of the identity, and can we see a style guide (if there is one) and examples of it applied to materials?

Engineering stakeholders

  • What technology decisions have already been made, and how firm are they?
  • How large is the development team assigned to the project, and what are their skills?
  • Would you draw a diagram and tell me in lay terms how the system works? (existing products only)

Sales stakeholders

  • Who is typically involved in the purchase decision?
  • Why do customers buy a product like this one, and why this one over competitor’s?
  • When you lose sales, what are the most common reasons?
  • What things do customers complain about or ask for most often, and why?

Senior executives

  • Questions similar to those for marketing stake-holders, plus:
  • What do I need to know that you don’t think other members of your team have said?
  • If you had to choose between going to market on schedule with a flawed product, or going to market late with a solid product, which would you choose? (If there seems to be some conflict on this point)

Subject matter experts

  • What are the typical demographics and skills of potential users, and how much variation in these is typical?
  • What distinctions in user roles and tasks would you expect us to see?
  • What sorts of workflows or practices do you think we’ll be seeing in the field?

Other product team members

  • QA: What problems do you currently see in development?
  • Support or customer service: What problems do you see most often?
  • Training or technical documentation: Where do users most often get confused today?

All parts of the chapter

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.

Project Management for Stakeholder Interviews

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

With good planning, most of your stakeholder interviews should fit within three or four days. Don’t plan on more than six interviews in a day, since they require a lot more energy than most people expect—you have to absorb what people are saying, figure out what the implications are, lead an effective interview, and take thorough notes all at the same time. A quick lunch and the occasional restroom break are essential. Plan on a short break after every couple of interviews to chat with your teammates, if possible. This table shows an example schedule.

Monday Tuesday Wednesday
8:00 Kickoff meeting Simon Parker (European sales)
9:00 Cristina Walker (clinical SME) Nothing scheduled—debrief, review materials
10:30 Ellen Kent and Ed Lieberman (product managers), walk through existing system Maria Torres (QA manager) Marty Long (mechanical engineer) and Jay Adachi (electrical engineer)
11:30 Lunch and debrief
Noon Lunch and debrief Lunch and debrief
12:30 Vijay Gupta (GUI lead) and Adam Matievich (lead architect)
1:00 Anders Haglund (sales VP) Collin Smith (CEO)
2:00 Ron LaFleur (products VP) Cynthia Woo (corporate marketing) Debrief, review schedule with Kate Riley (project owner)
3:00 Debrief Debrief Gunter Vering (professional services)
3:30 Tim Walsh (director of product management) John McIntyre (support manager)
4:00 Robin Sachs (regulatory issues)
4:30 Debrief, review schedule Debrief, review schedule

Try for at least a couple of the most critical stakeholders near the beginning of your schedule. If a few of the others need to be worked in between user interviews, that may not be a problem, but it’s preferable to finish stakeholder discussions first. That way, you’ll be aware of all the assumptions, opinions, and open issues you need to address in the user research.

When You Can’t Interview Stakeholders

The approach outlined above works well when you have an officially sanctioned project with support from the management team. If you don’t, how can you get some of this information? First, consider trying to get some of these meetings anyway; you may be surprised at how willing some executives are to spend time with you if you ask for help. Send them a persuasive, thoughtful email about how what they know could influence the design and how design decisions can affect business issues. Consider giving them a compelling article or short, interesting book on the subject. Seriously, try anything that won’t get you fired, because their involvement is ultimately necessary for the project to succeed. The one thing that won’t work is whining that you’re being excluded—instead, show them something so impressive they’ll see the value of including you for themselves.

If you simply cannot get access to the right people, see if you can get access to relevant documents they’ve created—white papers, memos, presentations, or whatever you can find. Build relationships with people in their departments so you can at least get indirect information. Above all, don’t give up—keep looking for opportunities to get them involved. Otherwise, they may very well involve themselves later, often with unfortunate results.


Goal-Directed design isn’t just about accomplishing user goals; a product or service that doesn’t also accomplish a business goal is a failure. Never shortchange your stakeholder research, even if it means compressing your time with potential users. Always:

  • Identify the full range of stakeholders and meet with each
  • Take advantage of the expertise that’s available
  • Learn about hopes, fears, beliefs, and goals
  • Avoid taking assumptions at face value
  • Remember that you’re not just asking questions—you’re also building essential relationships

Once you have a solid understanding of the business, you’re ready to move on to research with potential customers and users.

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.

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.

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.

Mythic Design

Written by: Christina Wodtke

When I agreed to teach a twelve-week course on user experience design, I did what anyone of us would do: I went to find something to copy. I trolled the articles and syllabi I could find online, and I was horrified. Sometime in the years between Jesse James Garrett’s lovely diagram and his incendiary demand that a room full of information architects, content strategists, and interaction designers rebrand themselves as user experience designers, user experience design had grown small. Jesse’s diagram starts with strategy and finishes with skin. His elements of user experience include deciding what to build, and how it looks. Yet the user experience designers I found were the wireframe people.

The wireframe people are designers who don’t design. They don’t make mental models, or do card sorts, or task analysis. They don’t write specs, and they certainly don’t do graphic design! They carefully do a collection of wireframes they then hand to “the designer” who hands it to the engineer. And the engineer, if he’s lucky, has a product manager who did all the interaction design work in the specs. And if he’s less lucky, he does it himself. No wonder many engineers view everyone except the graphic designer as essentially useless. Too often, they are. The wireframes people often call themselves user experience designers.

And forget stealing syllabi! Everywhere I looked classes taught Omnigraffle and touted the wonders of wireframes. No wonder the world was filling up with wireframe people.

So, to paraphrase the Grinch–who I was feeling like–“If I can’t find a user experience designer, I’ll make one instead!” I had a template in my mind of what I thought a user experience designer should look like. I had seen a new generation of designer I liked and hired every time I could.

They were medium-agnostic, code-fluent, and user-centered. They didn’t draw hard boundaries between information architecture and interaction design, and they flowed easily from task analysis into interface. When they did make wireframes, it was on whiteboards in conversations with engineers or as sketches in notebooks to clear their heads. I think of them as Mythic Designers because they would have been called unicorns by the specialists.

But even if these designers are rare, they do exist, just as family practice doctors still do in a world of cardiovascular surgeons and neurologists. These generalists do everything pretty darn well. They make good sites. They might not be the best people to call on if you had to build a Photoshop or a New York Times; complex interaction or massive content stores deserve the special skills of interaction design and information architecture. But if you are a startup, and you can hire one person, you want a real user experience designer. Just as when you don’t feel very good, you just want a doctor who can help.

But I was naive. You can’t make someone capable of designing a user’s experience in twelve weeks. I almost killed my poor students as I pressed five hours of lecture on interaction design into two, pounding them with conceptual models and use cases, activity-object models and task analysis. I knew I was teaching a foundations class and I would do nothing justice, but I kept trying. They wanted to learn Omnigraffle, I said no. They wanted to do wireframes, I told them wait. A student said, “I have never gone this long without designing anything,” and I despaired. They had designed task flows, use cases, site maps, conceptual models, and the basic social structure of their projects; and they thought they had designed nothing?

And then she said, “I’m so glad. We never get time to get our heads around our projects.”

And I got hope. I relented. My TA is going to run a workshop on Omni. I’ll teach them the fundamentals of interface design next week, in the guise of wireframes. Perhaps I’ll even start teaching them one way of doing something instead of three.

It has made me think that maybe the wireframe people wanted to do good design. And maybe they were given so little time to work, it was all they could do to choose between a multiple select list and radio buttons. And maybe they just needed to be taught some thinking tools and classic techniques. Perhaps what they really needed to be taught was to have faith in themselves, so they would demand the time it takes to make something worth making.

Ten years ago, they’d have been called web designers. In a sane world, we would have called them product designers. They chose their own name, user experience designers. And we old farts who have been designing forever need to help them, so they all can be called Mythic.

Designing Screens Using Cores and Paths

Written by: Jim Kalbach

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


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