Deep tech meets user-centered design: two practical methods to get started

A consistent focus on users isn’t just important during the development of a digital product. It’s a key foundational principle even when searching for a business model, especially when it comes to complex enterprise software. In this article, we’d like to show why a human-centered approach gives startups the best chance at success, and happy users. Using the startup steadybit as an example, you’ll learn which methodology to use to integrate human-centered design from the very beginning and thus create products that solve real problems.

In a nutshell, who is steadybit?

steadybit is a deep tech startup focused on chaos engineering. This ensures that even systems consisting of many different microservices and distributed architectures remain robust and maintain their functionality in the event of failures in individual components. 

In search of the sweet spot of innovation

When steadybit was founded, there was a vague sense of a problem, which gave rise to the initial product vision: “We want to find and address vulnerabilities in systems before they can cause harm.” At first, this vision was just an unconfirmed hypothesis. The next step was to test, learn, and understand, long before the concept of scaling even crossed our minds. But how do you actually get started? That’s where UX&I, as UX experts, came on board. 

The first two aspects were covered at steadybit: top developers were on board, and funding was secured for the time being. To address desirability, we now needed to adopt a UX perspective, and thus focus on the users. They are the ones who help us identify problems and can tell us how to make the solution appealing to them. But how do we reach them?

Get off the couch

Identifying and understanding user needs

Our Rule Number 1: You are not the user. And: You won’t find insights about users, the market, customer segments, or the industry while lounging on your damn comfortable couch. We can state this so clearly because, at steadybit, we first took the time to properly define value propositions, user journeys, product vision, and personas. On that cozy couch. Until we realized we were going in circles, it was time to take action. Only through contextual research can we discover and understand people’s needs, goals, and problems.

How much research is enough?

Since research involves time and money, we’re often asked: How much research do we really need? There’s no clear-cut answer, but one truth remains: zero people, zero insights (Eric Ries: “The Audacity of Zero”). So get out there, ask potential users, it’s always worth it.

Levels of understanding

Fundamentally, you should always be aware of three levels of understanding:

• Why does the user use the system in the first place? What needs are driving this?
• What does he or she want to achieve with the software, and what are the primary goals and tasks?
• How does the user behave at the operational level, and how is the software used?

An example: 

Why: I’m missing my girlfriend right now and really want to see her again.

What: I’d like to speak with her.

How: I use my cell phone to initiate a call with her.

Note: You can’t solve problems at the “why” level by addressing them at the “how” level. If there are inconsistencies or ambiguities in the motivations, the interface, no matter how good it is, won’t be used. Motives and basic needs relevant to digital product development include, for example, belonging, autonomy, and competence (see Diefenbach and Hassenzahl’s activity theory).

Gathering hypotheses

To ensure our approach is as focused as possible, we’re focusing on four core topics that we want to understand. 

1. Users and user groups
2. Motivations, goals, and tasks
3. Tools
4. Social, physical, and technical implementation

We assign the hypotheses to be tested to each of these four areas. In the case of steadybit, it looked like this:

Let’s get the conversation going

We now know what questions we want to ask, but what’s the best way to go about it? There’s now a wide range of research methods available, each with its own strengths in different contexts. Before you decide on a method, you should ask yourself two key questions: Do you need qualitative or quantitative results, and are you more interested in learning about behavior (the “How” level of understanding) or about attitudes and goals (the “Why” and “What” levels of understanding)?

It quickly became clear to us that interviews were the right approach for our primary research, but we also conducted remote usability tests and surveys in parallel to address specific questions. 

So we stepped out of our comfort zone, tapped into our network, and reached out to potential users and decision-makers to start conversations. We listened carefully, asked follow-up questions, and stayed focused on the problem space. In other words, our goal was never to sell steadybit, but to understand what problems people are facing today and how they’re currently dealing with them.

What happens to the research findings?

After the interviews, everyone felt proud. We’d had great conversations, learned a lot, and gathered an incredible amount of information. But who’s going to read all of this? What do these insights mean for our product? We needed a way to distill, share, and put this massive mountain of knowledge to use. 

Affinity mapping

Karen Holtzblatt and Hugh Beyer have developed a helpful method for analyzing interview notes. The goal of affinity mapping is to create a structured summary of all the insights gathered. Above all, it’s about listening carefully to and understanding the users’ voices. All you need to try this method yourself is a room (or a Miro board), two to six participants, and sticky notes in four colors. The core of the process is for the team to transform the interviewees’ statements into their own stories and interpretations. These stories are progressively clustered together until, ultimately, only a few core stories remain: condensed insights that can now be discussed in concrete terms and from which clear insights for further product development can be derived.

It’s crucial to always frame your arguments from the user’s perspective and never stray from the problem space. Proposing solutions is off-limits here. We’ve put together a detailed step-by-step guide with all the rules for you: Cheat Sheet: Affinity Mapping (PNG, 195 KB).

What have we learned at steadybit from affinity mapping? For example, the key insight that users are afraid of breaking something with chaos engineering. We also gained surprising insights regarding our hypotheses, for instance, that developers aren’t necessarily part of our target audience, since chaos engineering isn’t really within their purview. We uncovered new problems and identified where we need to dig deeper and which additional hypotheses we should test. We were able to prioritize our development backlog accordingly and determine what we want to build and test next. We were also able to derive clear design and communication principles for our product.

The problem has been identified, time to find a solution

It’s done: our hypotheses have been tested, and we’ve learned a great deal about desirability as a core aspect of the Sweet Spot of Innovation. These insights into the problem must now be translated into the solution space; we’re focusing on feasibility: How can we build something good? But it’s not always easy to develop a shared solution. 

Design studio workshop (aka Crazy 8 or Crazy 6)

The Design Studio Workshop method helps establish a shared understanding and a common language. It enables participants to generate, iterate on, and refine many ideas in a short amount of time, through collaborative brainstorming, sketching, and discussion. And it’s actually a lot of fun, too. Typically, the process culminates in a prototype or a layout. The method works best in three iterations with three to six participants. It’s essential that there’s already a specific question, and thus a framework, in place, such as a user story or job story (at steadybit, one example was: “As a user, I want to define my target quickly and easily and be sure that I’m targeting the right thing so that nothing breaks that isn’t supposed to break.”)

How does the method work? Each team member folds a sheet of A4 paper into six or eight rectangles and jots down a solution idea in each rectangle. Then, each person pitches their ideas to the team and receives feedback from the group. In the second iteration, it’s time to borrow ideas: You can mix and match from all the ideas, and jot down new ideas based on the best starting points. Finally, a “best-of” is drawn or modeled: One facilitator leads the way, and everyone joins in. We also have a step-by-step guide for this method available for you to download: Cheat Sheet: Design Studio Workshop (PNG, 172 KB).

Conclusion

Thanks to user-centered design and the right UX methodology, steadybit was able to hit the ground running and overcome obstacles right from the start. Our key takeaways from the process:

• We can only find important insights outside our building’s Zoom room.
• Learning is a never-ending process that takes place outside your comfort zone.
• Pivoting and validated learning aren’t hard: you just have to do them (and be willing and able to).
• Building the right product well requires an interdisciplinary approach.

If you’d like to learn more, steadybit explains in a separate article (in English) how the tech startup laid the foundation for its product vision. We also recommend the following articles and books on the topic: 

• Lean UX by Jeff Gothelf and Josh Seiden
• Lean Startup by Eric Ries
• Gamestorming by Dave Gray, Sunni Brown, and James Macanufo
• “UX for Lean Startups” by Laura Klein
• Testing Business Ideas by David J. Bland and Alex Osterwalder