Transitioning from User Experience to Product Management

Written by: Jeff Lash

This is part 2 in our series on product management and user experience. Previous parts in the series include Transitioning from User Experience to Product Management, Part 1

In Part 1, we outlined the responsibilities of product managers, the distinctions between product management (PM) and the user experience (UX) profession, and why there is sometimes conflict between the two roles.

Now, we’ll cover how moving into product management will change your focus, responsibilities, and challenges; what you will gain and lose leaving user experience work; and some ways to prepare yourself for the move.

Before you jump off the PM cliff, you should be aware of how making the leap affects your role.

What you do as a PM that you don’t do as UX professional

As a product manager, your everyday work life will change greatly. You get to take your deep knowledge of the users and use it to permeate the whole product. You were able to do this as a UX professional, but perhaps you didn’t have the official license to interact with as many decision-making groups across the company. Here are some of the ways you can do that in your new responsibilities:

Focus product strategy on customer and end user needs. This is why you make the leap.
Find the place where what user desires meet the business goals. You have been studying the customers and users for a long time; take that knowledge and make it the purpose of the product.

Help ensure user focus throughout entire product, not just the design.
The communications, policies, and pricing should all coalesce into an entire “customer experience.” We often don’t appreciate the importance of these aspects in shaping the user experience, but as a product manager you will be responsible for every aspect of the product that contributes to the overall product experience.

Balance the various forces.
It is important to ensure your product is focused on customer and user needs, but many other forces that need to be considered. Some (but certainly not all!) include:
* Sales objectives
* Marketing/branding objectives
* Technology strategy
* Portfolio management
* Budget management
* Market trends
* Competition
* Business model effects and revenue considerations (possible cannibalization, affect of changes, leveraging value, etc.)

Doing what is best for the product is a series of constant tradeoffs among internal business objectives, user needs, and market effects. As product manager, you manage tradeoffs to achieve balance where these forces meet.

Evangelize the product.
You must champion of the product both internally (to sales, marketing, executives, and developers) and externally (to customers, users, industry analysts, and the press). It’s not enough to develop a good product; you have to let people know about it and communicate the benefits.

Provide input on strategies for other products within the organization.
If you’re a product manager at a medium or large company, you’ll be in a position to influence other products as well. As you interact with other product managers across the business, you need to consider the company’s overall portfolio of products and how your product fits within it.

Challenges and forces working against you

Your new role in product management may seem all glory and power. And although your title will give you a bit more influence than you may have had otherwise, it’s not all wine and roses. There are some challenging aspects to the role and forces working against you.

As a product manager, you have little to no actual authority.
Guy Kawasaki described a product manager as “someone who has all of the responsibility and none of the power.” [1] Most of the other people working on your product will report into different management. Few, if any, staff will report to you. You must align these disparate resources and guide their work even as they get differing direction from their direct managers.

You will make and be held accountable for decisions, not recommendations.
In fact, you will make a lot of decisions and be held accountable for them. Not everyone will agree with you, of course. If you do your job well, you can justify those decisions, explain your rationale, be transparent, and people won’t be too upset or take it personally. But it’s tough.

Former user experience professionals may find it difficult that the decisions contributing to creating an experience are not necessarily the “best” for the user. Since there are other key factors to consider (e.g., other stakeholders’ needs, business strategy, business model, etc.), there will be times when a product manager has to make a conscious decision that may seem bad for users, but is ultimately the right decision for the product.

You will be at the center of regular disagreements between stakeholders.
Sales wants different functionality; development is pushing back against your timeline; finance needs new back-end functionality; business development wants changes to support partnerships; designers want to change a feature implementation; customers want a new feature a competitor just added; executives want integration with a new company product.

The product manager is right in the middle of these competing forces, and this can be dangerous political ground in some organizations. You need to manage these conflicting ideas and priorities while making progress on your strategy and keeping everyone happy (or at least not too angry).

Successful product managers balance these forces by focusing on the overall vision and strategy, making decisions that best support those higher-level objectives. The more a PM can understand about each stakeholder’s objectives and goals, the easier it is to navigate the various trade-offs you have to make. Sometimes it may mean conceding small points to obtain buy-in from stakeholders. Other times it may mean working to better align objectives across the stakeholder groups.

Management will look to you for information about the product.
The product manager is not just another player on the product development team—you will be the figurehead for the product. Whether things are going well or falling apart, whether you really have control or not, you are accountable.

What you do as a UX professional that you won’t do as product manager

