Select Page

The comedian, Louis CK, has a famous routine where he talks about how quickly our amazement with technology turns to impatience – or, how quickly we take a new convenient technology for granted. In part of this routine, he speaks of a plane trip where the plane offered free WI-FI – something that was not previously available on a flight. In mid-flight, technology difficulties make it unavailable and the person next to Louis begins grumbling about how this is bullshit. He makes light of this person’s complaints by underscoring how amazing it is to be able to use the internet on a plane in the first place and how quickly we take something for granted. Time is often like this for us. What was once an acceptable wait becomes excruciating as we get used to a new level of technology.

Consider how, in our every day interactions, our expectations are shaped and the bar perpetually rises. Waiting for a computer to boot becomes comparable to your mobile experience, where the device is available in an instant. Waiting for a website to load more than a few seconds causes us to reload or navigate away from the site. DSL connections today, can sometimes seem slow when taking longer than 5 seconds to load a page whereas a decade ago this would have been a miracle when the average page load could easily exceed a minute.

But, when it comes to humans, time is quite subjective. We are notoriously inaccurate at judging wait times. Veirordt’s Law states we tend to overestimate short durations of time and underestimate longer durations. If we are that inaccurate in our judgments, then there is plenty of latitude to shape what our minds perceive. We know this because there times when time passes by quickly for us – such as when we are immersed in a task. Ever become engrossed in your phone while waiting and suddenly realize the wait is over when a horn beeps or someone says your name? Thus the question is, what states are we in when time truly flies like this? For the answer to that, we turn to Mihaly Csikszentmihalyi who has spent much of his life studying “flow” – a state where users experience a distorted sense of time and become fully immersed in their task at hand.

When users are in the midst of a consuming process and time is flying, they are in what we would consider a state of flow. It isn’t too different from being “in the zone” and you can create this at different levels. There is flow to even our most menial activities such as navigating through a software process, navigating through a building using an elevator or something as simple as me writing this post. Mihaly’s work concentrates a lot on experts who truly become consumed in their processes. But, we can use some of the same principles when it comes to interface design.

Users in systems and software have goals along with a set of actions they must complete to achieve that goal. The actions and steps taken to achieve the goal can be seen as a process in which a state of flow can be achieved. It might sound strange, but if you have ever had to navigate through a system to perform an end goal, you have probably achieved a certain state of flow (or had it interrupted if the system was not well designed). The idea is to not interrupt that flow. While it is doubtful we will create meditating monks in attempting to create a sense of flow, it is possible to provide a sense of continuity and an enjoyable flow-like experience for our users by using certain methods.

Specifically, there are three primary methods we can use to keep the user in a state of flow or bring them to that state. The first is to model the system to your user’s ability. The second is to ensure there is a clear path to the goal with clear feedback and instructions along the way. And the third is to give the users a sense of control.

Modeling the System to the User’s Ability – Steven Seow calls this “Challenge Skills Matching” and cites Csikszentmihaly’s researching illustrating how a user’s flow can be impeded by software that is too challenging (difficult) or simply too easy for their skill level. The idea with modeling a system to the user’s ability is to ensure the software meets users’ needs based on their skill level. But going a little deeper than that, we are truly concerned with the emotional state of our users as they move through the software to complete their objectives and goals. If they encounter a system that is too difficult to navigate through, the likely result is they will become stressed, anxious or worrisome. Stress, anxiety and worry all interrupt the user’s flow. But, systems that do not account for advanced users can also cause the opposite problem – boredom. Modeling the system to the user’s ability ensures optimal flow. This can equate to having robust user preferences in a system allowing settings to be modified to the user’s level of skill. Sometimes this means providing a simple path for the novice users while allowing expert users to deviate from that path. Performing the upfront research and segmenting your users is an obvious prerequisite here. But at the very least, having novice and expert modes in certain software packages is a good start.

Clear Goals & Feedback – Everyone probably remembers the old Microsoft messages that went something like: “Error (60785) process cannot be completed…” and then you would receive a cryptic reason full of jargon. These messages made absolutely no sense to anyone but a programmer. This was often the result of poor programming from an external developer not associated with Microsoft. The result was simply worry on the part of the user because most of us had no hope of understanding what that message meant or how we could resolve it. This most certainly interrupts user flow. As designers, we must be clear with system messages and prompts.

Ways to do this:

  • Use clear language for messages and prompts – language that is clear for the end-user and has been vetted of technical jargon.
  • Ensure prompt feedback. A small 3-5 second delay is often enough to prompt worry in the mind of your user.
  • Be concise. Research indicates users are prone to skim (or not read at all) long chunks of information. Edit, edit, edit.
  • Be descriptive in buttons instead of using “Ok” or “Cancel” and use language that indicates what will happen when that button is clicked.

The less the user has to pause as they navigate through your interface, the greater sense of flow they will achieve. This will equates to a shorter perceived time in task completion.

Give Users a Sense of Control – A few weeks ago, I wrote an article about ethics in UX and placebo buttons. One example I used was the elevator close door button, which is rumored to be inactive in most elevators. The thought behind a placebo button is that it gives the user a sense of control over their situation and thus placates them. Another example I provided was of the fake thermostat placed in an office building. The complaining office worker who used the thermostat ceased complaining as soon as it was installed and they were able to use it despite the thermostat doing absolutely nothing to adjust office temperatures.

In your system, users should have a sense of control to “control” their worries and anxiety. What does this equate to? Building undo functionality into systems, robust help features, back buttons and as Steven Seow termed it, “escape hatches.” I really like that because that’s what we want as users – an escape hatch with a lever we can pull in case of an emergency. There is nothing more frustrating than hitting a button that permanently changes your course and not being able to “undo.” If users are not busy worrying about making a mistake they cannot undo, they will move more freely through the system. Consider the points where you have paused in systems because you weren’t sure which button to click or if clicking one of them would be a catastrophic error. Permission to err induces flow.

Following these three principles will take you a long way in creating a smooth and flow-like experience for your user in any interface you design. And that smoothness or flow will result in a decreased sense of perceived time spent using the software. In addition, I would highly recommend reading chapter 8 of Steven Seow’s book, Designing and Engineering Time: The Psychology of Time Perception in Software. It is a fantastic book with a plethora of information and guidelines for engineering interfaces with the user’s perception of time in mind.