The Case for Early Prototyping
When it comes to building digital prototypes, failure is not only an option — oftentimes it’s the point of the process.
It’s all part of what DSI co-founders Martin Bravo and Rune Madsen call embracing a “prototyping mindset,” where designs are put to the test very early on to help strengthen ideas and align stakeholders around strategy. This process of vetting ideas through code-based prototypes has become a core part of DSI’s practice. To explain why, Martin and Rune recently sat down to chat about their approach toward testing functional prototypes and the business insights that can come out of failure.
I think it’s about getting into the habit of acting early on ideas in order to prove their worth. It’s easy to imagine an amazing app that nobody wants to use. Functional prototypes make it possible to test your assumptions as early as possible and to make mistakes at a point where the financial implication is low.
Along those same lines, it's really hard to see the trade-offs when your problems are not concrete. You may have these grand strategies and everything seems amazing, but the moment you make it real, you have to make hard decisions and be like
okay, we can’t do this and that at the same time — which is more important?
The key point is that you can’t build a huge product all at once, so we have to force ourselves to keep things small and manageable and not chase after grand ideas without actionability. Prototypes are not a mock-up of the product; they are a vehicle for learning, which frees the prototype from having to be product-worthy. It is a proxy for the ideas and the questions that you have during the design phase.
We also may build a prototype that will never work as a product, but it helps shape our thinking in terms of what the strategy and direction should be for the next thing we build.
You have to force yourself into making these mistakes early. It is a very hard thing to do, but it’s a part of what we call embracing a “prototyping mindset.”
In a world where designers polish everything and make complicated Figma designs, the first time you actually try to see whether it’s doable with code and logic is when you build it for real down the road. This not only introduces a lot of duplicate work, but it also ensures that critical mistakes are done at a point where they are very costly. If eight months into a project you realize that there are major problems with the concept, it’s hard to undo things because there are so many teams involved.
There is this idea from businesses that design is cheap, and engineering is expensive. But the only reason why organizations think that way is because engineers don’t typically work in fault-tolerant environments. It’s always production code — you can’t mess anything up.
Instead, we believe in pulling engineers early into the design process, which has a ton of benefits. Engineers can write code really fast and loose if they are allowed to play by the rules of design instead of this production or security-focused environment. And if it doesn’t work, it’s at a point where it’s very easy to make changes. You can do a complete pivot, or just change a few things.
There currently is a persistent culture of building prototypes that are based on no-code tools, like Figma, that are meant for designers who do not code. And that has been synonymous with cheap or lo-fi ways of testing things. The problem is that it’s a fake product — there isn’t real data involved, so you end up with something that is pretty far removed from reality.
When you resort to code, you can make something that is much closer to reality. You can have data that belongs to a user and they can see themselves using it, which helps them respond to more precise questions.
There is this idea from businesses that design is cheap, and engineering is expensive.
It becomes a vehicle for alignment. There is a layer of interpretation that comes when you don’t have something tangible to work with. I can be imagining one thing, but Rune can be imagining a completely different thing. Prototypes help reduce the space for subjectivity. It will take more work to build a prototype that is fully functional, but the learnings from that will save a lot of wasted time in cycles of fixing stuff after things have been built.
Companies should invest resources in early experiments, innovation, and testing — like creating early prototypes for their ideas — not necessarily as a way to test on end users, but to talk about ideas internally in order to align on strategy. Businesses can sometimes get very conservative very early in terms of strategy and focus. But because we know that early prototypes are never meant to represent the final product, the process allows us to go a little wilder, make decisions and just try things. The first prototype will probably be horrible or not work at all. But it shapes the organization’s knowledge around what works and what doesn’t work so you can make better decisions down the line.
How can organizations get started?
You can’t do early functional prototyping without having a multidisciplinary approach to team-building and the way you collaborate, so that means designers and engineers doing things together.
Yeah, there has to be a combination of people who can dream and people who can build. Those are very different mindsets, but they need to collide and create ideas around that. The multidisciplinary approach to teams is really about letting go of predefined roles. Organizations tend to put people into buckets, and people put parts of themselves to sleep in order to fit in, but they are still there. The moment you pick them up and allow them to expand, they will take up that space and actually flourish. The cool thing about this approach is that if you put engineers and designers together in a room, they will learn from each other. Eventually, the builder will start dreaming, and the dreamer will start building.