Before writing his 1936 classic ‘How to win friends and influence people’ Dale Carnegie was predominantly a speechwriting consultant and author. His first three books (written in 1915, 1920 and 1926) all focused on the craft of preparing and delivering speeches.
Central to his approach was a technique which remains popular to this day:
- Tell them what you are going to tell them.
- Tell them.
- Then tell them what you just told them.
What is true of speechwriting is also true of interface design:
- Let them know what they can do.
- Let them do it.
- Then let them know what they’ve just done.
The latter part of that is delivered using UX’s beta blocker – feedback. Along with drinking more red wine, drinking less red wine, eating more cholesterol and eating less cholesterol, it lowers your user’s blood pressure.
In particular, feedback does two things. Firstly, it lets the user know that the system has received their input and is processing it on their behalf. Secondly it gives the user confidence that the thing they are wanting to achieve is progressing (or complete).
You press the switch to turn on a light in a room, but the light doesn’t come on. The fact that the switch has changed shape and has made a clicking noise gives you the feedback to know that the switch has done its job. This feedback lets you know that you need to change the bulb or that the electricity is out.
Remember the heady days when you came off a long–haul flight and just wanted to get to your hotel, but first you had to navigate the passport queue? As you snaked up and down the line you saw a sign which said ‘15 minutes’, later one which said ‘10 minutes’, then ‘5 minutes’ and eventually you got checked and went on your way. Those pieces of feedback were essential in giving you confidence about what was going on and a perceived sense of control.
Remember the headier days when you stood in the lobby of a busy hotel? You pushed the button for the lift and you waited. The light came on behind the button and that told you that the lift is on its way. Now of course you would prefer that the lift doors just open in front of you, but at least you knew there was nothing more you could do but wait.
As with lifts, lights and lines so with digital interfaces.
Every time the system receives user input and is working on their behalf it needs to let the user know what is going on. There is a myriad of feedback devices which can and should be provided for users as the system works busily on their behalf, with a relevant selection outlined below, along with the circumstances in which you should use them:
Interactive progress indication
Use these graphic devices when the user is in control of guiding themselves through a process.
Visual indication gives the user a clear sense of what has been completed, what they need to do now and what comes next.
Fathom (image owner). Visual progress indicator example [digital image]. Property of Fathom.
It isn’t always possible to fit this level of detail on to the screen without it becoming overly complex, so it is possible to convey slightly less information but still infer flow and level of completion.
Fathom (image owner). Progress indicator [digital image]. Property of Fathom.
Presentational progress indication
These devices should be used when the user can do nothing to impact the process (except potentially cancel it). Users get notoriously antsy when they don’t have control of interaction so this time needs to be managed exceptionally carefully. The system should give the user as much information as it has available to let them know when the process will complete.
Fathom (image owner). Adobe PDF viewer download progression [digital image]. Property of Fathom.
Fathom (image owner). Percentage completion example [digital image]. Property of Fathom.
This is a less fussy graphical artefact and should be used only for short (sub 10 seconds) processes:
Fathom (image owner). Looped animation example [digital image]. Property of Fathom.
This approach employs visual inference to communicate progress and should be used where the system is unsure of completion time. The artefact being animated should only make one pass left to right, it shouldn’t return and loop.
Fathom (image owner). Linear animation flight example [digital image]. Property of Fathom.
Popularised primarily by social media applications, skeleton screens give users an early sense of what content a page will contain but showing the blocks which make it up. As well as helping users anticipate what is on its way, it also allows them to get early visibility of the early–loading content, allowing them to get started on their task.
Fathom (image owner). Fathom website skeleton screen [digital image]. Property of Fathom.
How can you best help users?
There are three critical questions which are constantly on the minds of users. Well implemented feedback allows the interface to consistently and continually answer those questions while contributing to the user’s overall experience.
What have I completed?
What do I do now?
What happens next?