Redesigning a legacy system for a large organisation? Consider these 9 social phenomena for a better start.
Working with legacy systems can overwhelm even the biggest brains.
These 9 phenomena can help you navigate ambiguity, get better feedback from your stakeholders, and get your project off the ground faster.
Understand the organisation before you understand product requirements.
Organisations of all shapes and sizes invest in software to improve the efficiency of creating value, so before you start anything, consider the Jevons Paradox.
Jevons Paradox states that in the long term, an increase in efficiency in resource use will generate an increase rather than a decrease in resource consumption. The increase in productivity, efficiency or cost reduction of a process that your product brings will increase demand — the more fuel-efficient planes become, the more aircraft are in the air, and the more fuel they all burn.
Depending on the industry or domain you work with, this may translate into potential consequences you’d like to prepare yourself for from the beginning.
Conway’s Law states that a structure of a complex product eventually mirrors the structure of the organisation that made it. Even just siloed data can lead to a fragmented user experience.
The best way to improve a complex product’s design may be to fix the organisational structure first.
Building a system is a balancing act of 871 easy steps.
Gall’s Law states that building a complex system from scratch will inevitably fail and that to build a complex system, you first need to develop a small one that works.
Complicated systems should emerge from simpler systems. But as convincing as this approach may be, for many enterprise products to be useful, the product must cover most of the workflows from day one.
The Law of Conservation of Complexity states that for every system, there’s a certain amount of complexity that cannot be reduced. One of the best ways to identify the sweet spot between these two laws is to map and analyse the most productive workflows with future end users.
Structure communication to minimise the noise.
In a professional setting, many people try to sound as smart and ready for the next promotion as possible, so in many public conversations, your subject matter experts may try to outsmart each other by discussing highly unlikely scenarios.
Availability Bias explains why such a significant portion of meetings and business requirements for software products focuses on edge cases: we overestimate the probability of rare events while underestimating the probability of likely events.
These two create a potent mix that can bloat your backlog with requirements covering scenarios, features or workflows that are unlikely ever to happen.
A similar tendency to overestimate the probability of success in tasks perceived as hard and underestimate it in tasks that seem easy is the Hard-Easy Effect. Keep this in mind when estimating time or effort with a team of experts.
Another interesting one is the Bike-shed Effect which explains that organisations spend disproportionate time on minor issues as most people can relate to them. Relatability explains why your stakeholders will nod on your dataset schema slide but may spend hours discussing how to call it.
One more that will save you a lot of time is Fredkin’s Paradox, which reminds us that the more equally attractive two alternatives seem, the harder it is to pick one of them.
Establishing good metrics clarifies performance expectations.
Establishing good metrics can make or break the internal perception of the system and your work on it.
Take time to develop good metrics because “what gets measured gets better” (Richard Humming). Measuring customer support satisfaction can eventually lead to better customer support.
However, once a data trail from a metric becomes available, someone will try to put targets on it. As Goodhart’s Law states: when a measure becomes a target, it is no longer a good measure. Using measures to reward performance provides an incentive to manipulate them to get the reward, which can backfire quickly.
Considering these phenomena will help you work with legacy systems for large organisations or impress someone at a dinner party. Be hopeful.
Most things tend to get complex before eventually getting simple.
Check the Enterprise Software Survival Guide reading list for more insights on working on a legacy system redesign.👇
Do your stakeholders struggle to understand the value of UX? Try this approach next time.👇
