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)
8:30
9:00 Cristina Walker (clinical SME) Nothing scheduled—debrief, review materials
9:30
10:00
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:00
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)
1:30
2:00 Ron LaFleur (products VP) Cynthia Woo (corporate marketing) Debrief, review schedule with Kate Riley (project owner)
2:30
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.

Summary

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.

The Stranger’s Long Neck

Written by: Jeff Parks

Show Time: 33 minutes 42 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

iTunes     Del.icio.us     Boxes and Arrows Podcast theme music generously provided by Bumper Tunes

Gerry McGovern has recently published The Stranger's Long Neck - How to Deliver What Your Customers Really Want.

Ireland’s Gerry McGovern shares a few of the key ideas in his recent publication The Stranger’s Long Neck – How to Deliver What Your Customers Really Want. Mr. McGovern, who will be teaching a Masterclass series in Canada on the importance of task management this November, discusses several of the key findings in his new book, including:

Trading with strangers

– The customer is a stranger. On the Web, the customer isn’t king—they’re dictator. When they come to your website, they have a small set of tasks (long neck) that really matter to them. If they can’t complete these top tasks quickly, they leave.
– There is an existential challenge going on right now between organization-centric and customer-centric thinking. Customer-centric thinking is winning.

From Long Tail to Dead Zone

– The Long Tail theory says that the Web allows you to sell more of less, that we are seeing the decline of the blockbuster and the rise of the niche.
– The Long Tail is often a Dead Zone of extremely low demand and hard to find, poor quality products.

The rise of the Long Neck

– The Web is exploding with quantity but quality is still relatively finite. Quality is the ‘long neck’; the small set of stuff that really matters to the customer.
– Understanding and managing the long neck has never been more important.
– Remember that the customer’s long neck—what really matters to the customer—is rarely the organization’s long neck —what really matters to the organization.

A secret method for understanding your customers

– A unique voting method that identifies your customers’ long neck.
– Developed over 10 years, with over 50,000 customers voting in multiple languages and countries.
– Used by the BBC, Tetra Pak, IKEA, Schlumberger, Wells Fargo, Microsoft, Cisco, OECD, Vanguard, Rolls-Royce, US Internal Revenue Service, etc.

Organization thinking versus customer thinking

– Case study that shows how car company managers think differently about how customers buy cars to how customers themselves think.
– Explanation of how to frame the task identification question.

Deliver what customers want—not what you want

– Case study of Microsoft Pinpoint, a website to help businesses find approved Microsoft IT vendors and consultants.
– What’s the top task of US small and medium businesses when it comes to IT? Security.

Measuring success: Back to basics

– Why traditional web metrics such as page views, number of visitors, etc., are often misleading
– Observation-based technique to measure online behaviour.
– The key metrics of task measurement: completion rate, disaster rate, completion time

Carrying out a task measurement

– The benefits of remote measurement
– How to run an actual measurement session

This podcast has been sponsored by:


Publishers of world class content for students, researchers, and practitioners in the UX and HCI fields. To learn more visit http://www.mkp.com/hci


From concepts to rich prototypes and detailed specifications, all in one tool. Get your free 30-day trial at www.axure.com

The design behind the design
Boxes & Arrows: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there. boxesandarrows.com/about/participate

So You Wanna Build a Library, Eh?

Written by: Nathan Curtis

Modular Web Design book coverThe following article is an abridged version of Chapter 7 of Nathan Curtis’s 2009 book, Modular Web Design published by New Riders. The book’s first half addresses how to modularly break down your design, build it back up, and communicate in new and interesting ways. With those design techniques in hand, the book then drills into how to organize and build a library, teach it to others, and establish a process for maintaining it for an organization.


Legos are so freakin' awesome!!! Design patterns and modular components are effective techniques for designing and building long-lasting, consistent experiences. You may reach the point where you ask yourself “Is it time to build a library for our team?”

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. It takes time and effort to get off the ground, can trigger significant and uncomfortable organizational change, and comes with an ongoing maintenance cost. In some cases, libraries are not the answer and yes, sometimes libraries fail. Nobody wants to invest the time, effort, and personal capital only to have nothing to show for it.

Therefore, precede any kind of library build out with a period of discernment. Before you dive, ask yourself and your teammates the following eight questions to gauge whether a library is right for you.

1. Why Do You Want Create a Library?

