Introduction

Context

Over the past three years, I have been designing complex decision support systems for work-domain experts. This includes dashboards that aggregates information from multiple systems and user groups, decision support systems that involves rule-based algorithms to suggest recovery plans to the users and map based systems that provides users with ground situational awareness. It has been rather challenging but an extremely fufilling journey, nailing the concepts of operations.

In this article, I will be sharing my experience with designing complex and specialised systems for work-domain experts. I will be closely referring to definitions of complex applications, specialised systems and work-domain experts that I have learnt from attending NN/gs' course on "Designing Complex Apps for Specialised Domains" by Kate Kaplan.

Who are Work-domain experts?

Work-domain experts are defined as potential end users with direct work-domain experience, or people with extensive secondary knowledge of the work-domain. They are very familiar with their concept of operations and these are unique to their use cases and not commonly known to outsiders.

What are Complex and Specialised systems?

Complex applications are defined as applications that supports broad, unstructured goals or nonlinear workflows. Specialised systems refers to a field of work that requires specialised knowledge or training to reach objectives. Complexity can be defined by 5 main factors - Institution, Environment, Intention, Information and Integration. I will elaborate more on these factors in the context of what I have been exposed to.

Integrative Complexity

When multiple systems are involved and developed for different user groups and information has to be integrated together to provide users with a one glance view of information required.

☝️ Complexities can come from back-end architecture managed by different teams or legacy of underlying systems that has been built earlier but cannot be phased out due to dependencies.

Informational Complexity

When large volumes of data needs to be integrated with different systems for presentation and analysis of data in individual systems catered to different user groups.

💡 Identify key owners of each datasets and which systems these information should be integrated with early to avoid duplication of data sources.

Intent Complexity

When broad tasks and goals are unstructured and requires dynamic decision making on the spot, users might need to re-analyse data when there's sudden changes in environment and circumstances which renders current report out of date.

💡 Design an alternative path for users to edit plans on the fly when things goes south. There will be added complexities when changes in a plan affects another or when a decision support system is used and error recovery is essential for the users.

Environmental Complexity

When collaboration and dependencies on information transfer that results in interruptions, distractions and breakage in workflow, user can only complete their task when crucial information is provided by another user.

☝️ Without the relevant information required, the user will have to chase others in order to complete his tasks resulting in delays and downstream impact to subsequent users waiting for information.

Institutional Complexity

Defined by cultural structure of roles, norms, attitudes, beliefs and sources of power within the organisation.

☝️ Complexity can come from requirement to stick to legacy systems, due to inability to overhaul them as multiple systems are integrating to it.

Designing for them

I will be sharing some of the techniques I have applied while working in this environment and how it helped me be better at my work. My methods are mostly self exploratory, through experimenting and adapting, as well as learning from failures and improving from them.

Map out information flow diagram early

👉 Tackles: Integrative, Information and Institutional Complexities

Information flow diagrams will help to articulate which systems are the key source of certain datasets and this will help to eliminate double entry or duplicated features that requires the same inputs from the users. This might seem very daunting at the start for someone without prior domain knowledge of the ecosystem especially at organisations that do not have an existing repository to refer to - you wouldn't know what you don't know and how do you even begin digging about something you don't know about. 

What could help would be to leverage on your colleague's existing knowledge of the domain and to arrange for system demos by the system maintenance team or users themselves if this option is available for you. If both options are unavailable, try getting access to the system and doing a click-through yourself. This option might take longer but it is still a start!

💡 Questions to ask
1. What is the key functionality of the system?
2. Who are the different user groups using the system?
3. Out of which, which users edits the information and which users views the information?
4. Are there any existing integration between the system to other systems?
5. Are there any existing dependencies from other systems?
6. Any known painpoints expressed by users?

These questions will help you get a headstart on some domain knowledge, potentially provide some questions that you may want to ask your user during user interviews or focus groups and the available systems in the ecosystem.

Designing for error recovery

👉 Tackles: Intent and Environmental Complexities

Lapses in information flow may happen when users who are supposed to provide these information are in the midst of doing other adhoc tasks that happens along the way. In such cases, the users who are waiting for this information might already have their hands on the most updated details via verbal communication or through other means of communication. While it is possible for your user to change the information on the other users' behalf, it is often not ideal as they should not be given the user rights to edit information that is owned by other user groups as this will impact data integrity. If the system you are designing relies heavily on integrated information from other sources, it is important to ensure that your system allows your user to overwrite the information locally on his system so that he can continue completing his tasks before the other users updates this information. 

Error recovery is also important when your system provides recommendations that is algorithmically derived based on the inputs that are given by the users. While it is important to perfect system recommendations, it is also as important to design an error recovery process where the users can manually change the results of the recommendations based on his own jurisdiction and expertise. An example of this is, given that your system provides the users with a recommended route from Point A to B, while driving to Point B, there's a traffic congestion and it is no longer ideal for your user to use suggested route. There should be a way for your user to change his route to point B based on environmental changes.

💡 Questions to ask
1. Who do you rely heavily on for information before you are able to execute your work?
2. How often do you check in with that user group?
3. What situation usually renders a change in plan/action?
4. What is your intention of changing your plan/action?
5. Which input to the system changes in this scenario?
6. How do you expect the system to react to these changes?

These questions would be ideal in helping you to understand who are the dependencies of your users so that you can take note of the key information that your user needs to execute his tasks without being bottlenecked, frequency at which information need to be pulled, discovering what end-to-end workflow you should be looking out for when things doesn't go as planned, impact of not being able to go as planned and how does the user expect the system to value add to his processes.

Group workflows based on high-level goals

👉 Tackles: All Complexities

It is common for multiple user groups to work together to meet the same high-level goals. An example of this is, when a customer places an order for a burger set meal at a fast food restaurant. The high-level goal in this case would be to fulfill the customers' order and the different user groups would be the cashier, chef, logistics assistant and the waiter. Grouping the individual workflows of each user group together helps to consolidate all the key requirements to make the high-level goals achievable. By doing so, you will also be able to help identify outputs of each user group and means of communicating these outputs to other users.

In a more complex environment, your problem could look like this:

High-level goal: To ensure Director's objective can be met

User Groups and Goals:
1. Director: Sets objective
2. Planner: Plans requirements to achieve objective
3. Consolidator: Provide direction and recommendations / solutions to executors when there are issues
4. Executor: Execute plans based on directions given by consolidator and sound out issues

As each user groups has their own objectives to meet, by looking at them singularly, it will be tougher to determine the sequence of events and also information dependencies on users when executing their own tasks. By grouping the workflows, it will help to identify the various touchpoints each user groups will have with one another and how they can impact each other's processes. 

This is also very useful in helping to convince multiple stakeholders and managers across different projects in prioritising certain features for development in an Agile development cycle. This is especially useful if mutiple projects are developing for each user group as it helps to articulate potential bottlenecks and integrations that should be considered upfront.

Conclusion

Designing for work-domain experts may seem daunting when you first start, however, as you develop better affinity with your users during the research process, things will get smoother. As your users acknowledge that you are putting in an effort to study their domain and to offer fresh insights to their current processes, they will be more willing to share their problems with you 😁