Do interactive prototypes have to have every single possible screen?

Question

When prototyping an app do you have to prototype every single screen and screen state in the app so it seems like a coded product? Or is it just certain key flows? Wouldn't the prototype run into several hundreds of screens if I prototyped every inch of an app?

Answer 1

TL;DR: No. It's simply not worth it.

---

The main benefit of prototyping is to get a tangible and testable artifact at a low cost. You can use it to get your execs a clear picture of your vision but also to do some user studies. This allows you to do some quick and easy improvements without wasting costly development time.

This benefit loses all its purpose if we start prototyping the whole application. As you stated, you might end up with hundreds of screens. These do not only take countless hours to build, but are also difficult to maintain and at some point highly redundant.

You should decide upfront what you are trying to accomplish with the prototype and then build the required screens accordingly and in the desired level of fidelity. Or, as @Martyn stated in the comments, focus on what you want to show to whom. I would suggest a T-prototype, where your executives can get an overall impression of the top level architecture and then go into depth with the main interaction flow(s).

Ideally, you can explain the purpose and level of detail of your prototype beforehand. You could maybe even provide some scenarios (typical use cases) for them to play through and should be available for follow-up questions. If they are reasonable, this should be more than enough for them. If not, tell them that you didn't want to waste resources, because all execs are only focussed on saving money, right? ;-)

Answer 2

As with anything "it depends".

• Consider the purpose - Is this to show a client? for usability testing? to handover to a development team?/design team?
• Who is your audience? what do they want/need to see? Have they seen this before?/is this a redesign? are you trying to sell it? what kind of areas of the app are they interested in?
• How long have you got?/had? is this a 2 year mega project or a two week throwaway task?
• What existing resources do you already have? is there a mature design system or are you doing everything from scratch?

The point of illustrating these areas is that depending on the answers to these type of questions, the answer you need is very different.

As a few points from personal experience:

• Prototyping every screen may be possible or required if you're planning to hand off the solution to another team and walk away.
• Prototyping every state is likely not possible or desirable, but, if you are needing to hand off resources, prototyping the state of individual components can be helpful, then an implementation know how that component should be used wherever it sits.
• If you try to prototype many states, the ubiquitous "back" behaviour will cause you pain as it's common to have multiple entry points to a single endpoint, but because "prototyping tools" its often not possible to have a single back button be state aware, so you end up with many end screens which are identical except for their entry point and back behaviour. This can be a PITA to maintain.
• I've prototyped only making certain actions interactive, and often this can work, but if usability testing you will likely see more direct completions than indirect, the more things you make work, but aren't part of the desired flow for a test, the most indirect completions you're likely to get.
• I've also prototyped with placeholders, making key areas interactive, but deliberately not implemented. Think like an "under construction" notice. Whilst not desirable for some situations for exec demo's it can be a good way to call out that this area needs more time to deliver to the level of fidelity of the other areas.

EDIT: For execs

On reading your point about this being an "exec version to play with". I would be tempted to initially produce something much less interactive. I would suggest maybe some annotated screens which you feel communicate the overall app, it's key ideas and concepts, and the core flows. Put some of the more important screens into a powerpoint/keynote and email them out. Perhaps in that doc, list what you consider the most important flows and show others as box diagrams or simple screen > screen flows.

Call out aspects which aren't in the prototype and frame it as an illustrative example highlighting "some" of the core flows/key functions to "get a feel", be open an honest about what's not there and why it's not there. Offer them to chance to request a flow be added to the prototype, but explain first why you chose the ones you did and call out the time it will take you add the flow, honestly!

Ideally, do this in person (over zoom etc) to take feedback and answer questions before they get their hands on it. This will lessen frustrations over inclusion/exclusion from the prototype and set expectations.