Interaction meta-scenarios

Approach to make systematic first steps to understand and start designing any unfamiliar system.

There are cases, when we start designing a new system with a serious lack of knowledge about it, i.e., the users, subject domain, etc. Or we have some information, but it is inconsistent and fragmented. Also we can encounter the opposite situation—the information we receive is so tremendous and massive, that we are literally drowning in it, trying to organize it from scratch and convert it into design solutions that are generic, scalable and structured.

One of the ways to simplify this entry into a system vision is to start from top level use cases—interaction meta-scenarios, as I call them.

Interaction meta-scenarios are behavior patterns that are typical for people and systems in general, irrelevant to the application or subject domain. Actually, they are not specific to digital systems only—there is no difference whether we are talking about an HMI of navigational system or handling the sails of a sailboat. We can consider concrete, specific use cases of any particular system to be elements of these meta-scenarios.

Let’s review some categories of these meta-scenarios.

Product lifecycle

This set is quite simple—it defines how the users start, continue, and stop the interaction with the system, gaining more knowledge (or some kind of internal representation) about it.

• Installation of the new system — almost every new system must be installed and set up, including first start, adding users, assignment of roles, settings of sensors and domain objects (if we talk about industrial applications), etc. All our efforts to make this process as simple and straightforward for the user (like service engineer).
• Onboarding process — it is clear that we must introduce the user to any more or less complex system. And even with a simple one, it doesn’t matter, at first we look at a conditional calculator, and do not start clicking on buttons.
• Accumulation and reuse of experience – the longer we work with the system, the higher the likelihood that we have already accumulated a set of some kind of repetitive entities, template solutions, chains of routine actions, and so on, which we don’t really want to repeat every time from scratch. Component libraries in Figma, creating query filter sets in Jira, the ability to save a document as a template in Word, it’s all about not forcing us to do the same thing.
• Providing expert features to speed up work – well, that’s pretty self-explanatory. What is useful for a beginner will annoy an experienced user. Hotkeys and other fast keyboard input, command line elements (see AutoCAD), automation / scripting – all this is about supporting expert users
• System customization. In the mass market, customization options are considered bad form, but the more complex our system is, the less likely it is that we will satisfy the entire mass of users (both end users and operating companies). Personally, I was surprised that even air traffic controllers set up maps and displays of aircraft for themselves. Accordingly, it is necessary to ensure that our system supports such features as customization of workspaces, business process chains, groupings of entities, composition of displayed data, and so on. It seems obvious, but there are not always enough resources for this.
• Data exchange with other systems , transfer of work results from the system – for example, sending the created drawing to the CNC machine, or importing data on fuel consumption and vehicle tracks from third-party automotive systems, etc.
• Updating the system is not the most user scenario (however, hello to Kinopoisk), but designing the experience of both private and major changes to the existing system is what will help maintain the loyalty (and, more importantly, data and settings) of existing users.
• Completion of work with the system (offboarding) . A simple but forgettable part of the lifecycle. How to delete all data? How to dispose of the system? How to show a quit or terminated user? are the elements of this metascenario.

Situation awareness

These scenarios support the user’s understanding of what is happening with the system’s automation object—a business, transportation facility, hospital schedule, or power plant infrastructure. I will not describe in detail, but these are extremely important things for the same information systems and, especially, real-time control and monitoring systems (such as nuclear power plant control centers, trading systems or workplaces for ambulance stations)

• Acquaintance with what happened to the system and its automation object during the absence.
• Understanding what requires action , including an immediate response.
• Understanding what will require a response in the near or medium term , including predicting the state of the automation object and possible consequences. Trend visualization is also here.
• Working in a normal operating mode or in the presence of incidents is one thing when everything is fine with us, another thing when an emergency situation has occurred. Whether it was an accident and the need to deal with its localization and elimination of consequences (the so-called damage control), or a crowd of tourists fell into our hotel at night, those who went on business trips in large groups will understand.
• Notifying the user about events if he is not currently interacting with the system – also includes working out user distractions when he may forget what he was doing or that something requires a reaction (for example, situations of multiple failures).
• For round-the-clock work systems (such as a ship or a flight control center) , the transfer of the watch to another operator. For example, the same change in user settings, visualization of key objects of interest, etc.

Navigation and data access

This group of scenarios is directly related to activities related to data access and processing. It is particularly related to information systems.

• Search for the desired object and get detailed information about it. If a new patient came to the registry and I need to understand if he already has a medical card or needs to create it, or if I want to find a description of a specific vehicle unit. Of course, understanding the reasons for the search is important for elaboration – it appeared outside the system, or we are moving from the list of actions that require a reaction.
• Entering, updating information about a private automation object is a typical branch for the previous scenario.
• Identification of other objects related to the current object , obtaining key information about them without going into details.

* * *

Keeping in mind these (and other) meta-scenarios, we get the “glue” for system framework, that assists to organize the system interaction model in a consistent and systematic manner. With it we can start moving to more detailed use cases—like “What are the data items needed to support awareness about past events?” or “Is there a need to support user roles management during system installation?” We also may identify blank areas that require our further attention—and start designing them.