It’s generally understood that in product development you start at a low fidelity and increase fidelity and you gain more confidence in an idea. This was traditionally seen as necessary because development effort was expensive and therefore more risky to put toward building the wrong thing. 

So rather than build things, which is difficult and time consuming, we first made testable sketches. Then we made screens that kinda look real but lack the detail, then we joined the screens together into an interactive prototype to test how it might feel to use it. Once we’ve done all of this we hopefully had enough confidence to move our designs into production, and once in production we’d continue testing, only this time for usability. I’ve written this all in the past tense, but some of us still do this. And this article is trying to convince you that we all still should.

Fidelity of designs increasing over time. The journey was not quite this linear, we learned lots about what was and wasn’t important to users along the way, shaping the product in ways we didn’t expect at the start.

A new class of AI tools present us with a possible alternative approach. One where we can ditch all that low fidelity stuff and create something that looks finished and feels real, in minutes. With the problem of engineering effort seemingly solved, it’s tempting to skip these seemingly archaic, lo-fi methods.

High-fidelity too early is a recipe for poor learning

In product development there are two states that we operate in. We’re either trying to figure out how to make the right thing, which includes a process called ‘problem definition’. Or we’re trying to figure out how to make the thing right, which is only done when we have first figured out we’re on the right track. 

Showing what looks like a finished product to users during early exploration is like putting blinkers on them—you focus their attention on a shiny thing you made, preventing them from expressing the wider problem you’re trying to understand more about. The conversation is therefore narrowed toward your attempt at a solution rather than broadened to explore the edges of their experiences.

One method I use to get the right kind of feedback at the early stages of a project is the testable sketch. There’s a misconception that sketches are simply a crude version of the finished product. But testable sketches used during user interviews are less about presenting a finished idea and more about illustrating a narrative for the user. A testable sketch should present users with a story of problem, solution, and outcome. We then invite users to step into this narrative and question how it relates to problems they’ve experienced themselves.

A sketch used to explore the idea of a driverless car service for escaping the city.

If you’ve not done this kind of research before then it’s hard to understand how different the conversation can be when you show an artefact like a sketch instead of an interactive prototype. To illustrate, let’s say we wanted to test the idea of a recipe box service.

Interview A: An interactive vibe-coded prototype

In this interview we present users with a functional app where users can choose a few recipes and order their recipe box. During the interview the user might start to explore the app, tap a few buttons, choose some recipes, perhaps get hung up on the issue that some options aren’t to their taste. Finally, they get a few in their basket, checkout, and remark that it was, “Easy to use.”

Interview B: A testable sketch

We present users with a sketch and it shows a frustrated user trying to do their weekly shop online, a screen with some recipes, and a happy user cooking a meal with no waste. From here we begin a conversation that uncovers their counterintuitive enjoyment of scrolling through 100s of products each week via their usual online supermarket app. We might hear that they don’t really like to cook from recipes and instead just make it up as they go along. 

Showing a prototype that looks and feels real in Interview A created a narrow conversation which didn’t help us learn all that much. Whereas Interview B explored the user’s experiences of the problems we’re trying to better understand and led to some fundamental insights that brought the whole proposition into question. 

Showing what looks like a finished product to users too early in the process reduces our opportunity to learn by making the conversation all about functionality. In contrast, showing a sketch enables us learn more about the problem. It’s important because a sketch gives the impression that the solution is yet to be fully defined and still open for their ideas and interpretation. In the early stages of product development we should remain disinterested with how the idea works, what we need to be concerned with is whether the problem is true and the outcome is valuable. The sketch itself merely serves as a device to facilitate the conversation with the user. 

It feels faster but it often isn’t

Ten years ago this iterative process of starting with a sketch and increasing fidelity over weeks felt like moving at a rapid pace. We would compare it to client teams who had spent 18 months developing an incredibly complex product that failed to gain any adoption. They built and shipped without ever gaining a foundational understanding of the people they wanted to serve.

With AI and vibe coding tools we are presented with the ability to create in hours and days what would have taken entire development teams weeks and months. This changes our perception of the speed of an iterative process but it doesn’t change the issue of spending time building the wrong thing. Your working product may be up and running in hours, but understanding if it solves users problems remains a challenge. Several versions and months later it might feel like you’re going round in circles and making little progress.

Spray and pray

There is another school of thought. One where we build lots of things quickly and see which one sticks. This approach isn’t new, even before vibe coding, capable developers have thrown up multiple quick experiments and watched eagerly to see which gains traction. In this mode, the products that do well tend to be the ones where creators solved their own problems. AI tools have made this approach available to people who aren’t developers. I’m here for it, it feels DIY and kinda punk. But it’s important to note that when building for your yourself the question is not “how can I solve a user’s problem?” Instead it’s, “does this solution to my problem have an audience?”

We’re not always scratching our own itch. More often than not we’re working to serve others; people with different problems to us that we don’t fully understand. The rigorous process of early stage product development: the depth interviews; the creation of testable sketches; the lo-fi prototypes; they all serve to build up a comprehensive understanding of the people whose problems we intend to solve. 

Quickly launching ideas was always possible with the right resources. What stopped us from diving headfirst into building a product was never really about budget, resource or talent. What we really sought was confidence that we’re creating something people need. Whilst AI tools present us with a new method of creation, the problem of making the right thing persists and our low-fidelity methods remain the best way to figure that out.