Indigo Studio Design Rationale - Defining Interactions

There are many tools available today for designers that claim in some way to be a "prototyping" tool. Most of these imply some kind of interactive capability, and by far most of them, oddly enough, simply mean by this "you can create links between screens." You see this even in wireframing and otherwise static design tools--you can create a clickable PDF, you can link between pages, etc. Heck, even Visio lets you do this.

I suppose ten or maybe even five years ago, that could have been enough, but is it still good enough for today? This article on UXmatters, "Are You Still Using Earlier-Generation Prototyping Tools?", goes into the topic at some depth. Indigo Studio falls into the last category of "Dedicated, Generic Prototyping Tools" (the reason we're not mentioned is that this article was written before Indigo was released).

Even though we're in that category, we did try to address some of the limitations--we have intentionally focused on the "rapid" side of prototyping so that you can indeed use Indigo early on in your design process (in fact, you should because Indigo is optimized for that part of your process). Our experience has been that once you get past some initial brainstorming with paper/whiteboard, it is often considerably faster to sketch out ideas in Indigo, especially if you want to sketch a whole story and not just, e.g., a single screen. And designing based on stories is, after all, a great way to design (we even have integrated storyboarding to help with that).

Furthermore, Indigo Studio does not simply let you define static links between pages/screens; it has a much more capable framework in place to let you define not only small changes to the current screen but also to design smoothly animated transitions for those changes, as is a basic requirement for many apps these days. This is something you just can't do with 90% of the so-called "prototyping" tools on the market today that are nothing more than clickable mockup tools. It's amazing that many of us are willing to live with clickable mockups as a prototyping tool in this day of rich, animated interactions. Maybe we didn't have a good alternative before, but we do now! :)

STOP
Now, before you read further, make sure you know what we mean by interactions and interactive prototyping. Seeing is better than writing in this case, so check out this short video that gets your feet wet with designing interactions with Indigo Studio. If you want to get a sense of how we help you design animations, try this one on animating transitions with Indigo Studio. And if you're feeling really brave, read this help topic, which will help you understand and thus master screen interactions and states.

Now, as mentioned in the last article in our "Rationale" series, Indigo Studio tries very hard to stay focused and, thus, to help you stay focused on your users rather than on your technology. That's why we have integrated storyboards. That is also why, when you want to add an interaction, we phrase the software dialog in that way:

When you select a screen element--any element--you can add an interaction right there--it is contextually shown to you: ADD INTERACTION. You don't have to go searching for an Interactions panel. You don't have to convert it to some special kind of object that supports interactions. Just select the element, and right there, you can add interactivity from the user's perspective ("When the User…"). And when you choose to do that, we keep that perspective:

Notice the flow of the dialog: When User . We don't make you find a "triggers" or "events" section in a panel somewhere. It's right there and it keeps you thinking about what's going to happen for the user and less about what's going on with the technology.

So what can you do in response to some user action? We've chunked it out into two most common options (and some others if those don't fit). Most of the time, you'll either be making a change to the current screen or you'll be navigating to a new screen. If you're wondering about which choice is right for you, you can click the Help Me Choose link there. If you want a more thorough explanation, you might read our advice on prototyping with Indigo Studio. To put it simply, if you want to make a small change to the current screen, choose Change This Screen; if you want to go to an entirely new screen (e.g., another page on the Web site you're designing), you could choose Navigate.

The reason this choice is important is that if you are only making small changes, you don't need to create 10 different screens that illustrate the different possible states of one actual screen in your app. If you've used wireframing tools, you can appreciate how annoying it can be to have to deal with a bunch of different pages/mockups to show simple state changes (ending up with names like Product List_showing review, Product List_default, etc.). Another benefit of Indigo's in-screen changes approach is that it is super simple to animate those changes after you make them (again, see this video introducing animations). Lastly, a side benefit of just changing the screen is that it makes the Start state of your screen effectively like a "master" for all of the states on that screen, which can make changing things in your prototype significantly faster--you only change a common/shared element once, and it is reflected in all states where it is not set to something different. This makes iterating over ideas much much faster than in many other tools. Similarly, it means you don't have to manually duplicate and manage copies for all these different states.

So back to the point at hand--you simply choose what happens for a user in response to the action you want to design for. If you choose Navigate, then you make a choice between navigating to some external URL or to another screen in the project:

Choosing URL lets you type in a URL, but more interesting here is the screen in project option. This way you can pick an existing screen, but even better, you can create a new one from this link.

You can see here an easily searchable, visual gallery of the screens in your project and pick one of those, or you can type the name of a new screen and choose Create. The benefit here is that you can stay in the flow of the story you have in mind. The user clicks, let's say, My Account link you set up, and you can in the context of setting up that link easily create the target screen if it doesn't exist. Doing this creates the new screen, opens it, and adds the navigation link to it. These are steps you have have to do individually and manually in many other tools that do click type interactions: 1 - New File, 2 - Save New File, 3 - Go to prio file, 4 - set up link between two files, each of these steps requiring multiple clicks and sometimes keystrokes. In Indigo Studio, it is one, quick fluid path and you're done in a couple seconds.

Now, there are some tools that let you just specify a link by picking from some local file names in a drop down. Why is it, then, that in Indigo, you go through a few clicks to get the same result? Well, first off, in these other apps, you don't have the other choices that you have with Indigo (namely, changing in-screen state). If all we did was offer screen to screen linking, sure, we could just offer a simple property picker. Heck, even with our Add Interaction dialog, we could add another property on the property sheet that has that experience. But our reasons for choosing not to provide this way to define links are:

1. You might not learn about in-screen interactions, which frankly are really useful and powerfully expressive.
2. You would have to learn two ways to add interactions: one way through the Add Interaction approach, the other by specifying a Navigation target property. This could cause confusion about why there is such a property as well as another way to add interactions. We wanted to keep the path simple and unified so you don't have to remember different ways to add interactions. This is consistent--no matter what kind of interaction you want to add, you start by choosing Add Interaction.
3. We strive to keep a Clutter Free UI in Indigo, only surfacing properties and actions that are usually useful for interaction design, and only when they are needed. Having another property to do what you can do otherwise is clutter.
4. We show the list of defined interactions in the Interactions section, but this theoretical picker is for a property, so you would see some interactions defined under properties and some under interactions--it would be inconsistent and confusing.
5. In general, in Indigo, we try not to assume you are an expert, so we avoid obscuring important things. For interaction design, adding interactions is of utmost importance. The very prominent Add Interaction button is hard to miss, and we take you by the hand from there, having a straightforward dialog with you on how to do what you want to do, rather than making you poke through tons of panels with tons of little finicky properties and drop downs.
6. We try to optimize important/most common choices over less common ones, so you don't have to search through a long list of equally weighted options when 80% of the time you want to do one of two things. Some tools out there don't do this for you, instead giving you a list of like 20 options in one big fat dialog; this did not seem good to us.

So we decided that it is best to stay consistent and clutter free, providing an opportunity for clear dialogs with fewer, more relevant choices, with the trade off of needing a few clicks to do it. And really, what is a few clicks compared to all these. I should add, by the way, that we came to the current design through usability testing, after finding that designs with more choices up front (and fewer clicks) were more frustrating for people to grapple with.

All that said, if someone were to, say, suggest a keyboard accelerator to jump straight to the Navigate to Screen dialog, there's a good chance we might add it. ;)

Changing the Screen

While navigating to new screens/pages may be the most familiar way to design UIs in prototypes, Indigo offers you arguably more value if you choose the other option when adding an interaction--Change This Screen. If you will, rewind your mind back to right after you click Add Interaction, and instead of choosing Navigate, choose Change This Screen. Then you'll see this:

