Prototyping is the transition from talking about it, to doing just enough of it to see where it takes our ideas. Not until we build a semblance of our solution can we test to see if our ideas stick. Prototyping drives the feedback loop and becomes the launch point for ideas we want to invest in.
Where does prototyping fit?
In Design Thinking, we progress through:
- Empathy to understand our users
- Definition to describe the problem we want to solve
- Ideation to envision possible solutions and prioritize them
- Prototyping to give form to a solution
- Testing with our target users
The combination of prototyping and testing provides feedback loops into the earlier stages. Without bringing ideas into the physical world, things are only mildly interesting. Like solving the world’s problems over a beer. Feedback loops are key to evolve ideas into solutions.
Let’s say that our prototype looks promising. Should we invest in implementing our ideas? This is a mindful decision, not just a logical extension of prototyping. The sunk cost fallacy always plays: “We have already spent so much on this prototype, we really should develop it!” The point of the Design Thinking steps is to learn, not to become attached to the prototype. So now that we know everything we know, does it still make sense to invest?
If we decide to proceed, then the prototype drives the development backlog. Ideally, we continue in an agile way that continues the notion of iterations and small steps. Something like this:
This makes prototyping the connection between design and development, in a broad sense, and the prototyper the linchpin. No pressure!
Just Do It: With Crayons
Car designers have access to amazing computer aided design tooling, but they still use clay models to try out and refine ideas. Similarly, product designers use all kinds of mock-up techniques to test ideas with test groups. In software development, we push back against such low-fidelity techniques. Because we love technology. And overengineering. And diving into solutions head-first. More is more. But that all gets in the way.
Creating something just for learning and throwaway does not come naturally and requires self-discipline. We forget that the reason for prototyping is not the first step of the solution, it is a technique to better understand what sticks and what doesn’t. The outcome is the learning. Yes, I mentioned throwaway… unless you’re creating something iconic where people pay to see your prototype in a museum, it is disposable. It took me a long time to come to grips with that at many levels, but it’s liberating.
Low-fidelity prototyping
By low-fidelity, we mean an interpretation of the solution that isn’t pixel perfect. It may be a paper design and a wireframe. The goal isn’t to test the visual aspects, or if a design is “pretty”. For prototypes of software-based solutions, we want to narrowly focus on the key elements of the solution. It’s also not an architecture or feasibility prototype, those may come later. Right now, we are interested in an initial assessment of our direction. This is no different from any other type of solution, say an operating model or a physical product.
What makes software software is that it encapsulates behavior with interactions in a user experience. So we need a mechanism to implement that behavior. Fortunately, we have access to a squishy computer that can do just that: your brain.
The lowest of low-fidelity prototypes is like a Las Vegas blackjack dealer. Only instead of cards, she uses a paper model of sketches and wireframes to mock the interaction between a user and the solution. It’s fast, easy, and collaborative. We can learn and iterate quickly. Of course, it requires a fair bit of imagination, and the interactions are limited. As the paper prototype solidifies, it represents the best documentation of the idea.
The next step is to extend the paper model with a navigatable wireframe. We’re still not shooting for a target visual design and want to keep things basic. At this stage, we want to introduce tooling to give more definition to the experience and the interaction models.
High-Fidelity Prototyping
High-fidelity prototyping seeks to create a user experience that is close to the target experience. We still want to do this rapidly and not get sidetracked by the implementation details that we’d we have to worry about if we (gasp!) actually develop the solution. We really want to avoid building a prototype with the target technology: it inevitably leads to wanting to build version one of the solution, rather than learning. We just can’t help ourselves.
It requires more effort to develop a high-fidelity prototype, but it results in something a more tangible and lifelike. We now have a realistic and detailed visual design that looks like app or site. Something with actual content and a clickable interaction model. But we don’t invest in that effort until we have a sense that it’s worth it.
We expect users to interact naturally with our high-fidelity prototypes. Usability is important, but it should be grounded in the user’s ability to achieve outcomes. The temptation is always to add more features. More is more! Good design and a good prototype take a minimal approach first. Most importantly, the prototype should be driven by our learnings from the empathy stage. We want to keep thinking outside-in, not inside-out. And we should not forget to steal like an artist.
High-fidelity prototypes are great communication tools to get buy-in from clients, stakeholders, and investors. Something tangible always beats a description of it. Ultimately, the brain wants something exciting that’s hard to achieve with the low-fi crayons. But it’s more effective if it’s getting close to the right thing, not just the shiny thing.
Testing
Traditionally, even with agile approaches, testing doesn’t start until the initial code has been laid. By that point, it’s already becoming expensive to make big changes, like ditching the solution in favor or a better one. We want to test as early as possible, based on the low-fidelity and high fidelity prototypes. It’s a Shift Left mental model.
The most important reminder for testing is that we want to test with the actual users or customers that we started the Design Thinking approach with. We don’t want to introduce proxies or surrogates. Testing is just another mechanism to gain empathy. We may learn things we didn’t expect. How exciting!
Our main tools are observation and feedback sessions, supported with usage-based data if available. Our attitude is still one of learning: no attachment to the solution, unafraid of sunk cost. I know, it’s not easy.
Takeaway
Prototyping and testing shift us from design thinking to design doing. They are the main source of a much-needed feedback loop and a transition point into investing in developing the solution. Depending on the stage of the solution, we use low and high fidelity prototypes that we put in the hands of our users. Like poetry in motion.
Ernst Rampen ©2018
