“Anticipate the client’s needs before the needs are needed.” - a beautiful small line from the wonderfully surreal movie The Grand Budapest Hotel. That’s the users value of context in a nutshell. So anticipate the users needs and design interactions accordingly. Interfaces (user interfaces) should try to meet the expectations of user requirements. It should not make users to search for necessary tools. The website does have to come up with the required information for every functioning step for the user.
In the interactive processes between users and interfaces, new elements appear in the screens where signs are out of the users’ signification system. However, in each step to achieve completely a task, the users are inferring about the behaviour of the system interface to execute all activities successfully. These inferences and expectations, possibly predictions, may be frustrated by technical failure or by communication failures. In this case, users must infer again. Truths future envisaged by the user can be destroyed if it has any disruption in the communication process between user and the interface (or with the interface’s designer). This preview of future state that influences the users’ decision-making by is called Anticipation.
Software and hardware systems should attempt to anticipate the user’s wants and needs. Do not expect users to leave the current screen to search for and collect necessary information. Information must be in place and necessary tools present and visible.
Anticipation requires that designers have a deep understanding of both the task domain and the users in order to predict what will be needed. It also requires sufficient usability testing to ensure the goal has been met: If a tool or source for information is there on the screen, but users can’t find it, it may as well not even be present.
The penalty for failing to anticipate is often swift and permanent, particularly if you do not have a captive user, as is the case with public websites and apps, for example. Those users will probably never return from their search. Even if you do have a captive user, you probably don’t have a captive client, and if the client’s employees are wasting time trying to find required resources, your competitors will have a good story to tell when it is time to make their next pitch.
User story: You want to call a friend, someone you call at least once a week:
Standard interface: Swipe phone > enter password > open calling app > tap Contacts > start typing name > find contact among 10 entries with the same first name > choose which number to call > Call
Contextual interface: Look at your phone > tap search > enter first letter > a picture of your friend is first on the list > call.
What happened here? The contextual interface realized that this person was the one you were most likely to want to call at this time, at this place, starting with that letter. Because that’s what you’ve been doing every week. The user emotion here is “I’m being understood” – the phone gets me.
I always like to measure contextual design success in terms of how little interface was needed to deliver a great result. Top success is zero interface; what you want just shows up on screen. Second best is when you just need to hint to your device. Just one one tap, or one letter. If your phone is smart, and has been with you for over a week – that should be more than enough time for it to get your hint.