Advice On Prototyping With Indigo
About Indigo Studio
The Indigo Studio prototyping model is pretty flexible—you can prototype most app interactions with it, but you can sometimes achieve similar ends by following different paths. Below you will find guidance on which path to choose for designing your prototypes.
If you are accustomed to using wireframing tools, or even just Web sites in general, you may be used to creating individual pages/screens/files/mockups (whatever you prefer to call them) in order to illustrate the different states of your app prototype. Indigo supports having these individual things as Screens.
On the other hand, Indigo also has support for States, which are contained within individual Screens. These states typically represent small changes to a Screen in response to some user action (i.e., an interaction).
So the question arises – how should I represent my prototype changes? Do I use a new Screen or a new state of the same Screen?
Screens or States? There is no black and white answer—it depends on your context; however, there are some considerations that can help you decide, as follows.
|Your scenario…||What to do…|
|Is the main layout significantly different between one and another?||If so, a new screen is probably the better solution. Conversely, if most of the layout and elements are the same and only minor changes are occurring, a new state is probably better.|
|Would you have it as a separate page/design (for instance, Homepage, Product List, Product Detail)?||If so, a new screen may be the right choice; if it is just a minor variation on a primary page/design, a new state is probably best.|
|Do you want to have fine control over the transition from one state to another (i.e. you want to animate the changes)?||You get this with states/in-screen interactions—when you create a new state, Indigo gives you a timeline that tracks the changes between the states and lets you animate them; screens only provide high-level transitions. (Think of the difference between transitions and animations in PowerPoint/Keynote—a slide would be an equivalent to a screen in this aspect.)|
Depending on the scope of your prototype, you have these two alternatives.
The scope of your prototype is essentially to walk someone through a specific sequence of interactions to illustrate that one path/story.
- Super easy to do; keeps the prototype simple and easy to manage.
- Good for just trying out a path before worrying about potential branches/edge cases.
- Perfect for illustrating a specific story.
- Good to target just a specific part of an app to prototype the interaction aesthetic without getting distracted.
- Good to communicate a specific aspect of the app experience to stakeholders.
- Good for targeted usability testing.
- Does not represent the full experience possible (or maybe even likely), by constraining users to one path.
- Will not work for exploratory testing (except to know that a user wanted to do something that you didn't enable them to do).
- Will potentially have lots of holes/edge cases that have to be addressed later with developers.
- Only add interactions in the state(s) that you want a user to try them—this means the interaction will only turn on from the state you choose.
- Stay focused on the story/scenario at hand—don't let yourself get distracted into defining what ifs.
- It is best to think about this as a sketch, so don't get too invested. Just do the minimum you need to explore the concept.
- These are fairly equivalent to what is often represented in storyboards, so starting from a storyboard can be a good way to stay on track and add extra user context to your prototype.
The scope of your prototype is to emulate an entire app or a coherent section/capability/area of an app.
- Allows you to explore and validate the design in detail—you can try the what ifs, the branches, and edge cases. Increased confidence that the design works.
- The more paths you define, the fewer what happens when? questions you get at implementation time.
- By more fully emulating the app, you can allow for more exploratory testing of the design.
- Can be used as the basis for further elaboration of the design at later phases.
- Can lead to investing too much in a particular concept. Increases cost to create and maintain, leading to more attachment and less willingness to change.
- Requires a little planning to maximize investment.
- Can set the wrong expectations—it can give the impression it's more than just a prototype.
- Until logic and persistent data are supported in Indigo, it requires many distinct states to emulate app behavior. Even then, emulation is limited without these—requiring notes or talking through to round it out.
- Plan a little up front how you should break up the prototype into screens, maybe even think about folder structure.
- Add interactions to elements in the screen state they are added (if a button exists in Start, add the interaction there, so it is clickable wherever it is visible).
- Design out, starting with the more important/prioritized paths first, then secondary (and so on). It's okay to use notes to communicate intent, especially for items that are either less important or based on known conventions (such as make this work like the popup design on the main screen).
- Consider using Storyboards, either up front to guide your design effort or later in the prototyping process to help validate design or just to communicate particular paths more clearly—you can include as little or as much of potential interaction paths in your storyboards as you want.
Here are some suggested topics: