Embedding User Experience in the Product Development Lifecycle

By Mike Hughes

Published: January 18, 2010

All UX professionals, not just user assistance developers, face the problem of integrating their work into the product development lifecycle.”

All UX professionals, not just user assistance developers, face the problem of integrating their work into the product development lifecycle. At lower levels of organizational usability maturity, too often, the contributions of User Experience tend to be reactive. Usability professionals test the usability of a given product, then designers mitigate any shortcomings they find, and user assistance developers merely document what is already there. This column takes a look at the full scope of the product development lifecycle and how UX professionals can add value.

Figure 1 shows a simple view of the product development lifecycle. You could certainly define more fine-grained phases, but the four phases I’ve shown capture most activities to which UX professionals can add value:

  • requirements definition
  • design and validation
  • development and testing
  • deployment and support

Figure 1—The product development lifecycle

Product development lifecycle

Let’s look at each of these phases and discuss how to integrate UX design activities and artifacts into them.

Defining Product Requirements

“Although requirements definition occurs at the start of most product development processes, it is often the last phase UX professionals successfully infiltrate.”

Although requirements definition occurs at the start of most product development processes, it is often the last phase UX professionals successfully infiltrate. Indeed, if you are helping define requirements, you are at Jakob Nielsen’s Stage 7 on his eight-stage usability maturity model. Yet this phase is key to user-centered design, and it is where UX professionals can often add the greatest value.

There are four significant influencers of requirements, as shown in Figure 2:

  • market opportunities
  • technology opportunities
  • compliance
  • user needs

Figure 2—Requirements influencers

Requirements influencers

Market opportunities are features and functionality customers have indicated they would be willing to pay for. They do not necessarily reflect user input. In fact, such requirements frequently do not come from actual users, but instead, from meetings with their managers. Therefore, they tend to focus on high-level business needs. They describe what a product needs to accomplish, not how it does it. As a consequence, there is not as great a role for UX professionals to play as market opportunities influencers as there is for them as user needs influencers, which I’ll discuss shortly.

“There is not as great a role for UX professionals to play as market opportunities influencers as there is for them as user needs influencers.

Technology opportunities influence the features and functionality that result from newly acquired technical capabilities. They aren’t usually things customers or users are asking for, because they can’t even conceive of them. As Henry Ford said, if he had asked his customers what they wanted, they would have said, “a faster horse.” UX professionals can have a positive impact on defining such requirements by staying abreast of technology advances that can enhance the user experience. For example, technologies such as faceted metadata have improved the search experience, and advances such as Ajax (asynchronous JavaScript and XML) have made richer user interactions possible on the Web.

Compliance with Section 508 accessibility requirements or other types of external forces, as well as internal forces such as corporate standards or a need for globalization also drive requirements definition. UX personnel can add value here, because of their specialized knowledge about accessibility and their familiarity with corporate guidelines and design patterns.

“By far, eliciting user needs is where UX professionals can offer the most value during the requirements definition phase.”

User needs influence features and functions that support the ways users would want to apply a product within their own contexts. By user, I mean someone who actually uses a product in his normal routine rather than a manager or other stakeholder who makes the decision to buy the product, but does not actually use it. By far, eliciting user needs is where UX professionals can offer the most value during the requirements definition phase. There are several ways in which UX professionals can determine user needs, including the following:

  • focus groups that let a company hear what users want in their own words
  • contextual inquiries that study how users accomplish tasks within their real work environments and actual workflows
  • usability testing of a company’s own products or competitive products to understand the opportunities for enhancing the user experience
  • inspection of a company’s own products or competitive products to uncover weaknesses that detract from the user experience
  • product support records that point to aspects of a company’s current products that are difficult to use
  • user experience literature that describes best practices and research-based principles of user-centered design

Designing and Validating Products

“The design and validation phase is where UX professionals do much of the heavy lifting of creating usable products.”

The design and validation phase is where UX professionals do much of the heavy lifting of creating usable products. During this phase, they produce design artifacts that inform the work of other designers and developers:

  • User profiles describe different types of users and their attributes, which a design needs to accommodate.
  • Personas describe users in personal ways, so a product team can visualize the users as they create a product for them.
  • Scenarios describe the user experience around specific tasks and goals.
  • Use cases describe how a system and its users interact, often exploring failure conditions and alternative paths to achieving goals.
  • Wireframes show how to construct a user interface.
  • Specifications define the user interactions and behaviors for a product.
  • Prototypes can add interactivity and functionality to wireframes or specifications. They enable the validation of a design by users through usability testing.
  • Usability testing gives early feedback about a prototype’s performance and acceptance.

Development and Testing

“When an organization’s level of usability maturity is low, the development and testing phase is where most UX and user assistance professionals first become actively involved in the product development process.”

When an organization’s level of usability maturity is low, the development and testing phase is where most UX and user assistance professionals first become actively involved in the product development process. Usability experts inspect and test the usability of a product’s design, and user assistance developers document tasks and procedures. Although these are useful activities, they are reactive, so their impact is limited by the reality that developers are already committed to key design decisions. Any UX team that gets shut out of the requirements definition phase and, more important, the design and validation phase experiences a lot of frustration. They can see the potential for creating a much better user experience, but have been limited to damage control and lipstick-on-a-pig interventions.

Deployment and Support

Like the front end of the product development process, the tail end does not get as much attention as it deserves from User Experience. By the time, a company has deployed a product, the focus of most UX teams has moved on to other projects. But this phase provides the best opportunity to see a product at work in its natural environment and start making plans for truly user-centered improvements and enhancements. User researchers can conduct rich contextual inquiries to see how users really use a product for their own purposes, independent of preconceptions and the constraints usability testing often imposes. Customer support records can also be a rich source of information that points to potential areas for improvement in a user interface, as well as the features that would benefit from user assistance content in future releases.

Conclusion

“Look at your current process and identify where UX professionals could make a positive difference—then insert yourself there!”

UX professionals should educate their product development teams about where best to employ user experience activities and artifacts. In this column, I’ve defined a simple product development lifecycle model and given concrete examples of the kinds of impacts UX professionals can make during each phase. Every development organization is unique, and yours might have opportunities I have not described here. The important thing is to look at your current process and identify where UX professionals could make a positive difference—then insert yourself there!

2 Comments

After running company-wide persona/UCD awareness courses, we had an internal vote: Should we adopt personas? The answer was overwhelmingly: Yes! We are now adopting Persona Driven Design and also undertaking contextual inquiries to understand our customers and feed data into product definition and vision. Maybe I was lucky to work for an agile and open-minded organization; but for me, the move to embrace UX has been enthusiastic—and it’s great fun, too!!!!

Re: Deployment and Support Phase mentioned in the article:

I couldn’t agree more. This aspect of the project lifecycle is generally ignored outside of reporting analytics results from time to time where I currently work.

It’s a golden opportunity to look at how actual users and customers interact with your product and what the company experiences as part of its deployment. There’s too much of a get-the-next-thing-done mentality.

This phase presents an opportunity for open dialogue with your client on what worked, what didn’t work, and what you can plan together for improved results.

Join the Discussion

Asterisks (*) indicate required information.