All points in a flow where not created equal

Jesse James Garrett's Visual Vocabulary is an excellent resource for creating flow charts. There are of cause also other diagramming conventions such as UML and Entity Relation diagrams, but I often use JJG's for my flow charts.

One thing that many vocabularies lack is a way to specify that some parts of a flow are more important then other parts. We need to focus our design efforts on the parts that add most value and we therefore need to be able to communicate the relative importance of different flows and even of different points in each flow.

The need to represent different importance in flows became apparent to me after a recent discussion with a client. The client is creating a system where customers of physical retail stores can go online to get access to services that enhance the shopping experience. I.E. they are enhancing physical retail by creating valuable online services.

The client of cause have a lot of flows that need to be outlined — for example finding and choosing which services to use, setting up services and daily use flows — but one of the most important ones is the flow that starts in the store with the customer getting info about the service. That flow, the discovery and sign up flow, will be the single most important one for the customer's first year.

When I lay out the different flows I do of cause only add as much detail as is necessary to the charts, which is something JJG clearly states as a necessity in his vocabulary description. So, already in the vocabulary there is a provision about only including what is important. However, the flows also need to be complete — that point A of a flow is less important then point B might not mean that point A does not need to be included in the graph.

My solution to the issue is to use color to depict differences in importance. Color after all has an innate ability to communicate importance — orange is generally more visible then light blue. In order to capture the power of color without over loading the graph, i often use hues. darker hues mean higher importance. Which color I use depends on my mood as well as the client's graphical identity.

Some examples:
The flow on the right is a standard Visual Vocabulary flow, on the left I have indicated that point B is the most important one in the flow, with C being slightly less important and A & D least important.

Here I have indicated that the choice of B or C is the most important part, with B being the preferred choice (preferred by a combination of the customer and my client). The graph could for example represent the decision of whether to pay by Credit Card or via PayPal, with Credit Card being the preferred choice.

The careful addition of color to flow charts to depict importance can enhance the communicative ability of the chart.

Thoughts on IxD process

The Goal
In a video that introduce the acquisition of Zappos by Amazon, Jeff Bezos outlines his view of what is important. First on his three point list is "Obsess over customers" and thereafter "Invent on behalf of your customners" and "Think long term".

In "You Can't Innovate Like Apple" Alain Breillatt discusses the focus Apple puts on knowing their market and having leaders who obsess over all fasetts of design.

Epic
In the excellent HFI white paper "The Evolving Institutionalization of Usability: User Experience as Strategy" Eric Schaffer outline a process for making usability equally important to a companys operations as HR, manufacturing and similar business areas. The process involves having a CXO (Chief eXperience Officer) who is in charge of creating, implementing and maintaining a user experience strategy for the company in question. The strategy outlines such things as staffing, training and knowledge sharing. The process is truly epic.

Lean
Most of my clients come to me asking for usability work leadership. However, they are not of the size needed for Schaffer's process to be practical. I need a process that:

• Is small and efficient (resources are never abundant)
• Is modular (some pieces may already have been done by he client, others may not be prioritized at the moment)
• Can solve a large range of problems (since all my clients have different kinds of problems)
• Will create reusable design artifacts (so the client can do some future work themselves)
  

Adaptive Path are my experience / interaction design idols. The guys and gals there create wonderful experiences for a wide range of clients. Their solutions always seem simple, but are of cause very "designed". Also their process, as examplified in a recent article about a bike shop design, is deceivingly simple. However, to me it is close to perfection:

1. Understand the client — products, goals, market as well as the problem they want solved
2. Understand the client's customers and users
3. Clearly articulate the client's central process(-es) from a user perspective
4. Create concepts
   
5. Prototype and create reusable deliverables — material and immaterial — together with the client
   
6. Don't be afraid to iterate within, and jump between, stages of the process (for example by testing prototypes on customers)
   

Variations
The process outlined above is the one I currently base my work on. Each project has it's own characteristics and goals, but with these five activities I can help my clients obsess over customers and create products and services that both delight and help customers reach their goals.