Module 2, Use cases

On this page

Module 2

  • 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. In large-scale projects, the process may 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 may rely on agile development or a more traditional approach.

Regardless of the process used, it’s crucial to consider use case development in service projects. Unfortunately, this often isn’t done for online services, as use cases are typically associated with software products. However, an online service is also a software project, and detailed specifications are equally important—if not more so. Practical experience shows that many accessibility issues stem from incomplete or missing specifications during the planning phase. Sometimes, development starts with designing the user interface before deciding on the functions the service should perform.

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 scenario is similar to a use case but is usually written at a higher level and from the user’s perspective. It describes what the user wants to do with the service and why. What is the goal of this task from the user’s point of view? A user story can be more informal and descriptive, and it doesn’t need to address the technical details of the service.

Use cases and scenarios are used to define the functional requirements of a service. The advantage of these methods is that they help prevent unnecessary features in the user interface. This is especially important for online services, where the main pages can easily become cluttered due to demands from various stakeholders. Excessive content can significantly hinder usability when unnecessary highlights, embeds, and forms are added that do not serve the primary purposes intended for the users.

All user interface functions should be created based on use cases. Use cases should be iterated whenever it is found that the UI still lacks some basic requirements or has unforeseen features. Use cases and user stories are particularly well suited to agile development and MVP (minimum viable product) release.

Accessibility in a use case

Accessibility requirements are usually easy to include in use cases. Among other things, they appear as delimitations related to the task:

  • The user may not be able to examine the entire page view at once or see beyond one element group (due to screen magnification or a screen reader program)
  • The user may be using a keyboard only without a pointer device (mouse, touch activation)
  • The user may be unfamiliar with common IT conventions, such as menu, saving or location symbols (a senior user, for example)
  • The user may have challenges with language and reading

Taking these issues into account will ensure that the service is accessible to different user groups.

Still, taking accessibility requirements into account is not always obvious, especially when the subject is unfamiliar. In particular, integrating assistive technology such as screen readers into concrete use cases can seem strange and difficult. On the other hand, even the basic challenges faced by older users in the user interfaces of online services can be surprisingly simple. For example, the meanings and functionalities of symbols may remain unclear.

Here are clearer versions of the texts:

The following approach can be helpful: Start by creating high-level use stories from the perspective of a user for whom the function is both important and potentially challenging. The user can consistently be a so-called special user, such as someone with sensory or cognitive limitations due to factors like language barriers, reading difficulties, disabilities, 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 complete the task with ease. This method also makes it simpler to incorporate special considerations, such as notes on assistive devices, and ensures that the software requirements meet the legally mandated WCAG criteria. Otherwise, these criteria can seem like a collection of abstract requirements that are hard to apply in practice.

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

  1. The user discovers easily that they can change the language of the service.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. The language selection function must not be based on understanding the default-language name of an element, such as a menu.
  4. There are two languages to select from, as one of the languages is always active and thus not selectable.
  5. 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.
  6. 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.
  • The links only show the languages that the user can switch to. There are therefore always two links.
  • 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