Module 2, Use cases

Use cases describe what functions service users need from a service and how these functions are performed in the service.
Well-created use cases steer user interface design. They help avoid the accumulation of unnecessary functions and contents in the service.
Use cases are also key in successful accessibility user testing.

Use cases and service development

A website is created in a software development process that is today based increasingly often on so-called agile development, but especially in large-scale projects, the process can also rely on a more conventional waterfall model or quality reports through which the service must pass before certain work phases are completed. In such a model, individual development phases can correspondingly be based recursively on the same development process or implement it into a separate, more agile and iterative development method.

Regardless of the form of the process, use case development must be taken into account in the service development endeavours. Unfortunately, this is not always the case with online services yet, as use cases are considered to be more closely related to software products. However, an online service is a software project as well, and the role of specification is not any less significant in it – on the contrary: Experience with practical development projects has shown that the majority of problems related to accessibility in particular occur early on in a specification phase that has shortcomings or is not always even carried out. In fact, the development of the service may start directly from user interface visualisation without a decision on what functions the service is even intended to carry out. This problem was also detected when assessing the state of the City of Helsinki’s services (Service Centre, 2020).

Not only do use cases serve as a foundation for specification work, they are also a prerequisite for efficient accessibility user testing. This is why use cases are paid special attention to in Helsinki’s Accessibility Model.

Use cases: ‘use case’ and ‘user story’

‘Use case’ refers to a function or series of functions that a user performs in the service so that the service can fulfil a need assigned to it. A use case is an account of the interaction between the user and the system. It indicates what state the system is in, how the system reacts during the use case, what exceptions may occur and what the state of the system becomes like when the use case is completed.

A ‘user story’, or a scenario, resembles a use case, but it is usually written at a higher level and from the user’s perspective: What does the user want to do in the service and why? What is the objective of this task from the user’s standpoint? In accordance with its name, a user story can be a more prosaic account that does not have to comment on what happens in the service technically.

Use cases and scenarios are used to specify the service’s functional requirements. The advantage of these methods is that they should prevent the creation of unnecessary functions in the user interface, which can significantly compromise accessibility particularly in online services and on their websites, as every interested party related to the service has added their own highlights, embeddings and forms to it without all this “bloat” actually having to do with the purposes for which the service is provided to users.

As such, all user interface functions should be created based on use cases alone, and use cases in turn should be iterated when it is discovered that the user interface is still missing some of the basic requirements set for the service, or that the requirements include aspects that were not anticipated. Thus, use cases and stories are particularly well suited for agile development and MVP (minimum viable product) publishing.

Accessibility in a use case

Applying accessibility-related requirements to use cases is usually straightforward. Among other things, they appear as delimitations related to the task: for example, the user is unable to examine the entire page view at one or see beyond one element group (due to screen magnification or a screen reader program); they may be using a keyboard alone without a pointer device (mouse, touch activation); they may be unfamiliar with even common IT conventions, such as menu, saving or location symbols (senior user); they may have challenges with language and reading; etc.

However, taking the accessibility requirements into consideration is not always obvious, especially if the perspective is even less familiar. In particular, assistive technology such as a screen reader may seem exotic and difficult to place into concrete use cases. On the other hand, the very basic-level challenges faced by aging users alone in the user interfaces of online services can surprise with their simplicity. What does the symbol with three lines on top of each other mean? Is it perhaps a decoration? Is it safe to touch it with the mouse? What if this link opens one of those non-web pages in another program that I do not want right now as I am trying to open a website?

The following method can be of help: Begin the creation of use cases with higher-level use stories that are written from the perspective of a user to whom the function is imagined to be important on the one hand but potentially difficult on the other. The user can even consistently be a so-called special user: a person with sensory or cognitive limitations caused by factors such as inadequate language or reading skills, a disability or aging.

