Context of use is an essential input to the design process. It helps to frame the problem, define product goals, identify requirements, inspire conceptual design, and create basis for scenarios for validation and usability test. Information about the context of use of a product are generally collected early in the product life cycle and then refined as additional data are gathered from usability studies. By definition context of use determines usability. The ISO 9241 standard Part 112 Guidance on usability (ISO, 1997) defined usability as ‘the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
The Context of Use consists of the users, tasks and equipment (hardware, software and materials), and the physical and social environments in which a product is used. ISO 9241 standard Part 112 Guidance on Usability (ISO, 1997), or, in different words: the Context of Use is the actual conditions under which a given artifact/software product is used, or will be used in a normal day-to-day working situation. (ref: Interaction Design foundation).
The context of use analysis involves collecting and analysing detailed information about:
- The intended users, i.e. personas
- Their tasks
- The tools that support the users’ goals
- The physical environment in which a product will be used
- The user’s social and organizational milieu
- The technical environment and associated technical constraints
- Other contextual factors that will affect the user experience
Great. That sounds simple enough. Now what?
EMUS suggest that “Context of Use (CoU) analysis is a generic technique that assists development by posing certain probe questions about the project. [No] The probe questions elicit from the development team and other stakeholders in the project information that may be held ‘below the surface’ by one or more of the constituent groups (usually unwittingly). The effect of carrying out CoU analysis is to bring this information out into the open at an early stage in development, when the implications can be examined and to drive the formulation of a realistic test plan.” (ref: European MultiMedia Usability Services)
So a checklist is what we need?
Actually, browsing the Internet you stumble over checklist, summarizing items to check, record and consider. I’m not a fan. Checklists that have the problem that they do not give insights into the constraints, merely offer a list to tick-off. Often, the process of ticking-off dominates, shifting from checking usability to the next item on the checklist. You see a similar behavior with alert boxes. Are you sure you want to delete this file? Are you absolutely sure you want to delete this file? Are you definitely certain? By now you just want to get rid of the alert box, so of course you are absolutely definitely certain. Luckily, we have time machine.
Obviously, there are more methods then just checklists to collect data for context of use. For example interviews, workshops, surveys, site visits, artefact analysis, focus groups, observational studies, and contextual inquiry. Basically any method that helps to collect data can be used to collect information about the context of use (……).
If methods are plenty and available, critical for collecting information on context of use part must be in what the methods are applied for? What is it that we are looking for?
What we should be looking for when analyzing the context of use are the factors that constrain use. Yes, we want to know typical behavior and scenarios, but as designer we are especially interested in boarder-line situations. “Yes, I want to have that information on my tablet 24×7. Well, not when I am taking a pee, obviously. Then I want to have it on my smartphone. These borderline scenarios may not serve as requirement, but they will help prioritize the requirements we do have.
For mobile software, the most basic parameters that govern the constraints on use are; the physical location, the device on which the software is running, and the available attention span.
- The physical location is a fundamental parameter. Typical locations are home, office, on ‘on the road’, i.e. in-between. To specify this a little further, the locations are further detailed. For example, at home the areas have very specific application and because of this you can expect the portal use to be different. In the kitchen, while eating breakfast, you may have less time and attention compared to sitting in your study with a tablet on your lab.
- The device is an important parameter. Depending on you location and situation, you prefer a different device. A laptop in the office, an tablet at the kitch table and a mobile phone while walking through the city.
- Most important parameter may well be the user’s attention span. My attention span is different when I am sitting in a tram in Zurich with people entering and leaving every 3 minutes compared to being on the train gliding through the alps with, apart from beautiful scenery, nothing to distract or interrupt me for maybe a hour. Attention span and usability appear orthogonal, when it comes to their relative importance. In case attention span is infinite, usability becomes almost irrelevant; given infinite time anybody can learn anything. By contrast, when the attention span is limited, the tools must not be complex.
To analyze the context of-use I’ve created the form as shown below. You can download a free copy here. This context-of-use-form combines ‘device’, ‘attention span’ and ‘physical location’, into a basic grid to support the analysis of context of use.
To illustrate the use of this form, we use it to evaluate the context of use of a new to be developed research portal. A bank is developing a new research portal for their wealth management clients to give access to research material. The portal will be available via multiple devices, via a pc/laptop, via a tablet and via a smart phone.
As a first step, we looked at the use situations for the ‘standard user’. The result is shown below. This overview, although revealing, reflects the general expectation. For specific users the situation may be different.
To become more specific about actual user needs we use personas. In a previous project we have interviewed a large number of client advisors and based on this developed a set of client personas. From this set, we selected a few to create a small cast.
The next section gives two examples of how the context of use form will look like for specific users (as characterized through the personas). Meet Ana and Danny.
Ana is independent; not employed but with has moveable assets in the amount of 30 Million CHF, which was inherited. Her father was an entrepreneur while her mother took care of the household. Ana was married, has a University degree in Art History, and 2 children; a son 30 years working as electrical engineer and a daughter, 28 and married, with a university degree in Marketing. Ana is frequenting the club life. Clubs have beach campuses, city campuses, and sport campuses for members – and are very popular with the high society in Latin America. In addition, she likes to play golf and fitness. She drinks black coffee, but only in the morning. She has both the latest blackberry and iPhone. Ana consumes information throughout the day, both in paper form and on-line. She typically reads one local newspaper and one form the US. She will surely cover the economic, political, cultural and social life sections. Ana is in regular contact with the bank. She is fairly experienced and likes to be involved in the investment decisions.
Completing the form for Ana reveals a completely different situation, as show below.
Let’s have a look at Danny.
Danny (or Daniel as his mother calls him) obtained his wealth through a donation. He was born and still lives in Stuttgart, where he followed a professional education and became a certified accountant. His mother was a teacher. His father owns a company in network components of about 900 employees large. After his studies, Danny started working fro the KPMG in Zurich, mergers & acquisitions. He now is COO in his father’s company. Danny drives a Porsche 911, likes travelling, cooking, dine and wine. No sports. He reads the Wall Street Journal, the Frankfurter Algemeine Zeitung and the NZZ. He reads research information provided by his bank, provided it is crisp and clear. After receiving the donation he immediately invested all with his bank. He is a conservative client, and although he is independent and experienced, Danny allows himself to be driven by the Client Advisor.
Danny, being different person than Ana, also gives a different situation, as show below.
In combination (the form for the generic customer, for Ana and for Danny) the forms give a diverse overview of the constraints, sketching the solution space from the point of view of usage (i.e. context of use). Using the personas, and based on these overview it will be easy to describe a number of scenario that illustrate the usage and can be used as reference scenarios capturing the context of use in aspects that are relevant to consider when designing a solution.