Those making the transition from UX to product management will take on exciting and challenging new responsibilities. At the same time, you may miss some aspects of UX:

Product managers do not get dirty hands.
This is one of the hardest challenges for those used to being involved in pixel-level decisions. Most of the detailed work will be delegated to other people. PMs that spend more than a brief period of time dealing with product decisions at the detail level are not doing their job well. Product managers need to be more strategic than tactical.

Product managers do not have the luxury of shooting for perfection and the theoretical ideal.
The joke is that user experience people always answer a question with “It depends.” As a product manager, it may depend, but that’s irrelevant. It’s not about what theoretically should happen, it’s about what we should do right now in this situation and why.

You will need to get comfortable with the idea of “good enough” and be OK with decisions that may not be ideal for the user but make optimal use of limited resources.

Product managers do not make recommendations about the core areas of the product.
This is the opposite of the point we made above. While UX practitioners make recommendations constantly, product managers make decisions about the strategy, high-level user experience, feature set, marketing plan, pricing, and other aspects of the product. The reason we mention this again is to encourage you to reflect. If you like making recommendations or have difficulty making decisions, you’re probably not cut out to be a product manager.

Product managers are not artists or expert practitioners.
They are not the go-to person for any one aspect of the product. Instead, they need to know a bit about all aspects of the product. They serve as captains or coaches and drive the bus. In this capacity, product managers lead partly by working with those around them to ensure the strategy and vision are reflected in other areas such as marketing strategy, UI design, and copywriting.

It may be difficult to adjust to not being the expert in any one area. Learning how to lead other experts towards a shared goal is a challenge that will serve you for the rest of your career.

Work better with your PM now

If, after learning about the “behind the scenes” of product management, you are interested in making the move, there is one very simple way to get started: work more closely and productively with your product managers now. This is a worthwhile strategy even for those do not have the traits, skills, or desire to be a product manager. Better understanding of the responsibilities and challenges that that other team members face can help you as a UX practitioner adjust the way you work with these other roles and ultimately help you become more valuable, respected, and influential.

As recovering, er, “former” user experience practitioners, we have identified areas where UX practitioners can work better with product managers. These are some of the best ways to feel out a new role and can help you no matter whether you actually make the move.

Lead!
Don’t want for a product manager or other team member to request a specific research activity or design deliverable. In many cases, other team members will welcome your initiative and ideas. At other times, there will be differences in opinion, but action brings those out in the open quickly and focuses the debate on something concrete rather than theory or conjecture.

We do not suggest you be sly or hide things from the product manager, but his or her signoff on every action you take is not necessary. This is one case where it is better to ask for forgiveness than permission.

Ask product managers what their goals are for their product.
Asking about goals is great for two reasons. First, it makes them think about the product goals, which they may have never explicitly considered before. If so, you have an opportunity to be a trusted advisor and help them establish the goals.

Second, if the product manager has established goals, you will have a very clear set of objectives and expectations. If their goals do not make sense, you can get clarification, identify where you are not in alignment, and determine how to make corrections.

Help your PM factor in all aspects of a design and evaluate alternatives.
Don’t just propose designs and wait for a decision. Prepare yourself to discuss the impacts of specific design choices. Present the reasons behind your decisions and how they relate back to the broader vision and objectives. Listen to what the product manager says about the design, and probe for the reasons behind their objections and endorsements.

Make strong recommendations and include the big picture.
By giving counsel supported by evidence and experience, you become a more integral part of the product and will be seen as more than just an ancillary consultant. This will also provide practice on making decisions in the face of conflicting evidence and varying factors, which can be useful if you decide to move into product management.

Show your grasp of the big picture in your work, and you will be a more important member of the team and show your potential for greater responsibilities, no matter what direction you decide to take.

Help product managers get out of the office!
Product managers should not need coaxing to meet with customers and users in person, but many do. You can help by asking them when they last met with a customer, bringing them along on formal or informal research, or telling stories about valuable meetings with customers. Invite them along next time, and if they say no, keep asking.

If product managers are going to meet customers on their own, ask to go with them. In addition to learning about customer needs, these are great opportunities to spend time with your product manager and learn more about his perspective, interests, and goals.

If you really cannot get product managers out of the office, bring users and customers in. At that point, there’s absolutely no excuse for product managers (or anyone on the product development team) to not be interacting regularly with customers!

Studying and preparing for your PM role

So, you want to be a product manager? Not sure where to start? In addition to focusing on the ideas described above, you can start adding to your knowledge of product management to get a feel for what you’ll need to focus on as you start to make the move.

