By Scott Berkun, May 2001

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 websites,  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 design 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 designing 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 assumptions can you make about your users and their skills?
• What are the 5 or 10 most important commands or tasks users need to complete?
• Are these 5 or 10 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 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 to drive a car or type on a keyboard takes time. The 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 learning curves are particularly unreasonable. Users spend most of their time on other websites, 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 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.

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

[edited 9-8-15]