Daily Prototyping

A few months back I had the opportunity to hear Tom Chi of Google X design speak. I was deeply inspired by his idea of doing to learn rather than talking and brainstorming. Feeling uninspired and rather lost in my own process and career I decided to perform an experiment of my own - by implementing a practice of daily prototyping. Could I prototype my way into relearning to prototype - or more to the point - back to creating and physically building to learn?

Complex Visual Storytelling
In 2011 I began creating a series of case study PDFs that allowed me to tell a story of my work with an individual client. After prototyping for many months - I'd finally created 3 solid stories that showed my work across a broad generalist skillset and most importantly to me - showed that I worked in physical products, software and cross platform implementations.

Now I was ready to start telling more stories of process and ways that I want to work across my skills and beyond. To do that - I needed a stronger design - visually and informationally.

With that in mind, and to avoid the "planning as doing" habit I've been reinforcing in my daily life the past few years, I dove into a project to prototype the presentation of my portfolio in static form.

I had some basic guidelines:

1. Present a wide variety of information - photos, outlines, wireframes
2. Create a visual language (color, style and organizational graphic elements) that lets me communicate process and complexity
3. Keep evolving my quietAction branding and also bring my name higher up into the communication structure

Since I don't do visual design day-to-day an additional quest was to wake up my skills and explore some different styles of design. This required some time looking at different inspirations I'd been collecting over the past year. I quickly realized that the first part of this prototyping push was to prep materials for my prototyping. So I collected links from portfolios, sites and apps that had visual, information or styles that I found appealing. I also collected text, screenshots and vector art for some basic elements that I could throw into the prototypes.

DAY 1

I began with the brand and visual design from my case study PDFs and attempted to start iterating in new directions.

I was really rusty when I started so I began by trying match some of my inspirational designs. Could I make it dimensional? Could I flatten it out? Could I go for full whitespace design?

What happens when I add increasingly complex information? How can I show the breakout of one part of a product flow so it's clear what is being shown? How about an outline with wireframes? Could my basic architecture and visual hierarchy hold up?

While I was pleased with the informational communication of the day's prototypes, I was left with an overall dissatisfaction with how "stick-ish" it all was. I found the flat, outline quality of all of the elements - text, brand and information - didn't allow any of them to shine. It ended up looking just as complex as it was.

DAY 2

The next day I took this underlying dissatisfaction into the process and continued to attempt to organize the information and iterate on layout and adding more whitespace.

Discriminate and reset
Eventually, it was clear I was rearranging deck chairs (i.e. on the Titanic) and I stopped to chat with my brilliant design friend, Cliff Jew. Over the years I've come to value Cliff's ability to talk through design issues with me and to help me see what I'm missing so I can keep iterating in a new direction. This process of "discriminating" is critical in a prototyping process. You have to know when you've stopped heading in a direction that is fruitful - reset - and then be able to move nimbly in a different direction.

When I explained my irritation with so many flat elements on the page hindering my ability to distinguish between levels of information or even visual flow around a page - Cliff immediately jumped to the idea of "traveling through" the information rather than simply laying it out to be read. Traveling and storytelling both have a time component. What could I add to the visual design that allowed us to make the information special and also allow us to move through it in an organized way. Cliff remembered an old project he designed that used 2.5d graphics to lead a person through a setup of a physical product. By adding a spatial component he was able to separate out textual and design elements from the most important data.

Taking a one of my designs he quickly overlaid a couple of examples of dimensional objects into the page to see if they would fight. Rather than fighting, the additional of a spatial quality to the data made it into a "secret garden" that a person could engage with separately from the text and brand container.

After I got off the phone with Cliff, several things started to happen. I let go of my original brand container and moved toward a stronger whitespace design that focused on my name and that this is my experience exploration (portfolio). I learned how to orient my vectors spatially in Illustrator (be very, very frightened :D). I suddenly got much braver. You can even see the happy accident moment - "Look what happens when I go FULL whitespace" in my Evernote documentation.

DAY 3

