Context

Using context to bring clarity.

Many of the frustrations of today’s software — cryptic error messages, tedious procedures, and brittle behavior — are often due to the program taking actions that may be right given the software’s assumptions, but wrong for the user’s actual context. The only way out is to have the software know more about, and be more sensitive to, context.
H. Lieberman and T. Selker
Depending on the software you're designing, there are some obvious macro contextual considerations you should make:
  • Place of use (office, train, car, home, outdoors, indoors etc.).
  • Time of use (day, night, regular intervals, random intervals, time of year).
  • User's personal information (non technical/ technical, young/old, accessibility considerations, personal views).
  • Accessibility - see this exceptional website for information on situational/ temporary/ permanent disability considerations.
This is the type of information that should have formed part of your Task and User Analysis — covered in the section Starting the Design — so it's worth revisiting your Task and User Analysis to see if this provides some ideas of where you can improve your user experience depending on, for example, time of use. The most obvious example of this is of course, supporting dark mode. Another example would be things like arriving at a location triggering a reminder, or supporting usage offline if your product will ever be used on a commute (where signal is often a problem). There are also some highly important micro contextual considerations, and that's what we'll deal with in this section:
  • What have I done up to this point?
  • What did I just do?
  • What's the current state?
  • What can be done next?
In order to do a good job of communicating these nebulous states, outcomes and possibilities you need to engage in a good dose of reification, which is to say turning an abstract intent into a concrete action.Adding any kind of contextual intelligence to your apps will add complexity, users will have to learn the states, and developers will have to juggle them. This complexity isn't bad, it is in fact required in order to provide a low friction user experience. Interestingly we find that some users are more affected by context than others, the users that struggle to hold mental models in their heads tend to rely more heavily on context, and if you don't cater for context well enough, these users in particular can run into trouble. This is yet another case of 'you are not the user' being relevant.

What have I done up to this point?

This is to do with knowing about past actions the user took, and using that knowledge to smooth the route ahead, here are some examples of that:
  • Storing form information for re-use in the future.
  • Learning an irregular spelling a user intentionally uses on multiple occasions.
  • Suggesting further content based on previously viewed content. This can have unintended consequences (reinforcing biases and such).
  • Remembering and suggesting recently used items/ files.
  • Remembering a state a user sets, and reusing that in the future. This could be window positions, or a drop down setting.
  • Ordering search results with frequently visited results coming top. Like suggesting content, this one can also have unintended consequences.
  • Showing some kind of history of actions taken by the user.
For a real world example, let's look at this frankly brilliant help article from Google. They detect what account you're viewing this page from, they look into your admin privileges, and tell you if you're able to proceed, and if not, why this is, and what you can do about it. Kudos.
As an aside, it's worth mentioning ChatGTP here, if you're unfamiliar, ChatGTP is an AI chat bot that can converse in a conversational style; it can answer follow up questions, admit mistakes and make corrections, it can do these things because it has contextual awareness of your conversation, this is a very compelling and interesting development in this field directly related to the above points.

What did I just do?

  • On the low hanging fruit end of the spectrum of this category, the way to deal with this is feedback. A subject handled to an excellent degree in a thousand different places. Suffice to say that it should be obvious to a user that they just did something, and how that went. I'd call this table stakes. So let's move on.
  • A more advanced trait in this category is that your system should strive to understand the intent of what the user just did:
    • If I type a proper noun, and the system corrects it to some 'correctly' spelled word, then I'll have to go back and type it again, now if it gets corrected again this is an example of a system not understanding the intent of what I just did. In this situation the system should understand I just corrected the correction, and it should not correct it again.
    • If I drag an image into an image editing application content area, my intent is that this image should be added to the content area, and thus that is what should happen.
    • If I drag some files onto a folder and then hold the mouse there, the folder will magically open for me - this is called spring loading folders and they are a wonderful thing, by inferring that I want to 'enter' a folder, a number of steps in the process of putting files in specific nested locations can be removed in a highly intuitive way.

What's the current state?

