Complexity-in-use explains why learning and using a digital tool is easy and straightforward for users in one context and difficult and cumbersome in another.
These examples illustrate the dimensions underpinning complexity-in-use. First, system dependency increases when more business concepts are represented in the system. Second, semantic dependency increases if a deeper understanding of these concepts and how the system processes them is required. The two dependencies complement and reinforce one another — the impact of semantic dependency will be much higher if system dependency is also high.
This is an engrossing write up with significant pointers. There is a lot of cognitive overload of new systems (and that also explains the resistance to adopt and adapt new tools). This is true for those organisations who are making a shift to the EMR’s- for example. The business case illustrated here is for a bank but the key pointers apply in healthcare too. Here’s another interesting insight:
This complexity-in-use is often overlooked in digitalization projects because those in charge think that accounting for task and system complexity independent of one another is enough. In our case, at the beginning of the transformation, tasks and processes were considered relatively stable and independent from the new system. As a result, the loan-editing clerks were unable to complete business-critical tasks for weeks, and management needed to completely reinvent their change management approach to turn the project around and overcome operational problems in the high complexity-in-use area.
The key-takeaways from this study are:
The solution itself is more complex than the problem! Digitisation will depend on user uptake and addressing concerns of senior leadership on eventual “efficiency gains”. Unless there is a clear business-case, they will not budge. Besides, it will lead to more demands from senior employees to “hire data-entry clerks”, so those issues also need to be addressed.
One way forward is to introduce the systems modularly, without an overload of the “features”. A browser based system with server side changes is the best solution to manage costs. A timeline with user metrics will provide a visual indicator of the transformation. I had brainstormed these issues before the proposal went live locally in front of the committee, but they rejected the proposal. However, the insights have been refined further.