Sites and products are rarely designed nor behave in a linear fashion anymore. Save for the popular long page format. There's no way to capture the dynamic nature of use cases with a static site map. Why create a typical tree of pages connected in a deceivingly orderly fashion, that when all the real connectivity between screens as added, would be an unreadable game of Pick-Up Sticks?
Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional metadata about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site. [sitemaps.org]
This definition mentions nothing of a site map's usefulness beyond search engines. In current web development processes, the utility of a site map has been stretched beyond its intended purpose:
- to communicate general site structure and information architecture to the site builders based on practical principles
- to help search engines index a site for discovery
- to instill a sense of logical structure and information hierarchy to aid usability
What if site maps evolved into a new framework to help both builders and users? To inform practicality and boost usability?
A Small Step
Early iterations of this evolution were designed to illustrate somewhat linear steps in a process. Steps like selecting a t-shirt, then color, then size, then quantity, then customizing the graphic just didn't translate well on a static screen. Adding each step in a series of actions and states within that process helped. In typical Western fashion, reading from left to right and top to bottom alludes to order of importance and step of succession.
This experiment proved useful when describing how a user actually uses and navigates through a site. Only marginally better than a standard site map, this framework failed to address decisions (and distractions) along the path of a use case.
Dissecting the New Model
Flow maps read from left to right and top to bottom. The tree structure has given way to the favorite palette of interaction designers - boxes and arrows. Each use case gets its own map rather than adding branches to a one-size-fits-all tree. Colored arrows indicate the hero path - the quickest way to achieve success for a particular use case. Grey arrows indicate secondary paths - a successfully way to complete a use case with some deviation from the tightest line.
All flows and use cases begin with an impetus - a reason to act. Sure, a user may want to adjust their email notification settings, but does this thought originate on the home page or in the inbox after receiving yet another activity feed email notification? This impetus will also drive a user's intent (hero flow) and possible points of departure (secondary flow) when trying to fulfill this goal. Each major step in this process is notated as a stage on the map where users typically enter at the top of the column and proceed down until a user executes an action to proceed to the next step.
All flows end with a viral loop. With 8 ways to architect virality, there are no exceptions. If a user signs up to receive a case study, what happens after they download the case study? Nothing? A confirmation page? Hello missed opportunity. For example, provide links to other relevant thought leadership artifacts since that was the user's original intent - to gather information. Present related case studies, white papers and blog posts to keep the user engaged. Don't make users search, provide an invitation to continue.
DIY Flow Maps
This document was created in Adobe Illustrator, can be recreated using anything from excel to post it notes.
1. Create Clearly Defined Use Cases. Begin with a reason for starting the use case. Call it demand generation or impetus or a reason to go on. Consider how the next series of steps are affected and depend upon the source of intent. Trigger events and vehicles include email, organic search, the first of the month, a fraud alert, etc.
Breakdown each process into specific steps. Some steps are gates that can impede progress and others are pass-through checkpoints. Know the difference and importance of each.
2. Crate the Hero Path. What are the least amount of actions required to achieve success? Add each general step as a column title. Notate each screen state or action below as a required screen. The grey background indicates the hero flow.
3. Create the Secondary Path(s). Most use cases contain the minimum number of steps required to achieve success. Congratulations, you created a unicorn. It's unfortunate that most users interact with sites in ways that are neither expert nor efficient. Instead of blaming the designer, the product manager or (gasp) the user, plan for points of deviation while keeping the user on track.
If a user wishes to update email notification settings, they could dive into settings, then click the notification settings tab, then the email tab and so one. Maybe this task is a highly requested action buried in hierarchal structure. Maybe this unique task is duplicated to live outside of the bowels of notification settings and residing atop the main user settings. Maybe a user gets confused and must hunt for the "correct" location to finish their quest. Maybe they adjust their SMS settings along the way. Just don't penalize them with a change confirmation and kick them out to the top level. Remember: the user is not like you. Plan for that behavior with open eyes and without judgement.
4. Add Points of Deviation. As a user, contextually relevant actions are expected to be available when navigating certain pages. Changing avatars and email addresses exist in the settings, not at login.
As a designer, contextually relevant actions would be built when constructing certain pages. When building a site, use cases and best practices dictate specific actions and processes to be available throughout the site. It's the designer's responsibility to add contextually relevant points of departure on each screen. (How these actions are successfully visualized via visual and interaction design is a different topic.)
5. Build It. Product managers can audit the user experience from two simultaneous vantage points up high (steps to accomplish hero flows) and down in the trenches (points of deviation to accomplish secondary flows or abandonment).
As screens graduate from sketches to wireframes (Always sketch first!), a designer uses the Flow Map to understand what links and actions are available each step of the way. This initial audit helps get the right things on a page first as ingredients meld into the right blend of structure and output.
Developers understand how static site maps and screens are linked together while looking for red flags that break the data model. Corroborating use cases with technical stories is a good thing, right?
Why It Works
Flow maps bridge the gap between site maps, use cases and what's actually getting built.
- User flows are defined with source intent, ultimate success and viral loops clearly defined.
- Screens are listed and referenced with a unified screen name/number that informs wireframe and final pixel creation. Developers can see how screens are connected from the user experience perspective rather than an incomplete story derived from static site maps or (hopefully) well-documented wireframes.
- Points of deviation via screens state changes or links to additional screens are noted and architected for a directed user path. Designers know what components to organize on a screen to optimize for user flows and customer experience much sooner in the iteration cycle.
- From an agile perspective, designers and developers can hone targeted flows in a sprint. Break down larger problems into bite size chunks. Design, build, test, repeat.
- As functionality and screens get cut from MVP, MDP or the next build, the border of those screens changes from blue to grey (built vs. not built). This also helps clients understand the product roadmap and where subsequent capabilities get altered into the current product.
Admittedly so, first look at this document can be daunting. Client response has ranged from "I don't get it" to "This saves so much time." Past experience has proven that clear positioning and understanding of the document's goal can mitigate the negative reservations. Lack of attention to flows through the product experience typically earns the designer extra fire drill revisions as a bonus prize in later project stages - generally not fun.
Geeking out over user flows isn't exciting to most people. In fact, it can be m-i-n-d-n-u-m-b-i-n-g. Any tool that requires a lengthy explanation is likely over-designed. Understood. Clients of various technical and procedural stripes almost always require a tailored explanation putting the definition, utility and benefits in reframed terms. As a designer, this task should already be a solid skill in your toolbox.
Linear products and sites are a rare, nearly extinct species outside of the long page. Understanding the uses and limitations of static tools leaves from for new dynamic representations that benefit more than one party in a single stage. The flow map tool is in constant beta and its utility slightly tweaks with every new product and/or client. Product maps and demand funnel maps feel different but ultimately work using the same framework. That bridge in itself is already a success, but feedback is always welcome.
The flow map was conceived, designed and refined in conjunction with real clients at my current workplace.