Discovery & Design Process

Discovery Prep

Product Design prepares for Discovery by reviewing any business requirements, use cases, or pain points provided by the client. From there, we document any assumptions and open questions we have stemming from the client-provided information.

Joint Discovery Sessions

During the joint discovery sessions with the client, Product Design will facilitate discussion and lead group exercises to produce four main artifacts. It is important that Product Design acts as a facilitator and does not provide responses on behalf of the client so that we are not influencing the discovery with our own assumptions or biases. As with many exercises, the discussion and information that is revealed during the exercise are more important than the artifacts that are produced.

At the top of the discovery, Product Design will review the client-provided information and confirm and discuss any assumptions. We will also obtain answers for any open questions. During the call, we may document other assumptions and questions and answers as they come up.

  • After reviewing the requirements, assumptions, and answering any questions, Product Design leads the client in converting the information into problem statements. This helps prevent the client from dictating solutions and designs, and instead aligns us on: What problems are we trying to solve?

    This can help remove preconceived ideas on a solution; in the past we’ve seen requirement documents describing button text, dropdowns, etc. We want to move away from solutioning and focus on problems. Remembering Henry Ford’s (the inventor of the automobile) famous quote: “If I asked them what they wanted, they would have said ‘faster horses'.” In order to provide the most innovate designs, we cannot get stuck on what the client wants, but instead need to uncover what they actually need.

  • The Journey Map and Workflow exercises can be done in either order. The Journey Map exercise can also be scaled depending on the group and the scale of the project.

    Our modified Journey Map exercise seeks to define: Who are the stakeholders, and what do they need?

    Our journey map exercise starts with the client identifying any parties (users or stakeholders) that need to interface with or will need information from this feature. For each user group, the client identifies goals, needs, and outcomes for this feature. The second section of the journey map documents the activities for each user group.

    The final four sections are the prioritization of the user steps. These use the MoSCoW prioritization method (Must have, Should have, Could have, and Won’t have). At this point in the discovery, we are discussing the prioritization of the user steps within the product, not the prioritization within the use case or current processes.

  • The Workflow Diagram and Journey Map exercise can be done in either order. Sometimes, if the client is struggling with the journey map, it can make more sense to do the Workflow Diagramming first.

    The workflow diagram exercise documents the current processes and stakeholders in order to identify: What processes are we trying to support?

  • The culmination of Discovery results in the client defining user stories, using the standard format of “As a [actor], I want to [action], so that I can [goal]”. These stories create definition around: What use cases do we need to include?

    It is important to get these business user stories written in the clients' own words. It’s also helpful to get various stakeholders to contribute and voice their needs.

    Once the user stories are documented, we sometimes need to organize and occasionally discuss and cut scope. Sometimes a client will suggest a story that is not within scope of the original requirements or problem statements. In these cases it is important to discuss and get group buy-in that the story is not within the scope of this feature. We strikethrough the story in order to document this decision. Another possible outcome is that we prioritize the user stories using MoSCoW (Must have, Should have, Could have, or Won’t have).

Solutions Design

After the joint discovery session, Product Design synthesizes the discovery discussions and outputs to evaluate the use cases and needs. This is compared to current functionality in the product, and then solutions are designed to close these gaps. Product Design will also consult with development and architecture SMEs to ensure that designs are feasible within the current constraints of the product and teams.

  • Product Design starts with some low-fidelity wireframes. This is both to present to the client, in addition to being a reference once this gap moves into development. A key point in creating these wireframes is limiting what is shown to the client to only the information relevant to the design. This keeps the evaluation and discussion in scope.

    The wireframes help answer What could the feature look like? And should include field and configuration options.

  • Building off of the low-fidelity wireframes, Product Design builds prototypes to walkthrough during Design Review with the client. As with the wireframes, these prototypes focus on the areas of the feature only, and do not overwhelm the client with other fields or information that may exist in the UI. These prototypes show the step-by-step behavior for feature and should cover the various user groups and use cases identified in Discovery. Typically there is one prototype per use case.

    The prototypes should answer How does the feature behave and what use cases does it support?

Design Review

Once the prototypes and wireframes have been developed, the solutions are presented to the client for review. After a quick recap of the Discovery process and artifacts, Product Design will walk through the wireframes and/or demo the prototypes.

The client should be focusing on if this solution will meet their needs per the problem statements and user stories drafted during the last Discovery. There is also an opportunity to assess if additional use cases or outcomes are needed that were not brought up during initial Discovery once they see the solution.

The client should be asking Which problems haven’t been solved or use cases not supported? This helps prevent the client from giving more subjective or opinion-based feedback.

Following the review, there may be changes or feedback to the designs. Some of these may be pulled into the next draft of designs, and others may be pulled out for scope or added to a project backlog. Typically, we limit the process to 2 rounds of review so that it doesn’t go on indefinitely, and this ends up being more than enough in most cases.

Design Plan

Once the designs have gone through a second round of review, or if there are no changes, then the discovery and design artifacts are pulled together into a formal Design Plan that the client reviews and signs off on. The Design Plan also includes detailed walkthroughs of the prototypes and implementation acceptance criteria (and supporting evidence) against the user stories. This acceptance criteria will be a driver for development and User Acceptance Testing.

The Design Plan seeks to answer Did we effectively understand and meet your needs