Advice On Prototyping With Indigo

Overview

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.

Screens vs. States

Introduction

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 vs. states guidance

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.

Guided/Story-based Prototypes vs. App-Like Prototypes

Depending on the scope of your prototype, you have these two alternatives.

Designing a guided/story-based prototype

The scope of your prototype is essentially to walk someone through a specific sequence of interactions to illustrate that one path/story.

Pros

• 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.

Cons

• 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.

To create one with Indigo Studio

• 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.

Designing an app-like prototype

The scope of your prototype is to emulate an entire app or a coherent section/capability/area of an app.

Pros

• 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.

Cons

• 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.

To create one with Indigo Studio

• 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.

Learn More

Here are some suggested topics:

• Adding your First Interaction
• Understanding Screen Interactions & States
• What Do We Mean By Prototype?