Taking the in-screen changes approach is really great for quick, story-based prototyping. You can just nearly experience the user's perspective as you are sketching out your prototype: user clicks X, a few changes are made, then user clicks Y, a few changes are made, then user clicks Z, and they're done. Hit Run, and you test it out. Then you can go back, iterate, add animations, add alternative paths, etc., as you see fit. This approach is different from what most of us are used to, but we've found it offers a lot of helpful benefits for prototyping as illumined above. To get more familiar with this model, I again highly recommend this help topic to really master it, and watching this video as a good intro to interactions. But you should also just try it out--it's easier than it sounds all explained out like this. Just leave your preconceptions from other tools behind, though! This is not your mom's prototyping tool.

Visualizing the Interactions You've Defined

In addition to quickly banging out prototype concepts with minimal effort, we also help you think through what you've designed. This is where the Interactions Explorer comes in handy. Just click the drop down button at the top of your screen that shows the name of the current state. If you see this (the Interactions Navigator, which is useful for quickly switching between states), try clicking the little expando icon:

Clicking that will expand it out from the Navigator (a.k.a., mini Interactions Explorer) to the full Interactions Explorer shown next. (BTW, you can toggle between the Navigator & Explorer, and we'll remember your choice when you open it again.)

Even while you're designing a new idea, it can be easy to get lost in most tools--especially static mockup type tools, but even in fully capable tools like hand-coded prototyping. Once you've designed a handful of interactions, you basically have to remember in your head what you have designed.

Indigo Studio helps you with this challenge by offering a visualization of the interactions that you've defined. The screenshot above is the Interactions Explorer for the Flight Search screen in our Rove sample. Zoomed out like this, it shows at a glance the various interactions/possible paths a user can take through the prototype screen. Links are shown as little labels that you can double click to open. Changes from one state in the current screen to the next are shown as thumbnails, so you can see the differences visually, in addition to the names (which by the way are intelligently auto named). If you hover over a thumbnail while zoomed out like this, you see a full size thumb and other information:

This way you can see the whole interaction flow tree while drilling in to particular details. This example shows that when a user taps/clicks SEARCH, the prototype will change to the Tapped/Clicked SEARCH state (an auto named state). You can double click to open that state and start editing it directly. Now, this is useful when you're currently in the prototyping-like-a-mainiac zone, but it's even more useful when you come back to a prototype after a few days or weeks, or when you have to work on someone else's prototype. It gives you a way to much more easily understand what is going on with it.

We offer a similar visualization at the project level, too, to help visualize your screen-to-screen links/navigations as shown here in our FindFlix sample:

When you're on the project view, you click the little node diagram icon over the list of project designs to see it. This one is not as powerful or meaningful as the in-screen diagrams (it's just the nature of the beast), but it can help you see how your screens are linking to each other at least, without you having to manually keep such a diagram up to date.

On top of these automatic visualizations, you can use storyboards to situate specific paths through your prototype in a user context. You can even, if you didn't start from a storyboard, create one from a path you select in the Interaction Explorer and choosing Export selected to Storyboard:

Then you can add narration around the path in the storyboard, add contextual scenes, etc. This is a way to guide people through your prototype, and it lets you add a layer of contextual information on top of that.

There's plenty more to say, but this post is already long; so I'll wrap it up now. Above I hope you gained a better understanding of some of the design rationale that went into how Indigo Studio lets you define interactions. They are core to doing interaction design prototyping, and we've spent a lot of time trying to make defining them relatively simple and yet extremely powerful, expressive, understandable, and manageable. Enjoy!

About Indigo Studio for Interaction Prototyping

Don't have Indigo Studio? Download a free 30-day trial which will let you try all of the prototyping goodness.

Download Indigo Studio

Looking to suggest improvements and new ideas for Indigo Studio?

Submit a new idea

If for some reason you are having trouble with Indigo Studio, check out our help topics, forums or contact support.

Get Support

Follow us on Twitter @indigodesigned

About the Author

Ambrose Little is principal design technologist at Infragistics and has worked on Indigo Studio as interaction designer and product manager along with an awesome team based here in Cranbury, NJ, USA and Montevideo, Uruguay.