Think about the steps you took when you started in user experience. Books, blogs, conferences, discussion groups, organizations, and mentors all probably played an important role. The same opportunities are available if you’re interested in product management.

A great introduction to product management is through training and conferences. Apologies for the shameless plug, but we’d be remiss if we didn’t mention our pre-conference session at the 2007 IA Summit: So, You Want to Be a Product Manager. This half-day workshop will focus on how to make the transition from user experience to product management, including how to most effectively leverage your current skills and how to avoid potential pitfalls.

Other training classes related to product management are offered by many organizations, including:
* Pragmatic Marketing
* 280 Group
* Blackblot
* ZigZag Marketing
* Silicon Valley Product Group

Plenty of great blogs discuss product management. You might start with these select:
* Roger Cauvin’s blog
* Pragmatic Marketing’s blog
* SVPG Blog
* The Product Management View
* Tyner Blain
* Michael on Product Management & Marketing
* How To Be A Good Product Manager (by co-author Jeff Lash)

While there are not as many books written on product management as user experience, these staples can anchor any product manager’s library:
* Winning at New Products: Accelerating the Process from Idea to Launch, by Robert Cooper
* Software Product Management Essentials, by Alissa Dver
* The Product Manager’s Handbook, by Linda Gorchels

Additionally, aspiring product managers would be wise to read up on general management responsibilities such as leadership, management, marketing, finance, technology, and strategy.

There are two major organizations for product managers: PDMA (Product Development and Management Association) and AIPMM (Association of International Product Marketing and Product Management). Both offer training, conferences, local groups, and other product management resources.

Also, use your professional network—maybe with the help of a service like LinkedIn—to find product managers with whom you can set up informational interviews or discuss product management questions. Product managers within your company may be able to mentor you, and product managers from other organizations can give you a different and potentially more honest perspective.

As you learn more about product management and think about making a move, talk with your own manager. Most good managers will be glad to help someone grow personally and professionally, even if it means helping them move to another position within the organization.

So, DO you want to be a product manager?

We have tried here to provide some insights gleaned from making the move to product management ourselves. Choosing such a path can leverage your understanding of how people use products and give you an opportunity to suffuse that insight through all aspects of a product and experience.

If after reading these articles you’ve decided that product management is not for you, that’s great-there are still plenty of other ways you can take your career, including everything from being a manager to starting your own company, continuing to practice design or beyond.

No matter what you choose, we hope that you have learned something from our experiences. Best of luck!

banda_headphones_sm.gifWant to learn more? Listen to Jeff Parks in conversation with Jeff Lash and Chris Baum in Boxes and Arrows’ FIRST EVER podcast… (but not our last!): Download the MP3

References

[1] seattletimes.nwsource.com/html/businesstechnology/2002033872_codenames13.html

Transitioning from User Experience to Product Management

Written by: Jeff Lash
“Becoming a product manager is a logical move for many UX practitioners, as it requires many of the same skills, traits, and competencies involved in crafting a user experience.”User experience (UX) professionals are increasingly becoming interested in the business aspects of what they do. At their core, the user experience roles focus on understanding user needs and creating useful and easy-to-use products that address those needs.

User experience professionals often get frustrated when their research, designs, and ideas are not given the respect they feel they deserve. There isn’t a UX professional who hasn’t had a bad experience with a stakeholder who, despite their lack of customer interaction or knowledge of needs and workflows, overrules a research-based design on their gut feeling or unfounded opinion.

Increasingly, many UX professionals feel that they have the experience and insight to wield more authority and make a larger impact on the products they help to build. Product management is garnering more interest from interaction designers (IxDs), information architects (IAs), and UX designers looking to increase their influence and ensure user-centered product development.

Becoming a product manager is a logical move for many UX practitioners, as it requires many of the same skills, traits, and competencies involved in crafting a user experience. Additionally, product management is a common role within many organizations, making it easy to transition to a role that already exists. However, IAs and IxDs looking to make this move should examine the trade-offs if they choose this direct path to influence.

What is a product manager?

In the classic sense, a product manager is the president of the product. For the purposes of this discussion, we will define a product as any piece of software, website, web application, intranet, or technical product.

As presidents, product managers hold responsibility for the overall success of the product, including the user experience. For technology products, the user experience is a significant part of the success of the product. Product management (PM), though, also must ensure that all aspects of the product come together, including sale of the product, technology, legal, business model, positioning, branding, and marketing of the product.