State is highly dependent on your domain, for example, in an accountancy app, date is an extremely important state to communicate effectively as so many things hinge off it, you don't want your user to put something in the wrong accounting year because they get mixed up. Likewise in animation software, the current time (frame) is a very important state to communicate, as is selection and the current type of editing mode that the user is in; this list is pretty endless to be honest.
Another, perhaps more simple example of state would be in an word processor, the current font and style would form part of the current document state and a common locus of frustration is when word processors break the current state when pasting something in...
There is a lot of overlap with Information Architecture (IA) when it comes to state - for example breadcrumbs that show you where you are in some data form part of the IA, with your location in that data forming part of the app's current state. If this sounds a lot like communicating context to you, you're absolutely right, and you're getting it! Context, state and IA are all interrelated.Another example that falls under all three categories of context, state and IA is scrollbars, these provide you with your current location on a page, or in a document, on macOS these are hidden by default for trackpad users in the interests of minimal beautiful UIs, scrollbars appear when a scroll interaction happens, so in order to know your location in a document you must first scroll it, then look at the scroll location - this is the very definition of a UI bottleneck and is unarguably an inefficient user experience (though it makes for a lovely clean UI). This mistake becomes a criminal matter when it comes to XCode. When programming something in XCode, if one makes a change which causes an error to appear elsewhere in the document, this is indicated to you with a small red line in the scroll bar. The visibility of this error state is exceptionally important for developers and all good and proper coding environments make these indicators permanent, but you guessed it, when the scroll bar isn't visible in XCode, neither are the error bars. Oh dear.

Be honest about state.


The Three Mile Island nuclear disaster was caused by the system state not being accurately reflected in the user interface:
  • An operator activated a valve switch.
  • A light went on.
  • The operator reasonably assumed this meant a valve had opened. It had not, the light went on regardless of the valve working or not, it was effectively a light switch. A partial meltdown occurred.
A much milder modern version of this would be a system for submitting jobs for processing on a server, here's what not to do:
  • User submits a job
  • A status update immediately changes to "In Progress" in order to give some instant feedback.
  • A few seconds later, the servers return an error of some sort as there was a fault with the submission, the status changes to "Error".
In this situation the message should never have been changed to "In Progress", because the job never got that far. Instead "Submitting" or some other preparatory piece of copy would be better as it would communicate to the user that something has happened - but that the job is yet to start.

What can be done next?

  • Use Empty Space. If content windows are empty, put a message in them indicating how they might be used.
  • Automatic context switching:
    • If you have context sensitive controls or tools (e.g something that only works with a particular selection) consider showing these controls when an appropriate state is reached (in the given example that would be when an appropriate selection is made).
    • In Unity they recently introduced contextual workflows for this, in Cavalry we have certain controls/tools that automatically appear when certain layers are selected, showing context sensitive controls so a user can can see a route forwarn in these contexts. I.e if you select a gradient in the layer stack, we show gradient controls in the viewport which can directly manipulate the gradient. The user doesn't need to do anything to see these, it's automatic.
  • Feed forward.
    • This is a way to provide a user with a result of an operation without actually performing it.
      • Previewing an image filter without committing to it.
    • It's also a way to indicate if something is possible, or what the result would be if the user were to follow through.
      • If I'm dragging a file into a text editor, will this open as a new tab, or a split view? Feed-forward could indicate this, Visual Studio Code is particularly good at this.
      • If a button is incompatible with the current selection, disable it.
  • Provide different ways to view data - this can unblock users who don't know how to do something, when they look at it from a different perspective, they may see a new way ahead. This is especially useful for users who struggle to maintain mental models in their heads. These kinds of users need to explicitly see overviews of data and relationships in order to discern how best to manipulate them.
    • For example, spreadsheet data could also be viewed as charts.
    • Tree structures can be viewed in any number of ways (graphs, hierarchical lists, drill-down columns, flow charts, etc.). Remember that related items - not just child/parent relationships create tree structures.
    • A domain specific example - animation keyframe data on a timeline can also be shown as 2d curves to show speed of movement.
  • Provide context sensitive names if applicable. If you have a day of the week control on Screen A and this controls the day something is created, you may want to label it Day of the Week, and that's okay. Then if on Screen B you have another day of the week control, it may be tempting to also call this Day of the Week for reasons of consistency and because it says what the control is, but before you do, consider the purpose of the feature, in this situation let's say this controls the due day, it is probably more useful to call it Due Day which is a more self documenting name from which purpose can be derived as instead of saying what the control is, it says what it does. This is an inconsistency for the sake of clarity, due to context. If you understand this, congratulations, you are now a level 8 Product Designer. For more on Consistency (and its pitfalls, see this link).