One of my favourite concepts from the world of ergonomics is the forcing function commonly cited in human factors case studies as recommendations for error-prevention in health and safety contexts. It means forcing users to do something in a certain way in order to proceed on a journey. A great example is how microwaves do not work unless the door is closed. Users cannot fail to be aware of the open door because it literally stops them from carrying out the primary goal, and crucially, it is not possible to make a catastrophic error. Dan Stockton provides eight design patterns for error-proofing most of which are examples of forcing functions in the physical world. There are direct links between these and examples from the digital world, the common factor being that they support error prevention as opposed to error recovery.
For example, if you wanted to stop people from walking up a flight of stairs, you could put up a sign on the wall reading "do not walk up these stairs". Or you could use a physical barrier. These two measures both have exactly the same the meaning, but only the physical barrier actually stops people from walking up the stairs.
An example from the digital world: you may not be allowed to proceed using a site until you have changed your password (eBay recently enforced this). In fact good password creation tools utilise forcing functions by disabling the button until the password criteria are met. This is a forcing function; compare that with the experience of having an error message appear on click of a button reading ‘password criteria not met’ or something equally annoying.
Stress-testing a system
When designing or building any system, one of your 'stress tests' should be what I dub the ‘blunderer’ – which is a user who has no intention of following any sort of advice or guidance – or even paying attention to anything. Their goal is to get as far as they can through the process and will generally choose paths of least resistance. You as a designer must ask yourself this: how far can they get through the system? If the answer is that they can stumble through and get further than you wanted them to go, then you need to put in a forcing function somewhere along the way.
In our physical example, the blunderer could easily ignore any signs leading up to the stairs, but they couldn't ignore a barrier - they would walk straight into it and fall over. Now, you may be thinking ok, the user might fall over, but they could easily crawl underneath or jump over the barrier. And you'd be right. But there is a crucial difference between the act of hurdling a barrier and the act of ignoring signs on the wall. Hurdling over a barrier is an active decision, and takes some effort - it presupposes that the user has acknowledged the barrier and understood the meaning of it, yet they have made an active decision to circumvent it.
Compare this to the act of ignoring signs; this is a totally passive act, and in order to achieve the goal (walking up the stairs) the user does not require any sort of decision or any understanding of the system whatsoever. They can set their sights on the goal, and blunder towards it without any thought.
Making that active decision to circumvent a barrier requires much more precise and intentional behaviour than simply blundering through, and so is much less likely to happen (it may also be easier to prosecute someone who has circumvented a barrier, for cases where the 'goal' is something illegal such as piracy or hacking).
Forcing functions decrease the likelihood of blunders getting out of control.
Beyond the simple ‘blocking’ nature of forcing functions, there are more subtle advantages to them, and these are what make forcing functions a particular favourite:
They convey a very tangible meaning to the user. For example a button on a web page that is disabled conveys a great amount of meaning - much more than if the button was simply not there. Users can reason that there must be some set of actions which they must perform to make the button enabled - and therefore recognises the step of the process the button represents as important and reliant on certain other actions. This actually gives the user more control too – rather than allowing them to do something the system does not accept, and showing an error message, it gives them all the information up front without them having to read anything.
Something else forcing functions affect is the personality of a website or software. The thought behind this is often handed over to graphic designers, copywriters and marketers – but I have always maintained that it begins with the interaction design. You can affect how users view the system (trustworthy, secure, personal, fun, authoritative) just by choosing interactions carefully. For example, a process could be very linear – making users jump through hoops step by step (authoritative, secure); or it could allow some more freedom in how users interact with it using a hub and spoke model (more fun and personal). Each of these could utilise forcing functions in varying ways – depending on which parts of the system you want to emote freedom, and which parts you wish to promote authority/security.
A cornerstone of Gamification is the notion that something is difficult to achieve and therefore worth something to you. Games often utilise this precept by showing users future steps which are unavailable to them at the present moment – often requiring a deliberate series of steps to ‘unlock’ them – which tantalises and encourages players. Quest and Platform games use a positive forcing function to aid onboarding (learning) a game. It is a great help to players if there are easier choices to start with, and harder ones as you progress. You may start on the easiest setting, or start with one working action (e.g. ‘shoot’) which happens to be a winning action. Wii bowling for example defaults you to play with barriers – ensuring that you will knock down at least some pins.
Figure 1: Wii bowling uses default settings to force you to succeed initially
This same concept is utilised on the web and in software by providing easy choices first to onboard the user to the process. It kick-starts you with an error-free experience and sets a precedent for the rest of the journey.
I hope to have introduced some of the core concepts of forcing functions – it is by no means rocket science and I’m sure you will have heard it by another name, if not the name itself. But it is a great help to be able to explain some of these interaction decisions from different angles and so create a reduced-error experience, and maybe just avoid some catastrophic blunders.