The Seeker

Evaluating Data and Exception Driven Workflows in UI Design

New year, new start. January brings news of resolutions into our conversations and social media feeds. Brought on by last years triumphs and tribulations, we use data to inform how we should improve in the upcoming year. Deriving meaning from the events of the prior year if you will.

The majority of systems I’ve developed over the years are data-intensive. Past and present design considerations affect how users process information and achieve their goals. With the start of a new year, I reflect on data and exception driven workflows, reflecting on their differing usage and future impact.

Where Do I Hide?

Historically, I’ve witnessed development teams providing expansive grids of data for convenience. To the extent that I’ve recently discussed the need to consider visualisation alternatives in our systems. Exposing all data columns a user might need to see at some point does reduce time to market for clients. It allows us to throw grid controls or Business Intelligence software on top of sources without giving much consideration to how data is actually used. This introduces unintended challenges into business processes.

Exposing all data increases cognitive load on making decisions and reacting to events. Originally, engineers exhibited good intentions to allow easy analysis and flexibility of transforming data by varying dimensions. Seeking context and identifying patterns is not always acceptable. Where results dictate a call to action, users exhibit a higher cognitive load. A data driven workflow introduces the need to constantly validate decisions. For new joiners, such processes require the accrual of knowledge over time to master business processes.

These challenges teach us that presenting all data fields is not always the right approach. Good engineers should be comfortable asking questions and forming an understanding of the processes clients follow, and the goals they strive to achieve. Developers should collaborate with users and designers alike rather than wait for permission to try something new.

Tell Me a Tale

Notification-based flows are a viable alternative to presenting vast expansive grids of data. If users are seeking answers from our data, there is no reason the system cannot present the answer itself, thus informing users of what action to take.

This does address the minimum knowledge requirements of a data driven application. New clients can begin using applications from the beginning without a significant fear of making mistakes, or executing particular actions in the incorrect order. Dedicated engineers should focus on alleviating the cognitive load of users. Reducing training overhead of our users should be a key considering in our product strategy.

Designing such a workflow introduces challenges. One key threat to user adoption is alert volumes. The possibility of cognitive overload remains unless caution is not taken to send correctly targeted alerts. Notifications should only be sent to the intended audience. Understanding of the target population can help identify subscriptions to reduce the cognitive load for all consumers.

Migrating from manual procedures to automated notifications relies heavily on trust. Stakeholders need to be satisfied that the system generates the correct decision. Having comfort in the underlying data is a critical starting point. Only then can we construct a reliable notification based approach.

Citizens of Tomorrow

Creating an alerting mechanism is the start and not the end of the automation journey. Once notifications have been identified, there is no reason that the risk of manual error could not be eliminated by automating the corresponding action.

Regardless of the benefits of automating repetitive manual steps, false positives and negatives will affect uptake. Especially in heavily controlled environments where incorrect decisions result in potentially disastrous consequences. Humans will begin to disregard particular alerts if regularly presented with false positives.

A recent experience over Christmas vacation with mobile ticketing brought home the potential impact of such false results. My husband’s bus ticket always failed to validate. The reader emitted an angry beep every time he boarded a bus. Every time without fail, the driver would roll his eyes and wave him through. It became vastly clear that false negatives were such a common occurrence that negative validations were always dismissed as invalid.

Failure to strike the balance of these false results against true negatives will erode client trust in the system. Confidence in both the workflow and action automation can only be built through validation and measurement of commonly agreed KPIs. Yet another case where collaboration between software engineers and users is the sole solution to building solutions that address client problems.

Thanks for reading!