To succeed, product managers need to act like leaders, not dictators, with support from cabinet members. Where a president will work with officials responsible for defense, transportation, and agriculture, product managers’ cabinets consist of stakeholders responsible for marketing, technology, finance, and other areas. Rather than by a vote-driven democracy, product managers are held accountable by their users and customers, demonstrated by revenue, profit, usage, and other market-driven metrics.

The variety of tasks and areas involved in product management necessitates that product managers be well versed in the many areas of the business.

Responsibilities of product managers

The base responsibility of product managers is to understand the market and guide the development of a product to serve their market. Because user experience professionals are often already fluent in understanding customer needs and knowledgeable about the markets for which they are designing, they have the potential to make good product managers.

Product managers have several high-level responsibilities:

* Creating a strategy for the product. They focus on the long-term horizon and creating a compelling vision for the product’s future.
* Translating that strategy into a product roadmap. With a clear vision and strategy, they lead efforts with stakeholders to identify how they can execute on that strategy.
* Composing requirements that support both the business strategy and the needs of the market. The roadmap identifies the major areas, which are then detailed out as specific actionable requirements.
* Making sure that the right features get built in the right order and at the right time. They prioritize the features based on customer value and relevance to the market.
* Ensuring proper communication with the market. By sending the right messages to the right people in the right way, product managers ensure that customers are aware of the great product they have spent time working on.

At the same time, product managers are responsible for ensuring that the detailed tactical work supports the higher-level strategic thinking.chart diagram baum-lash Product managers need to constantly monitor and revisit the strategy and adjust as necessary as customer needs, usage, market conditions, technology, and societal trends change.

Additionally, product managers are usually responsible for:

* Internal communication surrounding the product. Michael Shrivathsan describes the product manager as a “communications hub on product-related matters.” (1) This also includes being the internal face of and cheerleader for the product. Especially in organizations with many products, product managers need to generate interest and excitement within the organization about their vision and roadmap.
* External leadership and communication about their product. Many product managers are the primary point of contact for industry analysts and reporters, speak at related conventions and trade shows, operate as the external face of their product, and lead or assist with marketing and sales support efforts. Larger organizations may have dedicated roles or groups devoted to sales support, but even in those companies, product managers will invariably spend part of their time assisting with marketing and supporting the sales staff.
* Portfolio management. Most products don’t exist on their own. For example, iPod works with iTunes, Gmail works with Google Calendar, and the whole suite of Microsoft Office works together. Unless you work for a very small company, you will need to work with other product managers on a combined portfolio strategy.

The differences between product management and user experience

While the responsibilities of product managers are broad and strategic, product managers are also held accountable for tactical activities to create a product that embodies that strategy. At this more granular level, there can be some questions about how PM and UX overlap. As Jonathan Korman writes:

When I describe what I do to people who have not encountered the term “interaction design” before, I say first that “I look at users’ needs, figure out what kind of product best addresses them, and create a behavior specification for that product which the development team then uses as requirements to drive their work.” Often people say, “In my organization, we call that a ‘product manager.’” (2)

At first glance, UX roles and product management can seem amazingly similar. However, when you take a closer look, you see that PM and UX differ pointedly in responsibility, focus, and reliance.

Responsibility: Product managers are responsible for the overall success, while UX practitioners are responsible for ensuring that the interface is designed to meet users’ needs and be easy to use. User experience professionals should still be concerned with the overall success, just as sales, marketing, and engineering should be, but are not held accountable for that success.

Focus: While UX professionals focus on the interface and the user experience, product managers watch the interface and user experience, along with overall market feedback, specific marketing plans, competition, technology, profit and loss, and resources available to the product.

Reliance: Information architects, graphic designers, and usability specialists’ main focus on the interface allows them to rely mostly on themselves or others in the same role to accomplish their work. Product managers rely constantly on other people to do the execution of their product strategy. The role requires a delicate blend of vision and strategy, influence, and firm-but-fair decision-making more so than required for most UX roles.

Jonathan Korman offers perhaps the best distinction between product managers and other roles like UX/IA:
Product managers are responsible for what the product should do; other roles are responsible for how the product does that.

Conflict between product management and user experience

The most common conflict between user experience and product management roles comes into play when discussing what the product should do and how it should do that. There are often arguments about who should be responsible for defining the features and functionalities of the product. Product managers feel as though they should be responsible since they manage the product, but user experience professionals feel as though they should be responsible since they spend time researching user needs and interacting directly with customers and users.

