This year I’ve started to show you some of the custom process that I’ve developed. So far we've talked about state of the product reviews, interaction outlines and flowframes (combined wireframes and interaction flows). I’m working on some other posts to fill in more detail on some of the interaction and communication strategies I use with stakeholders and developers but I couldn’t resist showing you some of the items that can be quickly generated throughout your interaction design workflow in design research, scenario planning, team buy in and even blue sky strategizing.
NON-LINEAR DESIGN THINKING
Before I drop you into interaction storyboarding, let’s take a little trip through some of the why and how I developed these offerings.
In the early 90’s I began teaching and working in multimedia. Teaching has always been the fastest and most efficient way to help me learn and organize information. It forces me to create focus, order and simplicity - to make up a structure - and then to find effective ways to communicate that to people that only “hear” information in certain ways. That in turn has been helpful for working in real world situations where a typical day has me collaborating with corporate stakeholders, engineering, user research and marketing - each with a need to quickly understand how the design works. And for me, the more ways I can look at, process and explore data the more nimble I become at coding in and designing for that system.
One of my early issues in teaching Director and then Flash was how to shift learners from linear thinking to interactive thinking. When we teach static graphic design, we’re looking at layout, clumping, white space, color - all issues we need to retain for interaction design but not our sole focus. Even when we move into 4D environments (over time) such as learning video or audio editing, we’re thinking and teaching ourselves how to create linear streams. When moving into creating software UI and/or interactive systems of any type, we need to acquire the ability to understand what static elements we need (2D or visual design), what architecture we need to support data and content flow (3D or information architecture) and how to create the behaviors that will make sense to the user so they can accomplish a task (4D or interaction design).
For 2D we have things like wireframes, storyboards and mockups that communicate and allow us to iterate the visual design. In designing the architecture we have things such as site maps, database diagramming and even code frameworks. In 4D we have scripts, flowcharts, outlines, animations and prototypes.
As I taught designers to code and coders to design it became clear that there had be better ways to communicate across those traditional divides. So I tinkered with some of my traditional documentation and came up with a way to communicate coding, layout and interaction behaviors visually, in a single document that I call an interaction storyboard.
Each interaction storyboard has a unique key that contains the symbolic language for the system that you’re working in. Early in my web career I began to use X as shorthand for behaviors that happened on click of a link and XX for double-click. It certainly sped up my teaching. Now they work just beautifully for tap and double-tap. As I moved through different systems the language can shift right along with the actions and behaviors that are unique to the system.
The first example is from a sketchbook in my web/Flash days. Notice the specifics to those systems. The second is for a Nokia touch-based mobile product. It's most useful for showing touch gestures such as tapping, holding, scrolling and flicking the page.
TELLING INTERACTION STORIES
Next is an example of a type of interaction storyboard that I used for my Flash classes called a Go To Structure that allows you to create a simple, divided timeline that the user can press buttons to access. If you spend some time with the interaction storyboard (I used it as a teaching tool) you can see the timeline at the top with indications of labels and actions that create each “virtual” section on the timeline. Then down on the “stage” you can see 3 buttons with indications of what happens on rollover and on selection of each. In this case, when you select button one it tells the playback head to jump to a frame label called “anim1” and start playing. Up on the timeline you can see the label “anim1” and the action at the end of that section that tells the playback head to stop or loop that section.
Can you see it now? Cool, huh? You just read a full interaction ”story“ that explains how to create a non-linear experience on a linear timeline. This is a pretty powerful way to teach yourself to think, see and communicate ”interactions“ to others.
I've transitioned that original language over the years to the new areas I'm designing in. Currently I find it a powerful way to communicate in touch-based systems on mobile platforms such as iOS, Nokia, Android and Windows Mobile. I’ve dropped the coding details and focus on communicating the basic flow through individual actions or agile style feature stories broken down into their component parts.
Let's look at the tap and hold symbols we saw in the key above working in storyboards for a Nokia mobile product. I used these enhanced wireframes as a part of a scenario planning cycle with the product and engineering teams. We decided on feature sets, layouts and technical details, as this was the shift of the product from key interactions to touchscreen devices. It became great shorthand for communicating the new new interaction language for both stakeholders and engineers.
CLARITY IN COMPLEX FLOWS
In this final example we moved from high fidelity mockups in an interaction storyboard format directly into an iOS prototype. Normally, I wouldn’t need to go into this much detail in my mockups and interaction storyboards for iOS design but the team was working remotely and this cleared any confusion on what we wanted to achieve. Then the discussion could move immediately into the details and the best ways to code and create infrastructure to support the feature story.
In my next post I'll show you how easy it is to move immediately into the more powerful use of this type of symbolic language by animating and prototyping touch-based gestures and activities.