Humans have a unique ability to adapt and our tolerance threshold is directionality proportional to this. You get a new job with a higher salary. A year later, the salary doesn’t seem like enough any longer. You move closer to your job to reduce your commute time. A few months later, you are complaining about how long it took you to get to work that morning. The wait at your local fast food restaurant is intolerable. Lest ye forget: We used to have to cook our own food and, at one point in our history, this involved hunting our prey.
Consider this same concept in our every day interactions. Our expectations are constantly 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. Internet 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. We have adapted and our tolerance threshold has been shaped through this adaptation.
I am most interested in time in relation to our adapting tolerance thresholds. And, 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. You can design for flow.
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, as a designer, 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 employing 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 research 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 place start.
Clear Goals & Feedback — Clear goals in a software system ensure the user knows exactly what they need to achieve (or do) and how they can go about doing what they need to do. When it is not clear to the user how they can achieve a given task or goal, it will most certainly interrupt their flow. Developing sound information architecture in a given system is essential to ensuring goals are clear to the user. Do they know what they need to do and how to do it? Or are common functions buried in nested menus?
In terms of clear goals, think of software as nothing more than a wrench, screwdriver or any other common tool. People use software as a tool to perform goals and tasks. When we design barriers into a system that impede the user from completing those goals or tasks, we interrupt their flow. Interrupted flow results in an increased perception of the duration of time.
Feedback is also important. 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. So, in terms of those long pop-up messages: 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 and deliberate 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 — Some time 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” the action. 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.