Ultimately, since product managers are responsible for the overall success of the product, they are the final arbiters of what the product should do. A good market-focused product manager understands the market context and customer needs and makes appropriate decisions about features and functionality based on first-hand experience and all available research.

User experience professionals often chafe at this idea, feeling as though since they are closer to the customers and users, they should be responsible for requirements gathering and definition. Good product managers are just as close to their customers as user experience professionals, if not more so. Product managers should not be detached from customers, sitting in the office in meetings while user researchers are conducting research.

Good product managers understand the role and importance of user experience specialists. They value their input and use their research and recommendations to create good products. Just like the president takes advice from cabinet members, product managers should use their cabinet members—user experience, marketing, technology—to inform decisions that they need to make.

Transitioning from user experience into product management is more than just getting to call all the shots on the interface design. Product managers have an important but challenging role, responsible for defining a vision and strategy, internal and external product leadership, creating business cases and obtaining funding, sweating the details while keeping their eye on the big picture, and coordinating the various aspects that go into a successful product—marketing, engineering, finance, sales, and, of course, user experience.

Here we’ve outlined the responsibilities of product managers, the distinctions between product management and user experience, and why there is sometimes conflict between the two roles.

In Part 2 of this series, we’ll cover what you can do to prepare yourself to move into product management, including what you’ll do as a product manager that you won’t do as a user experience professional (and vice versa), how you can prepare yourself for being a product manager, and common pitfalls that product managers, from a user experience background, have made when making the transition.

Read Part 2 now.


Endnotes
Seven Traits of Successful Product Managers, by Michael Shrivathsan

Where do product managers fit?, Jonathan Korman

Read Part 2

banda_headphones_sm.gifWant to learn more? Listen to Jeff Parks in conversation with Jeff Lash and Chris Baum in Boxes and Arrows’ FIRST EVER podcast… (but not our last!): Download the MP3

Making the Web Work: Designing Effective Web Applications

Written by: Jeff Lash
“ ‘Making the Web Work’ is an excellent read for someone making the transition from print design to web design and has the time to read and reflect on the content.”Making the Web Work: Designing Effective Web Applications” is a well-written, meaty book on the entire process of designing interactive websites from a user interface perspective. It should be commended for succinctly describing the entire user-centered design process, but at the same time chided for not focusing more specifically on web applications. A more concerned focus on guidance specific to web applications and a more specific focus on full-fledged web applications would have made this a more distinguishable item on the crowded user-centered design book shelf.

The book itself is structured into five sections. The three middle sections correlate to the three tiers of a visual model that Baxely uses as the framework for discussion of his approach to design. The visual model is similar to Jesse James Garrett’s “Elements of User Experience (PDF)” diagram, though in Baxley’s case, there are three sections—Structure, Behavior, Presentation—each of which are comprised of three subsections, moving from Conceptual Model in the “Structure” tier all the way to Text in the “Presentation” tier.

Baxley’s writing style is simple and straightforward, casual enough to not be boring but direct enough to be authoritative. The structure of the book is clearly apparent, allowing the reader to skim, skip over familiar sections, or quickly refer back to sections if needed.

The first section—Foundations—is an excellent introduction to the fundamentals of interaction design. Anyone looking for a quick introduction to personas would be hard-pressed to find a better reference than Chapter 2, “Putting the User First.”

Section two—Structure—is broken down into Conceptual Model, Structural Model, and Organizational Model (Baxley’s preferred term for information architecture). While the information in the Structure section is certainly worthwhile and presented well, readers expecting to immediately dive in to web application design specifics may be disappointed.

There are plenty of other books that provide this same basic overview of the user-centered design process, and there is not a significant emphasis on how this information relates to web applications versus traditional websites. Baxley defines a web application as “a specific type of web site that implicitly and explicitly stores and manipulates data unique to each of its users. Put more succinctly, a Web application is software on the Web.” As examples of web applications, he mentions online stores, financial services, travel services, information portals, and online services.

The problem with Baxley’s definition is that it is exceedingly broad. True, a good percentage of sites incorporate these sorts of features, but simply having one interactive feature does not a web application make. If a web application is truly as Baxley defines it—any website that does not give the exact same data to user A that it gives to user B—then nearly all websites would be classified as web applications, and the terms “web application” and “website” would be synonymous.

Describing this book as pertaining to “web applications” implies that it discusses applications that allow users to perform tasks like email, stock trading, and photo sharing (which it does), but not websites that are merely “interactive” in one way or another. For example, readers may not expect to find online shopping (e.g., Amazon.com) and portal personalization (e.g., myYahoo) defined as “web applications.” Perhaps some will see this as splitting hairs, but readers expecting information specific to intensive applications may be put off by the attention paid to ecommerce.

