Supporting User Experience Throughout the Product Development Process

By Peter Hornsby

Published: July 19, 2010

“Frequently, problems arise when capturing requirements. Some product people feel more comfortable describing requirements in terms of the user experience.”

For most of us, the ideal when working on a product-development project would be to work with a group of like-minded professionals, each with their own areas of responsibility, but sharing the same overarching goal. Yet all too often in User Experience, we encounter unwarranted resistance to our ideas, making the product-development process much less efficient and adding to a project’s costs. The apparent cost of involving User Experience early and throughout a product-development process becomes a series of hidden costs, resulting from project delays, incomplete requirements, and less than optimal products that result in higher error rates and reduced efficiency for users.

Frequently, problems arise when capturing requirements. Some product people feel more comfortable describing requirements in terms of the user experience. This can range from the very general—“The user needs to upload a file.”—to the very specific—“The user needs to click a check box to accept.” When Product Managers define requirements in this way, then pass them on to UX designers, those designers confront an immediate challenge—they must contradict the requirements as defined and must also assume an additional workload to overcome the deficiencies of the requirements as stated. Yet this also presents an opportunity: When UX designers sketch a user interface and shares their sketches with their product team, they help people to visualize the existing requirements and identify opportunities for improvement. The reason requirements frequently contain UX elements is that people think of products in terms of their user experience.

“Let’s look at how we might design a tool that could help us in overcoming these types of obstacles by supporting user-centered design….”

This month, let’s look at how we might design a tool that could help us in overcoming these types of obstacles by supporting user-centered design (UCD)—a tool that’s not just for UX professionals, but supports multiple project stakeholders in various roles throughout the entire product lifecycle. This UCD tool would support stakeholders by making requirements more clearly visible and enabling team members to work effectively across far-flung geographical boundaries. In describing this tool, I’ll draw on a number of currently available UX design tools for inspiration, including the following:

  • Axure RP—Axure supports UX designers in creating and specifying wireframes—and, if appropriate, creating interactive prototypes from wireframes.
  • TechSmith Morae—Morae supports usability testing, providing a wealth of data that user researchers and other UX professionals can use to understand and improve a design.

Rather than look at a specific product development process, we’ll consider some important stages of this process in isolation. This is not to suggest that our proposed tool would only support a waterfall process; it is just to simplify the description of the tool.

Capturing Requirements

“Any good product development process must begin with a clear, unambiguous set of requirements that a product team defines considering the context of the product’s target users.”

Any good product development process must begin with a clear, unambiguous set of requirements that a product team defines considering the context of the product’s target users. Thus, a UCD tool that enables the product development process must first capture requirements—supporting multiple, concurrent users—and allow a team to structure requirements according to the needs of the project.

Ideally, each requirement should be discreet, and the team should identify and prioritize requirements that are either directly or indirectly part of the user experience and relate them to the target user groups. As early as possible, a UX designer should begin to develop wireframes and share them with project stakeholders to gather feedback. By linking requirements—which don’t contain any UX details—with wireframes, you can meet your team’s implicit need to express requirements in visual terms and increase people’s comprehension of them.

Stakeholders should have a clear line of sight from requirements to their corresponding wireframes and be able to annotate the wireframes with their feedback. It must be possible for people to identify and capture additional opportunities and requirements, then use these as part of an iterative design improvement process. A major challenge here is managing and prioritizing the flow of feedback. However, the benefit is giving stakeholders a much greater sense of ownership and involvement in the design process.

The system should support a two?way relationship between requirements and wireframes. For example, if a requirement got deleted and a wireframe element was wholly based on that requirement, the tool should call attention to the relationship between them to the team, facilitating their removing that element. Similarly, if a wireframe element were deleted, it must be clear from glancing at the requirements that the wireframe is no longer complete.

Prototyping and Usability Testing

“The holy grail for systems of this type would be to support the easy creation of prototypes by nondevelopers, while also enabling an easy transition to a live system.”

Following the UX designer’s initial production of wireframes, the next step is to incorporate some limited functionality in them to support usability testing. The holy grail for systems of this type would be to support the easy creation of prototypes by nondevelopers, while also enabling an easy transition to a live system. This stage of the process is more akin to a conventional programming task, so our UCD tool should support it in the same way a development tool would—for instance, by promoting the creation and reuse of component parts, including their associated documentation.

Ideally, in the long term, our UCD tool could generate a live system from a prototype. However, given the current state of automated code generation and additional requirements like cross-browser compatibility, this is not likely to happen for some years. For now, our UCD tool should generate prototypes in a form that would support both remote and local usability testing, providing data in a format we could use with various data analysis packages—or even support data analysis itself.

UX professionals broadly regard the development of UX design patterns as a positive step. However, where we sometimes miss opportunities is in the collection of objective data that enables us to relate different patterns to specific problems, design contexts, and user groups, so we can understand which pattern is best for a given situation. When there are multiple, competing design patterns for solving a particular design problem, being able to capture and relate data about our implementations of the patterns and user response to them during usability testing could be critical in making the right design decisions. Yet, because of the difficulties of collecting, analyzing, and storing that information in a reusable form, such decisions may be made based on subjective criteria. This is not inherently bad, but it does not move us closer to a deep understanding of how to apply design patterns.

Post-Implementation Testing

“Post?implementation testing must ensure that the delivered product meets these UX-specific requirements, as well as the business requirements.”

Once a UX designer has devised a design solution, the wireframes capture details that do not typically form part of the business requirements—such as field sizes, interactions, colors and so on. Post?implementation testing must ensure that the delivered product meets these UX-specific requirements, as well as the business requirements. In its current form, Axure RP is a very useful tool for quality assurance testers. In addition to generating a printable report containing the specification details, testers can evaluate the wireframes against the implemented system. Integrating an automated testing tool into our proposed tool would allow it to handle many details of testing, freeing testers to focus on other important matters.

Product Lifecycle Support

“Following implementation, the design artifacts a UX designer has created during the product development process should be made available as a resource to support further development or training of users.”

Following implementation, the design artifacts a UX designer has created during the product development process should be made available as a resource to support further development or training of users. Because our proposed UCD tool provides a clear line of sight from requirements to our product development team’s implementations of those requirements and from prototypes to usability test results, it is much easier to understand the design rationale behind a design solution and, if necessary, develop it further. For busy teams, communicating design solutions in such a readily accessible form could support rapid shifts in workloads that would not otherwise be possible.

Summary

“A tool that put user-centered design at the core of the product development process and related requirements and usability test results in such a visible way to design artifacts would increase a team’s awareness of the rationale behind design solutions.”

Why create such a UCD tool? We are hugely influenced by the design of the tools we use. They shape our thinking and the ways in which we relate to other team members throughout the product development process. A tool that put user-centered design at the core of the product development process and related requirements and usability test results in such a visible way to design artifacts would increase a team’s awareness of the rationale behind design solutions. It would provide team members with greater opportunities for input into both requirements and UX design.

Our UCD tool would let your product team capture an audit trail that would help team members to understand how and why decisions were made, make the relationships between requirements and their implementations explicit, and support reuse. While the UCD tool I’ve described does not yet exist, it draws on existing, readily available tools for inspiration. I have not proposed anything that is not technically possible. I’d like to hear about what you would like to see in an idealized UCD design tool. Please drop me an email or submit comments below!

Join the Discussion

Asterisks (*) indicate required information.