Digital Product Design

Digital products are a constant part of our daily lives: Whether we’re planning our route on public transportation and buying a ticket, comparing different products before making a new purchase, or reserving a conference room at work—all of these activities, and many more, are made easier today by countless digital products.

The overarching goal of this phase: To identify the problems faced by potential customers and users and to assess the market for them.

The most important question in digital product development must be asked at the outset: What problem do we want to solve—and for whom?

Avoid “getting attached” to solutions too early, before the underlying problem has been thoroughly examined. All too often, this leads to products that do not address valid problems or solve them only inadequately.

That’s why we typically begin the discovery phase of digital product development by examining potential target audiences and user profiles. In empathy and ideation workshops with our clients, we develop a shared understanding of customers, their pain points, goals, and everyday challenges (e.g., in their professional lives or in relation to a very specific task).

Ideally, this analysis is already based on existing data, such as interviews, surveys, or observations of users.

Subsequently, the identified problems can be described in specific problem statements, and any existing potential solutions can be examined as part of a market and competitive analysis.

The overarching goal of this phase is to derive solution hypotheses from problem statements and align requirements with business objectives.

Based on the insights gained during the discovery phase, initial sketches of potential solutions can be developed in design thinking workshop formats, and corresponding hypotheses can be formulated.

Hypotheses formulate testable assumptions about the relationship between a proposed solution and an expected effect. These hypotheses help in developing clearly defined solutions to identified customer problems; at the same time, they enable the early validation or falsification of ideas. This can be done through small experiments during the definition or prototyping phase.

For example, to gauge demand for a new feature that would complement an existing product, a so-called “fake door” (a simple information page or sign-up option) can be used, which allows you to quickly determine, with minimal effort, whether there is interest in the market.

Formulating potential solutions as hypotheses also makes it possible to prioritize different features even before prototyping and implementation begin. This allows for the prioritization of those features that best contribute to business and user goals.

As potential solutions and features become more concrete, we recommend creating a comprehensive overview of the product scope using a storymap. This serves as the foundation for the subsequent implementation phases and allows the team to adjust the project’s priorities and scope at any time.

The overarching goal of this phase: to bring ideas to life and validate them.

The next step is to test the ideas and theoretical hypotheses. To do this, prototypes should be used—that is, more or less simulated visualizations of the product idea that do not yet require an actual technical implementation.

Depending on the time and resources available, there are various methods for creating prototypes. These differ in terms of “fidelity”—that is, how realistic the simulation “feels.”

Often, however, “less” is “more” in this context—or to put it another way: it’s better to arrive at test results quickly than to spend a lot of time creating elaborate prototypes. After all, this phase is primarily about gaining insights and testing our assumptions. Often, even simple paper prototypes or clickable “low-fidelity” prototypes are sufficient for this purpose.

At the end of this phase, we have design hypotheses that have been either verified or falsified. This allows us to formulate new hypotheses and test them again—until we have sufficient verification to begin the actual implementation.

The overarching goal of this phase: A digital product team uses a sprint-based process to turn a prototype into a working product that is ready for market launch.

The build phase is about turning a validated product idea into an actual, functioning digital product.

We recommend that this be implemented by a cross-functional team using an agile workflow, as this approach offers the necessary flexibility and efficiency. Based on the story map developed earlier—which is continuously updated and expanded within the agile workflow—the digital product becomes more complete with each sprint.

Continuous deployment allows for testing throughout the development process and prevents the product from not being ready until after a long development period. On the contrary: The team’s prioritization follows the initial feature prioritization. This ensures that the product’s essential core functions are implemented first so they can be tested more thoroughly and modified if necessary.

This approach also significantly reduces “time to market”—initial versions of the product with a greatly reduced feature set can be used long before a comprehensive version is completed.

The overarching goal of this phase: Launch the product, gather user feedback, and continuously improve it.

A common mistake in digital product development is to view the launch as the final step in the product development process. In reality, that’s when things really get started.

Despite early market analysis, testing of design hypotheses, and user testing with prototypes, it is only the actual market launch that provides a reality check on the product’s acceptance.

Using user research methods to monitor the product launch and the period that follows—in order to gather feedback from users—can provide valuable insights for continuous optimization. This way, even good products keep getting better over time.