A prototype does not need to imitate every detail of the finished work. Its value comes from making an uncertainty concrete enough to explore before the full project is built.
Choose the question first. A rough arrangement may test whether the content has a clear order, while a clickable version may test whether an interaction is understandable. State which parts are placeholders so the feedback stays focused.
Keep the result of the experiment alongside the prototype. Record what it showed and what remains unknown. A successful prototype may lead to a revision or a narrower idea, rather than approval of every detail it happened to contain.
Picture this situation.
Consider a paper sketch of a new navigation sequence. Trying the path may answer the ordering question without building every screen.
A second way to look.
Give the work one question to answer. A concrete purpose makes references, constraints, and revisions easier to judge without closing down exploration.
- Name the question the prototype should answer.
- Make placeholders clear.
- Record what remains unknown after trying it.
Follow a related question
Check the actual interactive area.
Touch targets with room to moveName the task the change should help.
Keep a small experiment logKeep learning
Related background to continue exploring this subject.
Git: version control fundamentals W3C: accessibility, usability, and inclusion
