The Role of Flow in Web Design

  • Article

 

Scott Berkun
Microsoft Corporation

January/February 2001

Summary: Discusses the concept of flow and how it applies to good Web design. (3 printed pages)

When things are going well in life, you move through processes without thinking about them. At the point at which you master a skill and can do it without thinking, you are able to use your mind for more advanced kinds of activities. Learning to type, or to drive a car, takes time, but once you obtain the skill you are free to pursue the high-level goals of writing an essay or driving to the beach. In designing Web pages, or anything that people interact with, a prime goal must be the achievement of flow for the user: Enable them to transcend the mechanics of links and navigation, and focus completely on what they want to achieve.

The notion of flow, or optimal experience, is described in eloquent detail in Mihaly Csikszentmihalyi's book Flow. The experience of flow is most pronounced in creative activities, like writing code or participating in sports, but in a much smaller sense, flow is achievable in almost anything. In a more abstract and functional definition than Mihaly's, I think of flow in a design as the movement of a person from their desire to their satisfaction, in as natural and easy a way as possible. A good developer, designer, or creator of anything strives to allow users to experience this kind of flow.

The irony of flow in design is that when it is achieved, the design itself often goes unnoticed. Paper clips, suspension bridges, and the computer mouse are all great designs, but are noticed by most only when they fail. This traps the egos of many developers and designers, who might feel frustrated by the lack of recognition for their brilliance. Sometimes you'll see a software product or Web site that goes out of its way to make you aware of what the designer has done for you, or what they think about the world, but this is rarely of benefit to the user. True design includes personal restraint to avoid tainting user flow with designer or developer ego. In most cases, if the user noticed something, or had cause to forget their desire and think about the mechanics, you've blown it already. It's a poor tool that places itself before its purpose.

To achieve flow, you have to invest from the first day of your project. Every page and every element of your site has to be created with the user's perspective at the core of your thinking. The easiest way to achieve this is through asking questions of your sketches and designs as you create them, before you bring them into the usability lab. Use these questions as seeds of discussion for brainstorming, and for comparing and generating alternative ideas. There are two kinds of questions about flow: What is the site structure and what is the task your user is trying to achieve?

Flow in Site Structure

When considering designs for an entire Web site, or just key elements like the home page and navigation systems, you must have knowledge about the common activities your users need to do. You can probe for your high-level flow by considering the follow questions in evaluating your designs:

  • Why are users coming to your site? What needs or desires do they have?
  • How will you ensure that those desires or needs are satisfied?
  • What supported assumptions can you make about your users and their skills?
  • What are the five or ten most important tasks or actions users need to complete?
  • Are these five or ten actions the clearest and simplest for users to access? (And complete?)
  • How can users navigate between related areas of your site?

In answering these questions, you'll be forced to make choices about how things are presented, including demoting certain things and emphasizing others. This is the heart of design: making trade-offs around a set of constraints. You can't possibly achieve flow if common activities are as difficult for users to pursue as things they never need. Flow requires focus on the part of the designer.

Flow in Tasks

Once your users are in the right place to do what they want, flow comes into play as an attribute of how much work they need to do to satisfy their goal. Imagine being in a rental car and not being able to figure out where to put the key to start the engine. You'd know you were in the right place for your task, but you'd be frustrated as to how to go about completing it. Your questions would not be about location, but about the steps you need to follow to start the car and drive to the beach. For each task, you can examine the task-level flow by considering the following:

  • Where does the user start this particular task?
  • How do they get from one step within the task to another?
  • What happens if they get lost along the way or make a mistake?
  • How will they know when they are done?
  • What common mistakes are they likely to make? How are these prevented or handled?
  • How does the layout or organization of the page make the answers to these questions as self-evident as possible for users?

Flow Deferred

Learning Microsoft® Visual Studio® takes time, as does learning to drive a car, or typing at a keyboard. The design trade-off in these examples is the time investment required versus the long-term payoff for making it. You could make a simpler automobile interface, with one push button for turning left and one for turning right, but it would not provide the level of sophistication needed in order for a driver to successfully navigate the road.So, in some cases it is acceptable to deliberately delay the point at which users can achieve flow through your design. However, this should only be done with real data and deep consideration about the people you are designing for. Is the investment justified? Do they need that much sophistication? In most cases, developers and designers overestimate the complexity of what people need. When in doubt, strive for simplicity. Only make things complex and involved if you have evidence that it's the right trade-off.

On the Web, creating learning curves is particularly unreasonable. Users spend most of their time on other Web sites, and the return on investment they would receive for the learning curve required on your site is very low. This is why inventing new kinds of navigation structures or using nonstandard conventions hurts users so much.

Notable exceptions justifying additional learning curves include Web applications like Hotmail or online banking, where there is manipulation and storage of data. Because the user needs in these domains are more sophisticated, it follows that the tool to satisfy these needs might need to be more elaborate. They should still be as simple as possible, but are likely to be more complex than your average read-only news Web site.

However, even in cases where a high learning curve is warranted, flow still applies. Training users and helping them through the learning process is actually just a different set of user tasks. You can use the same principles and design approaches for helping users move through the learning process as you do for designing the Web site itself. Avoid the trap of relying on cop-outs, such as "once they learn it, they'll like it." You want to strive for making them enjoy using your design even while they're learning it.

Measuring and Using Flow

For most of the questions I've discussed in this column, there are well-established usability engineering techniques that can provide answers. Cognitive walk-throughs and heuristic evaluations are low-cost ways to see how the parts of your Web site fit together from the user's perspective and will give you a sense of how things flow. Usability studies can be designed to examine these aspects of a design, and provide data about where your current designs fail or succeed. Minimally, you can set goals for your project around these questions, comparing this month's designs to last month's, or your Web site against a competitor's. This won't measure your user's internal sense of flow, which is subjective and difficult to capture, but it does give you an approximation that can be measured, compared, and used to make effective decisions.

References

For information on usability techniques, particularly study design, see Jakob Nielsen's Usability Engineering. To learn about the interesting research on understanding and creating flow in general, see Flow, by Mihaly Csikszentmihalyi.

Column Information

Old columns and UI resources are on the Web at https://msdn.microsoft.com/ui/. Anyone can subscribe via e-mail, at hfactor-subscribe@topica.com. If you want me to speak at a conference or event, send me e-mail at hfactor@microsoft.com.