The Psychology of Time Perception in Software: Expressing Time in Your UI
- The Timing of Time: Past, Present, Future
- Talking Time
- Couple of Whiles
- Time Grammar and Etiquette
- Summary
- Rabbit Hole
This chapter is from the book
This chapter is from the book
This chapter is from the book
In many instances, especially in progress indications, you need to communicate to your user some aspect of time, such as remaining time or estimated completion time. Although it may seem trivial and superficial, how you express time in the user interface (UI) can determine how your user experiences and perceives your solution. Simple words—for good or bad—can alter perception and affect tolerance. This chapter discusses when and how you should express time in the UI of your solution and introduces the use of time anchors.
The Timing of Time: Past, Present, Future
Besides what you express (phrases, time units, etc.) and how you express it (text, graphical, etc.), you also need to consider when you provide timing information to your user. For example, telling a person who is about to stand in line how long it will take to get to the front of the line has a different effect and serves a different purpose than informing the person who is already standing halfway in the line. Simply put, when you release information can make or break an experience. We all have our share of horror stories of how the mistiming of some information, sometimes by a matter of mere seconds, changed the course of events.
Users will use any information revealed by the UI—by design or otherwise—to form a perception of an interaction or process. This shouldn't be a surprise because we all do something similar every day. We make predictions based on patterns we see (long lines equal long wait), evaluate the quality of things based on signs and symptoms (blemishes equal carelessness), and form theories about why things happen the way they did (broken because of poor-quality parts). Likewise, users will use any timing information to help them understand and decide how they feel about and respond to the duration of an interaction.
Consider the following questions:
- How long will this take?
- How much longer will this take?
- How much time did that take?
Each of these three questions relates to a different temporal perspective; that is, where you are in temporal relation to some event. We can perceive durations from three basic temporal perspectives. First, we can anticipate, set expectations, or predict the duration of an event before it begins. Because the event has not happened, we'll describe this as prospective. In the UI, informing users how long a download will take, for example, is giving users a prospective estimate of the duration of the download. Second, we assess the duration of an event in real time while it is transpiring. A great example is reporting remaining time as the download is progressing. Finally, we can also evaluate the duration after event has transpired. We describe this last one as retrospective. Telling users how much time the download took after it has completed is an example. As mentioned, when you provide information about the duration of some event can influence user perception and shape user experience. Let's take a closer look at each of the perspectives.
Prospective: Tickle-Me-Elmo
It is not immediately intuitive that perception can be established, let alone be affected, before the actual experience. The key factor in prospective assessments is that a certain degree of judgment may have already been passed before the actual experience. If the judgment is negative, people can be hesitant in proceeding because they are, in essence, predicting that the experience will not match up or meet up to their expectation. An inordinate number of factors can go into forming or influencing the perception of a solution. In the retail industry, it is commonly known that people choose not to buy, use, or even try a specific solution based on its association, reputation, brand, or even price (not necessarily too expensive, but also too cheap!). On the flip-side, for the same reasons, people will go through hell and high water to get their hands on a product. In 1996, for instance, marketing hype and demand for the then-new Tickle-Me-Elmo dolls fueled fights among Christmas shoppers, some of whom reportedly paid upward of $1,500 for the $30 doll.
Report Time Prospectively When
- Users need to decide if they can "afford" to start the process.
- Users would likely want to attend to other tasks.
- The process is very long or captive.
Keep in mind that most users do not devote their entire time and undivided attention to using your solution. More likely, users will have a few applications running, not to mention other active noncomputing tasks happening (talking to a customer on the phone, watching TV, etc.). Users, like computers, are efficient multitaskers. To a great extent, the mental gymnastics they have to perform to attend to several tasks simultaneously is desirable because it translates to productivity and proficiency:"While the file is downloading, let me find that e-mail Marketing sent me so that we can look at it together while we are on the phone."
Any process that hijacks or compromises the user's ability to multitask will break the user's flow and experience. Imagine if the file download requires a dial-up connection that runs on the same phone line or if the e-mail program is hogging so much network bandwidth that the file download is halted or significantly slowed down. Therefore, give users an estimate of how much time so that they can decide whether they can afford to start or engage the process (see Figure 7.1). Examples of these include instances when the process is very time-consuming or captive—that is, when the process will commandeer some level of the application, operating system, or the entire computer system such that users have to wait out the process before proceeding.
)
Figure 7.1 When time estimates are reported to the users prospectively, it allows users to decide whether they can afford to proceed with the process without breaking user flow or compromising other priorities.
Real Time: Scratch-and-Sniff
Perception obviously changes moment to moment as more information about something becomes available as it is being experienced. The retail world learned a long time ago that getting people to experience some product or service (by sight, touch, taste, smell, or sound) is one of the most powerful marketing techniques because perception built through direct experience is lasting compared to perception built vicariously through commercials and ads. This gave birth to the world of free samples, movie trailers, trial memberships, 30-day trial software, test drives, model homes, and Scratch-and-Sniff stickers. Although these work before the actual experience, they give consumers a taste, or better, a promise of the full experience. There is a flip-side to having real-time information, too. When the actual experience is not what was promised or expected, informed consumers will want to bail out. That gave birth to the world of refunds, money-back guarantees, and store credits!
Report Time in Real Time When
- Ongoing processes and operations are too technical or meaningless to the user.
- There is a need for users to know and act on elapsed time.
Giving users real-time information about an ongoing process was the distinctive feature behind the Class A and C progress indications mentioned in Chapter 6, "Progress Indication." Providing remaining time, for example, typically provides assurance that progress is being made and progressively informs users that the wait is getting shorter. When detail about what is being done (work units) is too technical or meaningless to the user, show remaining time rather than remaining work. For example, detail about a few files being copied from one folder to another may be meaningful to mainstream users, but detail about a few hundred files being copied from the installation DVD to a temporary folder is not. Therefore, showing files copied in the former case may be acceptable, but showing time remaining might be better in the latter case. Figure 7.2 shows another example of hiding what is not meaningful and only showing what is meaningful in the UI.
)
Figure 7.2 When detail about the process is too technical or meaningless to the user, report estimated remaining time to the user in real time.
Providing elapsed time is another way to provide real-time information, but to reiterate an important point, report elapsed time with care. As a rule of thumb, elapsed time should be used only when it is meaningful for the user to see it, such as for diagnostic purposes and performance evaluation. As a footnote, not displaying elapsed time doesn't mean not tracking elapsed time. Prompting users for actions when waits become usually long is a good idea when tracking elapsed time is useful.
Retrospective: Worst Episode Ever!
It is natural for people to evaluate a product or service after experiencing it (like the comic book guy in The Simpsons whose catch phrase is "Worst episode ever!") Thankfully, research has shown that it is possible to negate some ill effects of long waits with compelling value or highly desirable outcomes, particularly with great service. Understanding how people look back at an experience is critical because there is a high likelihood that they will repeat or reengage the same experience if they found it enjoyable. Repeating or returning to what was deemed rewarding is a basic principle called Law of Effect. Beyond returning or repeating the experience, people also become pro bono marketing mouthpieces if the experience was positive (so called word-of-mouth marketing or WOMM) or a vitriolic critic if the experience was negative. In this modern age of blogs, ensuring that people look back at an experience and evaluate it positively is even more important.
Report Time Retrospectively When
- It is meaningful or valuable for users to know how long a process took.
- Diagnostic measurement or performance assessments is necessary.
Reporting elapsed time retrospectively (after a process has been completed) should be done only when it is meaningful or valuable for the user to know how long a process has taken, such as during diagnostic measurements or performance assessments (see Figure 7.3). For most mainstream applications, there is little value in telling users how much time was taken. If there is any doubt, fill in the blank:"My users will use the reported elapsed time to __________." Other than "tell how time has elapsed," whatever you can fill in the blank should reflect your users, their needs, and how they use your solution. If you cannot fill in the blank, reporting elapsed time might very well be a bad idea in your solution.
)
Figure 7.3 Report time elapsed retrospectively only when it is valuable for users to see the amount of time taken to complete the process. This diagram illustrates an example of a database administrator viewing the output of a maintenance program that informs the administrator whether the performance of the maintenance was acceptable.