What is your primary rationale for building a library? What motivates you?
At the top of nearly everyone’s list is usually one of two benefits: efficiency or consistency. Some value speed through reuse: get design done faster, be more productive, save time, save money! Others see opportunities for governance and consistency, using the library as a baseline to sustain a design system over time.

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial.

Beyond efficiency and consistency, other benefits that drive teams include:

Memory: A destination to record and refer to all the design decisions made in creating a large-scale experience.

Portability: Designers come and go. Project priorities change. A library should make you more nimble in shifting resourcing and focus.

Vocabulary: Establish and promote common understanding that includes terms you use for items, page types, and even deliverables.

Authority: Provide a more credible resource on which to make design decisions, prioritize efforts, and easily refer to conventions.

Predictability: Have a foundation to discuss and more closely approximate the impact of a design decision.

Collaboration: Amp up collaboration in your organization to trigger conversations, share knowledge, and learn together.

2. Are You Building the Right Kind of Library?

When it comes to libraries, teams usually find themselves choosing between a library of patterns or components.

A design pattern is a solution to a recurring problem. Patterns offer principles to follow and avoid specifics like style, editorial guidelines, page location, and finalized code. Libraries of design patterns are ideal for teams that design many experiences, such as Yahoo’s team that designs products with unique visual systems that adhere to a larger, common brand.

A component is a chunk of a page design. Experiences can reuse components for navigation (such as header, footer, and local nav), content (such as video players and page titles), and more. A component library is ideal for organizations that have built a system of modular HTML and CSS, and these teams can complement the code library with a collection of reusable design assets for wireframes or comps.

Choosing between patterns and components may not be an either / or question. In fact, one team built libraries for both patterns (for example, Tabs) as well as components (for example, tabbed product details, tabbed content module, tabbed search results, and so on). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.

Consider a pattern library if your team has:

  • Many design systems that are intentionally different or will not be reconciled into a single component library.
  • Capability to document patterns more specific than public libraries like Yahoo Design Patterns, welie.com, and ui-patterns.com.
  • Known opposition to prescriptive approaches, but a willingness to use common guidelines.

Consider a component library if your team has:

  • A specific visual design system, including grid(s), layout, color palettes and typography.
  • Many reusable components (page “chunks”) within that system.
  • Diverse groups across an organization that must work together using that system.
  • Interest in and capability of sustaining that design and code system across groups, projects and time.
  • Strong, centralized influence to create, deploy, and maintain a library (or plans to centralize influence via a library).
A comprehensive library of design standards doesn’t end with design patterns and modular components. A team could consider … include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

Finally, a comprehensive library of design standards doesn’t end with design patterns and modular components. Instead, a team could consider expanding their repertoire to include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

3. Is Your Experience Ready for a Library?

Ok, so you’ve got dreams of efficiencies, consistency, standards, and more. However, just because you’ve built a website, that doesn’t automatically imply that you should build a library. In fact, there are plenty of websites for which a library won’t net any benefit. You should take a long, hard look at your design system to ensure it warrants a library.

Scale: Libraries can be invaluable to large, distributed teams supporting many products or a site with thousands – or millions – of pages. On the other hand, if you are a small and tight-knit team constantly communicating across cube walls, then there’s no need to codify standards. Heck, there’s no need to document anything at all – just get real and build stuff.

Relevance: Rarely do experiences of any scale contain no reusable elements. However, some site areas – like an e-commerce checkout or an account management portal – may be unique, built once, and not duplicated again short of a redesign. Why standardize something that’s never reused?

Stability: Be careful not to standardize an experience too soon. A design system should stabilize before you invest in codifying layouts, grids, typography, patterns, and components.

Disparity: Instead of one simple set of grids, styles, and reusable chunks, you may have multiple, distinct design systems. Do you merge them into one library? If now, is it worth it to create distinct and potentially overlapping libraries?

4. Is Someone Ready to be a Librarian?

Just because you’ve built a website, that doesn’t automatically imply that you should build a library.

Building and sustaining a component library takes an evangelizing advocate. That person may be you, or someone you manage or work with. Almost always, the librarian wears many hats:

Leader: You’ll promote a new way of thinking, shepherding participants into common practice and evangelizing the techniques, benefits, and spirit of the library.

Target: You’ll be a lightning rod for the library, and even the cause of controversy in a design organization. Others may point to you as the standards police that constrains them from being creative.

