I started last week with one of the surveys that I do at the beginning of the project. For the next few days I'd like to climb into some of the more hands on process and documents that I use in my work.
Outlines are intriguing creatures. And while I've outlined plenty of my film and writing projects and even some of my large web projects, I didn't become a huge fan of working with them in my interaction and UI design work until I began working on large mobile systems. And mobile systems that were intertwined with web systems. And...
That combined with the fact that my design thinking has been moving from visual to written for the past few years make this type of play incredibly valuable for creating more usable experiences.
So, what's unique about an interaction outline? For me, it's the fact that I'm putting down every single interactive element on the page and then playing out states and flows via my outline.
I tend to use this type of documentation as I'm designing and working directly with engineers. This is not my stakeholder communication typically - I'll get to that in another post. I pair these outlines with flowcharts, wireframes and eventually with low and high fidelity mockups.
The example above shows some of the notes I had for my iPhone developer - a particular button state, keyboard, behavior and then the resulting messaging and behavior for success and failure. This really speeds things up when I can get to that level of detail.
It also provides a space for me to ask questions like: "What is the best way to do this?" and "This is the behavior I've seen before, how difficult would it be to get ours to work that way." For me, this is critical in the type of collaborative development I like to do as an interaction designer or technical UI designer working with engineers and developers.
The additional information I add to these outlines is tuned to the audience. Visual designers have really detailed design, color and font notes. For mobile developers I might list all of the components needed for a template and have notes about customizations needed from standard components. Really, the success of this kind of documentation is to have it help you continue designing and not simply be an exercise in recording everything.
Complex web applications
Another great use for this kind of outlining is when you're working with deeply nested interactivity on a page. This is particularly critical if you're attempting to work around technological limitations that will not be resolved in your current revision. This is an example from within a very intense and tightly designed field entry. The level of complexity required to get around the technical limitations of the system made it very difficult to create a desirable user experience. At a minimum, we did manage to clear the visual barriers and make it more responsive and friendly through our UX work on the system.
The nicest part about having this level of detail was that we were able to develop our A/B and QA tests in direct alignment with the intended behaviors. We even used these to create our test plans for user research. All of the QA engineers and user researchers always want me on their projects ;-).
Lean and agile?
How does documentation like this play out in lean and agile environments? Currently it depends on how much bandwidth I have personally. For me, this is really helpful to making sure I really am covering all my bases in my interaction design. It helps me think and design the system details after I've taken my high level "experience" passes. It's so easy to forget or simply run out of time to cover messaging and testing details when you're in a fast moving environment.
This style of outline also let's me review at high speed and make sure I can bring up any potential blocks - so we can consciously choose what direction we want to take, even if it's only that we are unable to deal with it at this time. I note these in my documentation by keeping all open issues highlighted. This makes it easy to find and review in scrums and review meetings for the product.
I haven't done a formal evaluation of the success of resolving the issues when I use this type of communication, but my experience is that it seems to increase the potential that the deal breakers tend to get broken down into smaller pieces and conquered within future cycles.
So, is this something I do with every project? No. But for anything that requires me to keep track of a lot of interaction details, it is one of the pieces of process that I reach for to keep things even and on track.
What kind of process and written materials do you use to keep track of complexity in your projects? I know a lot of folks use spreadsheets. For me an outline just makes more sense and is more adaptable but that's the wonderful thing about interaction design and UX...it's a big world out there with a whole lotta snowflakes :D.