If the use case is designed so that the user in question can manage it, it is likely that other users will also be able to carry out the task – even with great ease. That way, it will also be more straightforward to include aspects such as special notes on aid devices – and thus the legally prescribed WCAG criteria as well – in the software requirements derived from the use case. Otherwise, the criteria may be perceived as a large group of somewhat abstract requirements that is difficult to concretise.

Example

User story / scenario

User X is visiting the service for the first time. Their native language is Y, but they understand English to an extent. X needs to use a screen reader program with their web browser, as well as their smartphone and computer. X notices that the language of the service is probably Finnish, which they understand little. However, X discovers that they can change the language of the service; our user also notices that English is one of the languages supported and selects it. The language of the user interface is changed into English, and the speech synthesiser of the aid program now describes the contents of the service in an understandable manner. X starts examining the contents of the main page of the service again.

As a use case

The user can select one of the following as the language of the service: Finnish, Swedish or English.

Specified set of use cases following the use case

The user discovers easily that they can change the language of the service.
The user notices that they can select one of the following languages, with the limitation that the currently set language cannot be selected: Finnish, Swedish, English.
The user changes the language setting. The change is applied to the entire service.

Aforementioned use case #1 as an example: The user discovers easily that they can change the language of the service

User: Service client

Target: All web pages in the service.

Initial conditions:

– The user is using the service for the first time and is unfamiliar with the page structure of the service.

– As such, there is no language selection saved in the cookie data of the service.

– The user’s native language is not the default language of the service.

Delimitations: Does not pertain to publications that are not websites (e.g. PDF documents).

Objective: When the user opens a web page belonging to the service and examines or browses it conventionally, reading from the top of the page, they notice without any special efforts that they can change the language of the service.

Once all three specified use cases have been written out, they can be used to derive requirements such as the following functional requirements that specify the software implementation and user interface design processes.

Requirements derived from the set of use cases

The language selection function must be placed in the banner section of the standard page template.
1. This will guarantee that the selection function is available on all web pages of the service.
The language selection function must be located at the start of the banner immediately after the main page (logo) link.
1. The function will be visually easy to notice, even with screen magnification
2. A screen reader user whose native language is not the default service language will notice the function the easiest when they do not have to search for it among foreign-language contents or within a foreign-language menu.
The language selection function must not be based on understanding the default-language name of an element, such as a menu.
There are two languages to select from, as one of the languages is always active and thus not selectable.
If possible, the use of special controls or dynamically shown and hidden contents should be avoided as tailored, heavy technical solutions are unnecessary here and will make changing the language more difficult for aid device users.
The names of the language must be written in the language itself: suomi, svenska, English.

Technical solutions

The language selection function is implemented as conventional HTML text links that are always displayed in the banner immediately after the main page (logo) link.
- If text links cannot be used in a responsive view mode, they are placed in a language menu, the button for which is named for assistive technology so that the selectable languages are listed (e.g. svenska, English):
The browsing order, i.e. DOM order, in which the language links are corresponds with the visual layout.
Linkeistä on esillä vain ne kielet, joihin käyttäjä voi vaihtaa. Linkkejä on siten aina kaksi kappaletta.
The link order is from left to right: 1. Finnish, 2. Swedish, 3. English.
The HTML tag of each link has a ‘lang’ attribute corresponding with the language.
Because the service is a single page app (SPA) and the function is a change of page context, it must be ensured that when a language link is activated, the change in the language of the user interface contents is complemented with the following actions:
- the requirement (name of previously recorded other requirement) is met (browser focus is transferred to the start of the page, to the jump link, when the entire page context is updated).
- the requirement (name of previously recorded other requirement) is met (the ‘title’ tag of the page is updated when the page context is updated)

In this case, an analysis derived from a rather simple use case can be used not only to ensure that the technical implementation meets the WCAG criteria from the start, but also to develop the usability of the service.

Original version: Tero Pesonen
Created: 4.3.2021

Continue studying

Module 3, Software specification

Search the site