Last year’s Citi–Revlon error showcased the ramifications of unchecked shortcuts, workarounds, and usability difficulties on a global scale. It also highlighted how some practices have been increasingly normalised within banks’ back-office systems and that manual interventions can fail to alleviate or mitigate risk.
We explained why this occurred in our previous Information Age article. In short, Citibank overpaid an $8 million payment to various lenders on behalf of Revlon by $892 million, because of both a fundamental interaction design problem and the significant, unnecessary operational risk facing Citibank.
Introducing more users will not refine a UI system; only designing a better UI will. As a result of the Revlon incident, organisations are likely considering these issues in detail alongside actionable next steps.
How can these issues be avoided, overcome or learnt from?
In our work at Lab49, executing digital transformations for various sizes of companies, we have discovered several essential steps for the successful design of complex enterprise systems. While it is simplistic to suggest that these preventative measures would have helped to avoid a Revlon-scale catastrophe, any organisation wishing to undertake a successful digital transformation must:
- Understand the end-to-end service landscape from both the customer and employee perspective.
- Codify employee behaviours across lines of business.
- Explore the company’s current technology capabilities and strive to understand their relation to the business structure.
- Design tools that fit the behaviours and support the desired service outcomes.
- Build iteratively with constant feedback from users and end-customers.
How can firms ensure a smooth digital transformation journey?
Understand the end-to-end service landscape from both the customer and employee perspective
Any company undertaking digitisation must have a clear understanding of the key service, or services, it provides to end-customers. This should be their first port of call. It is then best practice to map the processes involved in delivering those services, including all people and systems. By gathering this information, technology teams will encounter employees that inhabit distinct roles across lifecycles, including subject experts, business leaders, and end-customers.
The goal is to gain a near-complete understanding of the existing landscape from employees. This can then be manifested in a service blueprint, a journey map, or a process framework. The organisation should anticipate that different outputs or levels of depth may result, depending on the scope and scenario.
While it may seem like many organisations, especially within banking, would already have this institutional knowledge, we have learned that this type of knowledge usually exists in small pockets, not across entire organisational lines. Gaining some understanding of the existing process across the organisation will therefore help clarify opportunities to converge siloed processes, increase efficiency, improve communications, and drive to any other pre-defined business objectives.
Codify user behaviours across lines of business
Secondly, as operations must be made consistent, it is recommended organisations seek a broad understanding of the types of work being achieved and identify types of working that span different departments. Universal tasks such as research, data entry, or manual quality assurance provide useful gateways into this aspect of digitisation. The crucial learning is to design for those task types, rather than for each individual or departmental instance of the task.
We recently worked with a department that had 118 different workflows for a project, where each workflow was for its own specific task. To refine this, we identified the eight most common tasks and worked with associates to understand their current workflows. We then designed and iterated a single, efficient workflow framework that applied to all eight tasks using user feedback.
Seeing an opportunity, our team hypothesised that this design could solve most of the 118 tasks, so worked with business leaders to map all 118 tasks onto the organisation’s service blueprint framework. As a result, we successfully honed the framework considering each new specific need that appeared throughout the process. We’ve since scaled up this approach by validating and iterating upon the design framework, testing it against more than 1000 workflows across 6 departments.
How to break down team and department silos for digital transformation
Explore the company’s current technology capabilities and strive to understand their relation to the business structure
While some understanding of this may arise from the initial journey mapping and service blueprint work, having clarity on the technology capabilities and ownership of existing applications will ensure that organisations are best placed to implement designs. Depending on the structure of the business in question, there may be some effort required to rally siloed groups around a single product vision.
To overcome any stagnation, digital transformation actors must understand the key players within any siloed group and begin building relationships with them. From our experience, the earlier this is achieved the more this will help lay the groundwork for effective collaboration as the project progresses.
Design tools that fit the behaviors and support the desired service outcomes
The design of tools is like designing a UI component library, but for user experience patterns based on user behaviours. To achieve this with consistency in design across differing types of behaviours, we frequently review and consider tasks and behaviours holistically.
This will help establish better user experience and increase the possibility that workers can be cross-trained on multiple tasks across the business in question.
Design and build iteratively with constant feedback from users and customers
Even if the analysis-driven method of examining processes broadly and codifying based on behaviours creates the perfect solution for today, the implementation of that solution will likely be incremental, and the needs of the company may change over time. It is important to take this into account and build iteratively while considering constant qualitative and quantitative feedback.
All the steps detailed above are subject to tweaks based on circumstance, scope, and subject matter. They serve as an indicative overview of our tactics to successfully replace software that could potentially result in the kind of situation that occurred in the Citi-Revlon case.
As enterprise applications are sometimes up to 30 years behind consumer apps, the legacy technology within banking is an area ripe for a seismic leap forward. Today’s workforce has consumer-style expectations and in some cases was in fact born more recently than the software used in these back-office contexts.
We are starting to see the ways this can cause costly mistakes for banks. The high-profile Revlon example should provide financial institutions and other companies with the impetus to not fall behind and instead to consider some of the measures outlined here.
