Prototypes are an essential part to kickstart a project, but also a vehicle to test assumptions, check key questions, and validate decisions. There is a wide range of terms being used for prototypes. Here is my terminology in broad strokes. In practice, prototypes grow from one phase to the next, and the distinction is not so black and white.

Paper prototypes are the first stage in defining and visualizing a concept. These typically show work settings , storyboards, use context, wireframes of UI parts, but can also show system diagrams and technical sketches. They are not supposed to be flashy and shiny, but serve as working input for early discussion, evaluation and requirements capture.
Functional prototypes have limited technical functionality. They function well enough for the user to interact and perform a small task, but some functionality might be faked. Functional prototypes allow small scale testing.


At the stage that there are enough functions to complete basic workflows, I drop any adjectives, and just call it a prototype. This is the stage leading up to an actual finished application. Data connections should be in place to provide a ‘realistic’ looking interface, and the main dynamics of the work process should be reflected in terms of time, complexity and cognitive load.
(Note – the data in the image is made up.)
After this, the prototype should grow to a releasable product or MVP, and from there on, this should be regular product development and maintenance.