The discussion, additionally, could have benefited from more varied examples of web applications, rather than focusing on the aforementioned email, stock trading, photo sharing, and online commerce, since these are but a few of the large variety of web applications that may be developed by readers. An additional perspective could have been gained by discussing web applications that allow system administrators to monitor servers, enable employees to fill in timesheets, let users balance their checking accounts, or permit students to register for classes, just to cite a few examples.

It is not until halfway through the book that the information specific to web applications becomes apparent, and even then, only bits at a time. Chapter 7, “Viewing and Navigation,” focuses mainly on site-wide navigation, but near the end begins to focus on controls for sorting, filtering, and viewing data. Chapter 8 focuses on editing and manipulating data, and chapter 9 rounds out the Behavior tier by focusing on user assistance.

Part four—Presentation—discusses Layout, Style, and Text. Baxley manages to fit a large amount of useful tips and examples into a mere 64 pages, but one would think that a larger part of the book would have been devoted to this tier, since it is here that web applications are most easily distinguished from web non-applications from a visual and interactive standpoint.

The final section includes case studies on Amazon.com and Ofoto. Baxley analyzes these sites according to his three tiers and nine layers, providing useful descriptions and screenshots where necessary. The index, often thrown in to books at the end as a metaphorical afterthought, in this case is extremely well designed and readable. Kudos to indexer Cheryl Lemmens for closing the book on such a positive note.

While accurate overall, there are some minor inconsistencies that stand out. For example, he describes the merits and drawback of using the <ALT> tag for contextual help when he is really talking about the “title” attribute (p. 292), and uses Wine.com as an example while discussing the merits of a hierarchical organizational system when it is actually facet-based (p. 186). These mistakes are neither common nor severe, but they are fairly noticeable in a book that otherwise should be commended for its fastidiousness.

From cover to cover, “Making the Web Work” weighs in at just over a hefty 470 pages. Though about half of each page is devoted to text, with the extra space used for notes and labels, it is still a lengthy read. It is an excellent resource for someone making the transition from print design to web design and who has the time to read and reflect on the content. Those looking for a shorter way to absorb the information would be well-served by only reading the concise and helpful summaries at the end of each chapter.

Those new to the field of user-centered design will find “Making the Web Work: Designing Effective Web Applications” most useful; intermediate or advanced practitioners looking for in-depth information specific to web applications may want to look elsewhere.

Read a sample chapter (Chapter8 – 1.6mb PDF)

  • Making the Web Work: Designing Effective Web Applications
  • Bob Baxley
  • New Riders, 2002
  • ISBN 0735711968
  • 474 pages
  • List price: $45.00
  • Target audience: Practicing designers, product marketers, software engineers
  • Chapters:
      Part I: Foundations

    1. Common Ground: Defining Web Applications and establishing the Goals of Design
    2. Putting the User First: Describing Target Users and Product Goals
    3. Deconstructing the Problem: Prioritizing and Categorizing Different Aspects of an Interface
    4. Part II: Tier 1, Structure

    5. The Conceptual Model: Selecting a Fundamental Motif
    6. The Structural Model: Understanding the Building Blocks of a Web Interface
    7. The Organizational Model: Organizing and Structuring Content and Functionality
    8. Part III: Tier 2, Behavior

    9. Viewing and Navigation: Creating Consistent Sorting, Filtering, and Navigation Behaviors
    10. Editing and Manipulation: Using HTML Input Controls to Accurately Capture Users’ Data
    11. User Assistance: Communicating with Users Through Help, Status, and Alerts
    12. Part IV: Tier 3, Presentation

    13. Layout: Positioning Elements to Maximize Understanding and Readability
    14. Style: Defining Visual Appearance
    15. Text and Labels: Writing for the Web and Calling Things by Their Right Names
    16. Part V: Case Studies

    17. Amazon.com: Browsing the Aisles of the Web’s Supreme Retailer
    18. Ofoto: Looking at the Leading Online Photo Processor


Jeff Lash is a Usability Specialist and Information Architect at MasterCard International and writes the IAnything Goes column for Digital Web Magazine. He is also on the Leadership Council for the Asilomar Institute for Information Architecture and is co-founder of the St. Louis Group for Information Architecture. His personal web site jefflash.com proudly has no IA-related information.

The Elements of User Experience

