[hcarvalhoalves]

The tips on how to prototype are very good. Let me give another perspective though:

You shouldn’t always prototype first, before mapping what kind of problem you have, at the risk of reinventing the (square) wheel.

Rapid prototyping is the holy grail software is known for. But prototypes are not always cheap, and almost always go to prod and turn into technical debt. In other disciplines the instinct to just try something first would sound ridiculous (e.g. let’s always figure out open heart surgery from scratch, it’s just a quick experiment, if the patient dies we figure out later).

I’m a fan of the Cynefin framework [1] as a higher level tool to figure out if I should prototype at all - even if not very precise, because at least it forces me to think about it.

[1] https://en.m.wikipedia.org/wiki/Cynefin_framework

[tobr]

One necessity for a successful prototype is that you have a pretty clear idea of why you’re making it and what you hope to learn. You also want to consider if the cost of making the prototype will be justified by those learnings. With experience you do this instinctively, as part of the process. You know what answers you need and how to get them cheap enough.

In the case of surgery, where someone’s life is on the line, it’s not going to be worth the cost.