What won’t change
Prototyping is fantastic
If you’re here in search of a text complaining about prototypes, you’ll have to go somewhere else.
Prototypes are a brilliant form of software documentation
- What will happen when I hover over this link?
- How will this button react to a tap?
- What will happen to this complicated element on a small phone screen?
- Should this control be a normal text field or something slicker?
- How will the search engine work?
- How will this project look after implementation on various platforms?
A prototype can answer these questions much faster and nicer than a few‑hundred‑page‑long document.
The finished documentation of software isn’t finished software
This is worth remembering and reminding stakeholders about. Especially considering that we are nowadays able to quickly prepare prototypes that deceptively resemble finished software.
Even excellent prototypes are optimistic in their assumptions, implementations of business logic, handling of edge cases, and approaches to security. It’s good to communicate these things. More than once. The responsible management of expectations is crucial for prototyping’s positive reputation.
If you prototype a large app, your prototype is an app
Apps need cleaning. If you have been working on a prototype for more than a few days, chances are good that you did something in it “fast”. I use prototypes to explore various design directions and potential solutions to various problems. It’s good to be able to compare several solutions. Sometimes as many as a few dozen. In the end, there is only one. Sometimes, you have to do something just for a specific meeting. Sometimes, to temporarily save time, you omit the responsiveness. Sometimes, you hack something as part of rapid prototyping. All this has to be cleaned once in a while.
Without cleaning, prototyping is not pleasant:
- There are many strange problems with the way the prototype works (so–called “bugs”), usually arising at the worst moments.
- It’s difficult to work on the prototype with more than one person.
- Developing the prototype begins to take more and more time.
Prototype code belongs in the trash can
The prototype code is written in a completely different way from the production code.
Prototyping is not effective if intended to be used in production – in the product that the end user will interact with every day.
Prototyping and programming apps are two different activities. The intentions of people suggesting to combine them are generally good, but I don’t know too many cases in which this has worked for the benefit of the project.
Focusing on prototyping doesn’t mean abandoning other tools
A sheet of paper, a pen, and software for creating static visualizations have and always will have their place in the design process.
I’m not going to write about post–it notes because I have never used them.
A good prototype doesn’t exist without good data
Good data builds the authenticity, trustworthiness, and sense of reality and completeness of a prototype. Bad data can spoil even the best prototype.
There is often no way to use a production database or API in a prototype. It’s worth learning how to scrape and clean data.
Use real data. Fake it until you make it. Fake it good. If you have to use fictitious data, take care to make it realistic – long names, short names, missing data, edge cases.
Prototypes have a unique value
Imagine that you can use an application that you haven’t yet paid for, seven months before it’s created. Doesn’t that sound like magic? If it doesn’t surprise us, it’s only because we’re not surprised by anything anymore.
Prototyping costs more than just someone’s time
A computer with macOS, a computer with Windows 10, a computer with Windows 7, an iOS phone, an Android phone, a new iPad, an older iPad, an Android tablet, […] – it all has an associated cost.
Prototyping experience also has a value that can be expressed in money.
These things will not change this year. Let me know if I missed anything. Successful prototyping!