Written by: Jeff Lash
“The most admirable element (pun intended) of the book is its ability to blend the idea of being an advocate for the user with the idea of being an advocate for the business.”With his first book, Jesse James Garrett, an occasional Boxes and Arrows contributor, has taken a deceptively simple diagram and expanded it into a thorough primer on the fundamentals of online user experience design. His rational and straightforward approach is miles away from the often-criticized dogmatic rhetoric frequently found in the areas of usability, design, and business.

The Elements of User Experience” is based on the one-page diagram (PDF) of the same name. Posted for free downloading in early 2000, the diagram quickly became one of the most important tools and popular pieces of cubicle decoration for web designers, developers, and anyone even remotely involved in crafting the user experience. It made clear the separations and connections between the different factors involved, offering enough of an explanation and synthesis of ideas to aid in understanding, but at the same time leaving out much that could not fit on a single page.

Compared to the full book, the original “Elements” document is like a Cliffs Notes version (and a highly abridged one at that). The one-page diagram is certainly useful, and may be all that is needed for some people, but to truly learn and comprehend, more is needed.

Conveniently, the book is arranged in a similar manner to the diagram. After an introduction to user experience and an overview of the elements, a chapter is devoted to each of the five “planes” — Strategy, Scope, Structure, Skeleton, and Surface — in the diagram, with a final chapter devoted to applying the elements in the real world.

Garrett’s writing style is clean and straightforward, providing enough detail to explain concepts to beginners while not boring more advanced practitioners. As one would expect of an author who is also an information architect, the book is very structured with well-defined sections. But the rigid framework still allows the sections to flow without abrupt changes in topic or lines of reasoning. It is as comfortable to read from cover to cover as it is to dive right in and read just one chapter or element.

The most admirable element (pun intended) of the book is its ability to blend the idea of being an advocate for the user with the idea of being an advocate for the business. Too often, user experience is given a bad rap because of its lack of business sense, and many who draw criticism do so incorrectly and unfairly by using the “user experience” label when they really are speaking only of “usability” or “visual design.”

Garrett has laid out a framework for consideration of the entire process of designing the user experience, including business, technical, usability, and design concerns. Paragraphs dealing with interaction design are peppered with comments about technical feasibility, and sections on user needs include discussions on brand image. By giving as much attention to a site’s objectives and functional specifications as to its interface design and user needs, Garrett has succeeded in creating a single book that can enlighten “suits” about user experience issues while at the same time teaching designers, information architects, and usability specialists about the necessity of understanding the business aspects involved.

Those who are looking for a short and easy yet informative resource about user experience design will be delighted. However, those looking for more advanced information or more in-depth focus may be disappointed. This is to be expected; it is simply not possible to cover the entire realm of user experience in detail while at the same time keeping the book to a svelte 208 pages. This point is conceded by the author, as additional resources are suggested at the conclusion of each chapter. He admirably restrains himself on subjects that could be discussed more thoroughly, providing enough information for most readers, while planting the seeds and providing the water for those who wish to learn more.

There is probably no better book on the market that so clearly and rationally covers the entire area of user experience. This book is a perfect introduction for someone who is coming from the design, technical, or business side and is just getting into the field of user experience design, or someone with experience in one of the elements who feels the need to study up on the others. Advanced practitioners may find that Garrett’s book serves well as a reference or “backup” in project meetings or those inevitable design “discussions,” but it is unlikely they will uncover much new material. On the book’s companion website, Garrett states that the book is intended to be “an ideal introduction to the field for students or entry-level practitioners,” but he also “hope[s] that the book will provide experienced practitioners with some new ways of thinking about the work they’ve been doing.” On both points, he has succeeded with flying colors.

Read an excerpt (PDF) from “The Elements of User Experience”.

  • The Elements of User Experience
  • Jesse James Garrett
  • New Riders, 2002
  • ISBN 0735712026 § 208 pages
  • List price: $29.99
  • Target audience: “Hopefully, just about anyone.”
  • Chapters:
    1. User Experience and Why It Matters
    2. Meet the Elements
    3. The Strategy Plane: Site Objectives and User Needs
    4. The Scope Plane: Functional Specifications and Content Requirements
    5. The Structure Plane: Interaction Design and Information Architecture
    6. The Skeleton Plane: Interface Design, Navigation Design, and Information Design
    7. The Surface Plane: Visual Design
    8. The Elements Applied

Jeff Lash is a Usability Specialist and Information Architect at MasterCard International, and writes the IAnything Goes column for Digital Web Magazine. He is also the co-founder of the St. Louis Group for Information Architecture. His personal website is jefflash.com.