Writer: You’ll be an author, or at least a contributor and reviewer of other’s contributions, for items like guidelines, library cheat sheets, and blog posts.

Teacher: You’ll teach principles and basic fundamentals about what’s where and how to use it. Help requests can be disruptive, and you’ll have to be patient, determined, and flexible.

5. Is Your Design Team Ready for a Library?

A library can transform how a team operates. Gone are the days where every project is a blank canvas where a designer creates a creative and original work of art. Instead, designers are equipped with helpful starting points as a framework in which to operate. Those constraints can be simultaneously welcome and controversial.

Above all, your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. Templates with grids, libraries, styles, and pre-made page chunks don’t turn designers into robotic automatons. But designers often react that way. You’ll have to convince designers that library starting points can focus creativity.

Other team attributes that influence library readiness include:

Size: How big is your design team? The larger the team, the more likely techniques, styles and deliverables vary. Libraries and templates can get your team synched up and communicating more consistently.

Overlap: How much do designs contain overlapping patterns and components? If your team is designing towards a common experience, a library can be a key part of a holistic strategy.

Distribution: Is your team spread out geographically? Standard design assets can mitigate impacts of reduced face-to-face collaboration.

Adaptability: Will your team be able to adapt to design practices that involve a library?

Stability: How stable is your team? Do designers come and go often? Learning library details is an investment with a return that increases the longer each designer uses it.

Advocacy: Do you have team members that are jazzed about or knowledgeable of reuse? Are they willing to be partners or champions?

6. Is Your Organization Ready for a Library?

Your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel.

You’ll need to have a pitch that explains the library in simple and concrete terms. What is it? How does it work? What does it mean to me? These questions hint at the profound impacts a library can have:

Workflow: Design libraries impact at least two critical workflows: how you produce a solution for each project and how you maintain assets, guidelines, and documentation across projects.

Collaboration: Do key team members – such as engineers and designers – have a common foundation to communicate on?

Documentation: You got to make it easy for people to refer to, find, learn, and integrate reusable assets into their own practices, whether via a component ID annotation on a wireframe, a PDF’s link to online documentation, or consistent HTML comments in your code.

Timing: When change is in the air, there may be opportunity to insert a library into the discussion and approach. Can you time the expansion of your library to dovetail with when your experience are already undergoing significant change?

7. Is Management Ready to Support a Library?

None of your planning and efforts will matter if you lack management support. They must vocalize a public belief in your effort as well as pony up time, money, and resources. It’s your duty to communicate a plan – and the return on that investment – to sell your management on why a library matters.

Unfortunately, even when the library is otherwise a good idea, management support sometimes wavers in instances like:

Lack of Priority: It can happen to the best of teams. You get your top talent together, you start roughing out a framework, and then projects hit. You get distracted. It’s up to management to carve out sufficient time for you, or else the library becomes stale and ineffective.

Insufficient Hardware and Software: It’s up to managers to ensure that designers have the right hardware and software installed so they can use the design assets. My confusion turned into empathy when I sat at a designer’s desk and watched for TEN MINUTES as the software tool launched on his out-of-date laptop. My query of “This is unacceptable. Haven’t you asked for an update?” was met with “You can only ask so many times” and a shrug.

Leadership and Evangelism: Ensure management is on message. Prep them with simple ways to communicate library value and help them avoid undermining you with explanations like “the library is another good idea, but if it doesn’t work for you, shouldn’t disrupt your own personal approach if you feel your way is more effective.”

Background Support: Public declarations are important, but so are the back-channel efforts. Your managers need to open doors to connect you with key players and partners. Knowing what doors to open is a two-way street, so help your managers understand the obstacles and why you need help.

8. So, Are You Really Ready to Build a Library?

Take a deep breath, because you’ve got a fun ride ahead.

So, your design system is stable, you’ve got some champions backing you up, and you know just what your organization needs. You are ready to put yourself on the line. You believe.

Then take a deep breath, because you’ve got a fun ride ahead.

Creating a UX library diagram
Diagram of How to Create a UX Design Library (PDF)

Up next, you’ll want craft a plan and read all you can from all the best authors and online resources. You then discover, organize, and prioritize what goes in your library. You’ll setup a platform for managing your catalog and publishing your standards. You may even equip one or more software tools with a library of reusable assets so that your team can create better design and deliverables, faster.

It’s time to build a library.