When does it make sense to create throwaway HTML prototypes for web apps?

Question

I understand how you would go from low (sketches) to high fidelity (clickable interactive) wireframes as prototypes, testing along the way. But if your high fidelity prototypes were actual HTML/CSS in what scenarios would you throw these away in order to start building the site? If your HTML prototypes cover just the MVP (not some future vision past MVP) surely it would be inefficient to throw away the prototype and start building the UI again one story at a time?

I understand throwaway prototypes in other product sense, e.g. plastic moulds of eventual metal products, one-off cars to be tested before mass production, but with HTML you might as well use what you've built already?

Answer 1

Logical long term solution is to develop Design system and have everything modular. With a quick setup you can have a quick design / prototypes / html production system, where you wont actually throw away anything, than play with it like with lego bricks.

Also high fidelity prototypes must not be html, and with Sketch, Invision and Craft you can create pretty realistic design only clickable prototypes.

Rest I guess depends on personal preferences and what exactly is needed for delivery.

Answer 2

You are assuming that high fidelity prototypes would be in html. Are you using Axure ? (it generates html files)

If you are using Axure you will indeed get html prototypes but the html code won't be clean enough to be reused for production.

If your prototypes were coded from scratch I would say you can use it as a base.

Answer 3

Coming at an answer more as a programmer than a UI person, in a lot of cases, if you have the luxury to do so, it is very often a good idea to throw any prototype away once you get to a certain point and – not so much "start from scratch" – but start a re-implementation now that you know where you want to end up.

• The final prototype is likely to have been built iteratively; even if it is now (roughly) where you want it to be, the route it took to get there might mean its implementation isn't really "right".

• If the prototype is essentially "static" HTML, trying to retrofit dynamic creation (assuming that this is needed) may be messier than starting the process of dynamic creation from a clean(ish) slate (but using the static HTML as a known destination).

• If the prototype is being created dynamically, again the history of how the prototype was created may mean that the current way of creating the HTML isn't the best way of doing so.

In a lot of cases, you can by all means lift elements of the prototype into the re-implementation, but doing that – rather than trying to turn the prototype into a "finished product" – can often result in better code.

Obviously, you often won't get the time needed to do all this, and you have to just "harden" the prototype... but while I don't think I've ever regretted re-implementing a prototype when we've been allowed to do so, there have been many cases where we weren't allowed to and six months to a year later I really wish we had.