This form does not yet contain any fields.
    « ux details: co-designing database interactions | Main | ux toolbox: interaction outlines »

    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.

    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.

    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.

    Reader Comments

    There are no comments for this journal entry. To create a new comment, use the form below.

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    All HTML will be escaped. Hyperlinks will be created for URLs automatically.