Using the tools of design discovery can help your company capture user needs and build better products.

Bill Welch, Triple Ring Technologies

All product development teams have one thing in common: the desire to just get started. Especially when coupled with pressure from investors and management, it’s very tempting to shortcut design inputs and let the development teams start on something.

It’s not hard to imagine how this leads to problems later. Typically, when teams are rushed, issues that could have been identified early are discovered later in the process, when design and engineering changes are extraordinarily costly.

One of the most important starting exercises for any development effort is to identify and create a list of user needs. These documents provide important insights into product requirements and help to identify potential problems early on.

It’s a good idea to start with marketing requirements and these key documents:

• List of actors and roles.
• Workflow analysis.
• Journey map.

Together, these documents provide a clear framework for analysis and a roadmap that enforces discipline in the process. If done correctly, the benefits include:

• Making sure user needs are properly represented in product requirements.
• Identifying gaps in the marketing requirements document.
• Providing a foundation for user experience (UX) designers.

Imagine you have been asked to develop a handheld diagnostic device that will be used by surgeons in the operating room. The company’s engineering team will probably already have made assumptions about how the product will be used. The company may have also hired a design firm to create product renderings. Jumping the gun on both of these activities tends to integrate early assumptions and may lead a team off course.

Before development begins, it is important to take a step back and reevaluate all of these assumptions. User needs should come from the user — through site visits, focus groups, voice-of-customer surveys, customer interviews, user studies and recorded observations.

Market requirements

The market requirements document (MRD) will have different names in various organizations, but the core principles are the same: why does the product exist, and what features and cost targets are needed so it can be successful. A product manager or someone in a business role usually writes the MRD, which can range from one to 50 or more pages. It should include:

• Key product features.
• Target sales price.
• Approximate sales volume per year and product lifetime.
• Sales method.
• Target customers.

The MRD should focus on high-level features that might be seen in a brochure. Avoid constraining the team with how the features will be implemented, and leave out specifications. The developers will figure out how a feature will be implemented, or how a cost target will be met.

Actors and roles

Next, focus on the users by creating the list of “actors” (users) and “roles” (how they use the product).

This is a comprehensive list of every person who will ever be in contact with the product. The more comprehensive, the better. Because our fictitious handheld device is used in the OR, it will have a long list of actors. Include the surgeon, patient and the full OR staff. If needed, add a salesperson for the demo mode. Also consider the assemblers in the factory, service and repair staff, the hospital’s biomedical engineer and central processing staff, etc. Next to each one, include a brief description of their role.

Workflow Analysis

Diagramming workflow is a crucial step and can take the form of a flowchart or a narrative text document. Describe every step of each user’s interaction with the product.

For example, during a recent workflow exercise, our team was focusing on the surgeon’s workflow within the sterile field. The original design of the device we were provided included a button that the surgeon or nurse could press to interact with the device during surgery. We determined through workflow analysis that it was possible to eliminate the button and replace it with an IMU (Inertial Measurement Unit) or motion detector. This insight resulted in several significant benefits: reducing product cost and complexity, potentially reducing user errors, eliminating an ingress point, and improving the user experience.

The act of writing down the steps in a workflow analysis will produce insights and discoveries that can improve the product and identify potential issues early.

Journey map

The journey map documents the physical movement of the device and its accessories through the usage environments. Typically, a journey map is a single-page diagram with a line that connects locations where interactions happen with a device. If the product is a one-time-use device, the journey map is likely to be a straight line, beginning on the left with the initial interaction point, flowing through to the right, where the product is moved to the point of use and ultimately disposed of.

In the case of our fictitious handheld device used in the OR, assuming the device is durable and designed for repeated uses, the journey map will include a loop in which the product will flow from central storage to the OR, to processing where it’s cleaned, then back to central storage. If a durable device also requires an accompanying sterile disposable component, the journey map will be a combination of a straight line (disposable) and a loop (durable), meeting in the OR.

Just as with the workflow analysis, the journey map will uncover new insights that will lead to a solid list of product requirements. For example, if a durable device needs to be cleaned and sterilized in central processing, the method and chemicals used in cleaning will need to be considered. This often affects the mechanical construction of a product housing, including parting-line location as well as determining which ingress protection (IP) rating is needed.

Key take-aways

It’s very common for companies to want to skip these “soft” processes and just get to work on making a new device. Even for teams within large companies, there is pressure to go fast and show results. What’s equally common is development teams becoming victims of feature creep, or to getting stuck along the way because they try to fill in the blanks after getting started, especially in the validation stage.

It’s going to save money in the long run to invest the time upfront to fully understand and properly capture what your users really need. Connect the dots between user needs and requirements as early as possible.

Bill Welch is director of product design for Triple Ring Technologies.

The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of Medical Design and Outsourcing or its employees.