Product Map

Quite often, how a product behaves is not clearly documented. Even more so, different members of the product team may have different perceptions on how the product behaves. Mapping the product’s behavior has the potential to save time and effort for support groups like Customer Support, Documentation, and Training.

What is it?
A Product Map documents the product’s User Workflow and UI behavior.

The User Workflow defines all the tasks that a user wants to accomplish with the product and the procedure to accomplish them. The UI behavior details the product’s reaction to any given input (usually user input).

The Product Map defines a starting point and lists all the different options available. Think of this as analogous to a web site where you start at the home page and define all the links.

If you read our UI Design page, you’ll notice that the same information is documented when designing the UI. The difference here is that we are mapping out an existing product.

What are the major problems by not having the map/workflow?
Not having this information clearly defined is costly and affects the following groups:

Documentation: Technical writers spend much of their time researching how the product works then understanding how the users are expected to use the product to accomplish tasks. The time spent gathering this information leaves little or no time to document additional useful information to customers.

Quality Assurance: A good test plan requires a thorough understanding of all expected product behavior. Any expected behavior that is not made known to the test writer does not get tested, leaving bugs to be found by customers.

Training: Like the technical writers, the course developers need to understand how the product can be used to accomplish the customers' tasks. The more time spent on discovering this information means less time spent on an overall training strategy and delivery.

Remote Engineering: In cases where engineering is done in a remote location, the product specification is critical. Especially where there are cultural and language differences, it is very easy for different developers to have a slightly different understanding of how the product actually works. This can reflect in how they code a particular function, creating barriers to success.

Customer Support, Marketing, and Sales: Between departments, it is easy for misinformation to occur. With different people gathering information from different sources and filling information gaps as they occur, final product information can lack critical details, can conflict among different sources, and can even be erroneous. In more severe cases, a lack of consensus concerning the product behavior can cause misunderstandings among product management, sales, marketing, and engineering. Eventually, misconceptions can find their way to the customer, causing customer dissatisfaction and additional customer support calls.

What a Product Map Gives You
A well-defined Product Map gives your organization the following benefits:

• Documentation and Training get the user tasks and product behavior they need, saving time and reducing potential technical errors. The writers and course developers can spend more time on other documentation issues, without having to add personnel to the team.
• Test plans can be more comprehensive.
• Misunderstandings are reduced. I have noted that there is often an additional benefit. Product problems are often uncovered when mapping the product. For example, the product does not provide useful or any error messages when a user gives incorrect input on a specific task. Another example is that the product does not provide appropriate feedback in response to a user action, which ultimately causes a product failure. These problems can be uncovered and addressed before the next release of the product.

I have noted that there is often an additional benefit. Product problems are often uncovered when mapping the product. For example, the product does not provide useful or any error messages when a user gives incorrect input on a specific task. Another example is that the product does not provide appropriate feedback in response to a user action, which ultimately causes a product failure. These problems can be uncovered and addressed before the next release of the product.

What is the Deliverable?
The deliverable is a document or documents containing the Product Map and User Workflow. The format and presentation of this deliverable is negotiable. A secondary deliverable can be the training of one or more individuals to update this information with every product release.

User Experience Design
Information Design
Single Sourcing
Back to Deliverable Management

Back to Top