2 days later I finally got back to this project and was very pleased with where I had landed. I decided to try laying in some of the material that I had from my case studies to see how things held together when I added even more complexity. I think it turned out pretty well with a lot of room for improvement and continued prototyping. And it's a huge leap from where I started. Definitely well worth the time and effort.

THE REAL LEARNING

So, in this 3-day sprint I learned quite a few things.

1. It's good to have some prep time to gather some base materials to prototype with. While it's cool to have placeholders, it's tough to keep a flow going if you don't have any raw materials handy.
2. Discriminate. Know when you've run into a wall. Phone a friend or simply leave that direction alone and try and jump to something completely different.
3. Keep yourself moving and be brave.

Self-documenting storytelling
One of the principles of Lean UX is that you want to engage in process that is self-documenting. In this case, I quickly created screenshots, threw them into Evernote and added some discussion of how the day went. Because I did this each time I took a break - the result was that I had a living document that helped me tell a story far more powerfully than any single static document could ever achieve. I consider this one more portfolio prototype in these days because it - more than the static elements - will become my FUTURE story.

I can't encourage you enough to begin incorporate this hands-on style of moving through so many of your life challenges. For me there is very little that you can't apply this to in my life. Stay tuned as I'll share some other prototyping I'm doing as I get further along in the process.

ux toolbox: flowframes

Flowcharts and wireframes - not exactly the sexiest tools in our kit, are they?

Well most people don't think so, but I have a special affection for them ever since one of my early projects at (Collosal) Pictures required me to create an 18-page flowchart for a project. A Freehand addict, I won points for being able to make a multi-page doc but also for sheer stubbornness in simplifying the system. For me there is very little in my work as satisfying as communicating complexity via symbolic systems that you create from scratch.

Flowcharts have definitely been falling out of fashion in the tech world the past few years. Not only do I see them less and less often on projects, fewer people can actually read them. I ended up putting an audio recording with my flows as a last resort on a project that relied on them to communicate critical decision points for a product. The team and stakeholders were surprised but ended up carrying on the tradition in future projects as they realized that flows and wireframes really are rocking shorthand for communicating architecture and technical details.

Building on interaction outlines from my last post, flowcharts are really great for laying out an overview of a project or potential exploring decision trees within the details of a project. I should point out I don't consider flowcharts a good way to describe user decisions. I find most of the experiences I design these days are about making some good guesses at where to start with people interacting with you. This has made it less productive for my purposes to be able to create airtight user flows in the traditional form. I think visual flows are better for working out what paths you're providing, not necessarily what will actually happen.

Over the years one of my favorite hybrids has become combining flowcharts and wireframes - or "flowframes" as I've dubbed them.

Examples
Let's start a bit traditionally. Here's a flowchart for a fairly old, full mobile OS system I developed a few years back. It's based on a very extensive interactive outline - showing only the top-level items in the system - visually.

It's pretty easy to figure out what the system involves. And nothing you haven't seen before. It doesn't become really powerful until you see the key for the system and begin to understand the depth of what can be communicated via these little tools.

This is a really elaborate example for a huge system but I think it illustrates how powerful custom documentation can become for communicating details of technical design. For instance, the engineer could immediately know that we needed to create a new movie clip for this section or that we needed to make an object that could be accessed at any time from the system for our asynchronous components.

Next we move into the areas that flowcharts, wireframes and interaction outlines begin to meet. As I dive deeper into each layer of info and design on the phone top there's a corresponding wireframe that uses some of the symbols from the key. Then I deconstruct each interactive element on that screen even further.

Animations, button interactions, types of components, key interactions - it's a little nutty how much info is stuffed onto this screen. See how parts of the interaction outline sneak into the detail breakouts to help cement what is being discussed.

And, just because it was the most fun to create and the most intricate use case - dealing with multiple calls - you can see that now we're dealing with the flow and wireframes to communicate both the 2- and 4-D aspects of the design. I love this stuff.

Production
How do I create this style of documentation? For many years I used Freehand as it was the perfect mix of illustration tools and layout features. Now I'm appreciative to have Illustrator allowing me to use multiple pages in a single doc. For me it's critical to be able to create symbols (reusable elements) for my projects. it makes it faster for prototyping and allows me change once across the system speeding things up as I begin to skin and model the prototype. Eventually, I'd like to see a Freehand features such as the ability to make templated pages return - but I suspect I'll have to turn to a tool like Keynote for features like that.