“Why We Buy: The Science of Shopping”

Written by: Jeff Lash

“Experience design,” as it’s often used in the online world, refers to everything a customer comes in contact with when having experience with a brand—what the colors are, what emotions the design conveys, how the text is written, ease of interaction with the web site, how the content is structured, and much more. Information architects and designers sometimes forget that there is an offline experience as well; Paco Underhill’s “Why We Buy: The Science of Shopping” explores customer experience and consumer behavior as they affect retail and offline environments.

Much has changed about ecommerce since this book was first published, but many of its predictions about online retailing have come to fruition.Overall, the book is a lively read, chock full of interesting stories, research data, and case studies. There are sections dealing with product usability, environmental graphics and navigation, demographic issues, location, marketing and promotion. Obviously a seasoned professional, Underhill presents business issues in a straightforward manner, backing up his claims and suggestions with anecdotal and statistical evidence.

Though the majority of the book focuses on “traditional” retailing, Chapter 17 specifically talks about online retailing. Much has changed about ecommerce since this book was first published (May 1999), but many of Underhill’s predictions about online retailing have come to fruition, and his bottom-line insistence on “you need a reason to start a web site” rings true in today’s economic environment.

One neglected aspect of ecommerce he mentions on the first page of the chapter has already been addressed by many retailers: “Few web sites will permit you to see if a particular item is in stock in a store near you, order it, pay for it and then go in person to retrieve it.” It would be interesting to hear the author’s feelings on the current state of online retailing three years after this was written and see what advances he feels have been made and what problems still need to be addressed.

Another brilliant aspect of this book is its universal appeal. While those interested in usability and ecommerce have snapped it up, it is not limited to those limited audiences. (In fact, those who lament “I can’t explain to my Mom what I do all day” might benefit from suggesting a read of “Why We Buy” and then adding, “It’s like that but with web sites.”)

If there’s any downfall of the book, it would be the sometimes-meandering text. The reader may expect a more of a textbook-like approach to physical experience design, but Underhill’s writing style mixes case studies with anecdotes, business, psychology, and opinions.

Though divided up into four sections and 19 chapters that purport to focus on specific topics, the end results often diverge from their intended subject. This is not necessarily a bad thing; it feels as though Underhill is leading the reader on a walking tour of a business, pointing out issues during the journey and recalling anecdotes whenever appropriate. However, those looking for a tome on the design of physical commerce spaces need look elsewhere.

There are dozens of lessons in “Why We Buy” that can be learned by those involved in web development, whether in ecommerce or brochureware. One is that, even after decades of running tests, Underhill and his staff are still learning new things and uncovering problems they’ve never noticed before, showing that continual learning is essential.

The author also talks about the importance of evaluating elements in the environment in which the customer will interact with them. (“Showing me a sign in a conference room, while ideal from the graphic designer’s point of view, is the absolute worst way to see if it’s any good. To say whether a sign or any in-store media works or not, there’s only one way to assess it—in place.”)

He devotes a good deal of printed space to the differences in the shopping habits of men and women, as well as the growing aging population and children, which suggests that these demographically-influenced habits (and others) could carry over to the online world.

However, two main messages permeate throughout, and they should be familiar, since those involved in designing the user experience online have been focused on them all along.

First, understand your customer and make things easy for them. Don’t make them feel uncomfortable, don’t confuse them, don’t make them do more work than they should. Structure things so that they make sense to your customer, for their actions will determine whether or not what you have done is successful.

Secondly, understand the business goals and design your changes to work towards those goals. Aesthetics, navigation, and structure are of no use if they don’t support the business objectives. And, of course, designing with your shopper/user in mind will help you reach these goals.

About the book:

  • “Why We Buy: The Science of Shopping”
  • Paco Underhill
  • Simon & Schuster, 1999
  • ISBN 0-684-84913-5
  • 225 pages
  • Hardcover retail price, $25.00; Paperback retail price, $15.00
  • Target audience: Anyone interested in retail or ecommerce
  • Sections:
     I–Instead of Samoa, Stores: The Science of Shopping
     II–Walk Like an Egyptian: The Mechanics of Shopping
     III–Men are from Sears Hardware, Women are from Bloomingale’s: The Demographics of Shopping
     IV–See Me, Feel Me, Touch Me, Buy Me: The Dynamics of Shopping
Jeff Lash is working on improving the intranet user experience at Premcor. He was previously an Information Architect at Xplane and is the co-founder of the St. Louis Group for Information Architecture.