Interviewing Executives and SME Stakeholders

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.

Senior executives

Ideally, there is at least one executive involved who has cross-functional authority and can balance the perspectives of both marketing and engineering; you need this person to make critical decisions, such as what’s worth waiting a little longer for. These are usually the most critical stakeholder interviews, because the way other team members approach product development depends on the views of the people at the top.

It can be difficult to get on a senior executive’s schedule, particularly if the executives regard the product’s design as a secondary concern. If they seem reluctant to spend the time, point out the kinds of strategic decisions that will be made in the course of the design work. However, most executives are more willing to spend this kind of time than people expect.

The concerns of senior executives may include any of the concerns mentioned above for marketing, sales, or engineering, as well as a common concern that they can’t get their subordinates to “see the big picture.”

What do we need to know that you don’t think other members of your team have said?

Senior executives often have a vision or perspective that others in the organization don’t. If they’ve shared that vision much at all, you will have heard it already from multiple people, but some executives communicate about their vision less than they think they do.

We know that both timeline and functionality are important, but if you had to choose one, what would it be?

When there seems to be some controversy about schedule, it’s usually because senior executives are asking to their teams to make omelettes without breaking any eggs. Mention the controversy, then ask what timeline they want you to design for and whether they would rather go to market with an incomplete product or delay shipment to get a product that meets more user needs. (Some designers frame this as “do it fast or do it right,” but it’s best to suspend this kind of judgment; sometimes, doing it “right” means shipping at a certain time to get critical revenue in the door, so tradeoffs have to be made.)

Subject matter experts

If you are working on a consumer product or a business product that involves common work or life activities, you probably won’t need domain experts to help you understand what you see in your research. For products in complex industries, though, subject matter experts (SMEs) are incredibly helpful to have around—so helpful that you might want to hire a consultant to spend a few hours here and there, if there is no expert already on the product team. Even in-house designers with a lot of experience working on certain products can benefit from the perspective of people with deep industry expertise, though they may be able to skip some of the following questions. In-house SMEs are usually part of a product management or professional services group.

A subject matter expert isn’t just someone who was a user (or did a similar job) once upon a time—it’s someone who has broad and deep industry experience and who understands industry best (and worst) practices. If your product overlaps a couple of disciplines, it’s best to have an SME in each; for example, when designing a device that delivers intravenous medication to patients in a hospital, we found it helpful to have the perspectives of both a pharmacy expert, who had a thorough understanding of the drugs, and a nursing expert, who had a thorough understanding of clinical practice.

Beware of getting presumed SMEs who are a little outside their expertise, though—for example, a surgeon who spends his time in the operating room is not an expert in how nurses do their jobs on the hospital ward.

Unless they’ve worked with you before, SMEs will be more concerned than anyone else that you won’t be able to understand their incredibly complex world, since it took them many years to get where they are. They usually wind up surprised at how quickly immersion in the usage environment can educate the design team. However, it’s important to be clear that good research techniques will let you develop a working vocabulary and high-level understanding very quickly, but you will be absolutely reliant on the SMEs for their detailed knowledge.

Spend a couple of hours with SMEs before the user interviews to get some background. Get definitions of terms, ask about best and worst practices, common processes, and regulations. If you’re talking about processes, ask the SME to diagram them on the whiteboard or do this yourself, using your sketches as a discussion tool.

Specific topics will vary by domain, but here are some typical topics to cover with SMEs:

What are the typical demographics and skills of potential users, and how much do these vary?

This information is handy for planning your interview sample, as well as for assessing how typical your actual interviewees seem to be in these respects.

What distinctions in user roles and tasks would you expect us to see?

A SME may be able to tell you about likely differences, such as tasks that vary based on seniority or skill levels that differ with geography. They probably won’t be able to point out all of those factors that make people behave differently, but they should at least be able to give you enough background to help determine how large an interview sample you need.

What sorts of workflows or practices do you think we’ll be seeing in the field?

Some SMEs will describe only the best practices in their industry, while others are very good at pointing out where reality tends to deviate from what people are supposed to do. This kind of discussion is a great way to think about topics you’ll want to explore in user interviews. However, avoid getting into tremendous detail or spending more than an hour or so on this, because you will still want to look at user behavior from a fresh point of view. A certain amount of ignorance helps you ask the naïve questions that can lead to important insights.

Other product team members

In theory, some organizations place QA and support on a par with marketing, sales, and development, but in practice, these organizations seldom have much influence over product direction. However, they may have a variety of useful insights, and at a minimum, they will be able to answer two important questions.

An experienced QA manager can often tell you how solid the engineering team is and can point out process holes that are currently leading to problems. The support or customer service team can tell you where users are most often encountering problems today, whether this is based on tech support calls for software or common failures for hardware—either could mean a flaw in the current design. In some companies, there are other groups that can provide useful information, as well, such as the training staff or technical writers, who may be able to identify where users most often get confused with the current products. Regulatory experts are also indispensable for medical products.

See also

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.

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.

Continue reading A Stakeholder Interview Checklist

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.