I've tried a ton of other tools including Omnigraffle, Fireworks, etc. but I always come back to the tool where I can quickly collect pixel, vector and custom symbols into a mashup that also has the ability to move beyond a single page analogy easily.

Documentation, design or process?
So what am I trying to show here? As we get less and less time to create documentation, how on earth could something like this be relevant? Good question. I'm not sure what the answer is, beyond the fact that this set of documentation was a part of an iterative build process and communicated a pretty powerful level of detail that and allowed a large team of engineers to divvy up the work and conquer it much more quickly than if we hadn't done a more comprehensive design process.

And as with much of my process, I retain these old-school concepts because they allow me to keep working with large sets of data in different ways. The more ways I can express a system - the easier it is to communicate, build and ultimately to iterate. If you understand a system this deeply, just imagine how much faster you can evaluate whether new features, shifts or removal of features will affect it?

Currently, I still use flows as I design large or multi-modal systems...but they rarely leave the whiteboard and sketchpads or go beyond being used as reminders of what flows and details we're after as we build at high speed. Pictures of whiteboards have become my world of linked together collaborative self-documentation. I'm happy to move beyond documentation as the goal and instead make the creation of the product the goal.

That doesn't mean scribbling out a good flows and spending some time working details in wireframe mode does anything but help your project. And isn't that the purpose of all self-documenting process - to move the design and creation forward or to rule out the features and possibilities that are not currently viable.

This was my 1 sketch for 1 ride day...and yes, that is a flowframe sketch.

ux toolbox: interaction outlines

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.

Examples

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.

Testing applications
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.

percolating

I’ve been doing an experiment for the last 6 days. I had this great idea that as a lead up to UX Week and a refocus on my business that I would do 30 posts in 30 days. It's been interesting to say the least as new projects popped up and I attempt to write, research and dev for some of the more technical and intricate posts.

And now, I'm choosing to end that experiment mid-stream, as I realized today that my goal is not to produce a lot of work, but rather to produce good quality that communicates and creates opportunities for conversation and connection.

While getting stuff up each day is a powerful lesson in discipline, it did not allow me the time and wandering that feels to me like the best of what I have to offer. I’ll definitely continue posting more regularly though, as all of this writing certainly does shake out the cobwebs.

If there’s one thing I’ve learned about myself it’s that I’m a percolator. I love getting massive data downloads that projects require and then getting a bit of time to digest, work and wander through the information. I read, sketch, have imaginary and in-person conversations with stakeholders, review notes, read requirements docs, talk to engineers, look at competitors, user feedback and marketing materials and then do random searches around the edges of the topic.

And then I put it away. I walk, read, nap, catch up on TV shows, and I work on moving other projects. I make sure to have a pad of paper and the key materials around me at all times. And the ideas and organization start to flow out of me. Sometimes this is a few hours, but on bigger projects this can go in cycles of input, hold, design and iterate for weeks.

When I’m working intensively I often wake up in the morning with solutions. My subconscious continues bubbling and the early morning is often the easiest delivery point in my day. Exercise invariably helps me slip completely out of problem solving and into that lovely abstract space of percolating. I also use music of various flavors to help me move into these states where my mind seems to effortlessly organize and show me options.

I often do freeform writing – longhand and on the computer – to help me keep the stream moving. Worry and fears are the showstoppers for percolation and as Julia Cameron calls it, "running to the page" is the easiest way I’ve found to get myself back into the flow. Cooking, cleaning and painting are all also soothing and helpful ways to keep me in sync.

Of course if it get’s really extreme and I’m too agitated to focus or relax into the work, I’m not adverse to a UX dance party. That works every time.

I also notice that I’m incredibly cranky and touchy during the start time when I don’t know how it all fits together. But I’ll leave that for another post on dealing with the unknown.

Thanks to all who have been reading and chatting with me about these posts. I really appreciate all the support and interaction. That really is what it’s all about for me.