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.
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.