In any organization, myths spread about what systems do and how they work. At the start, when the system is new, everyone gets it. But over the years, as a procession of different people work on and with the systems, the original knowledge, that detailed understanding is lost.
And it makes sense. Change (to systems and staff) happen at a pace. Documentation becomes obsolete as soon as it’s printed. Keeping up is a massive undertaking, one that vanishingly few organizations actually do.
Without that detailed understanding, people make assumptions: “When I do X the system does Y therefore this is how the system works.” These assumed insights then get passed on as gospel as people come and go through the organization.
As systems designers and reverse engineers, it’s our job to cut through the hearsay. We need to understand what a system was designed to do. We need to get to the bottom of what it actually does. And we need to listen to what users believe the system does.
The older a system is, the more likely there’s a disconnect between those 3 things. Equally, if a new system took ages to implement, there’s a high chance of a big disconnect. Either way, everything must be validated and verified. We can’t take anything for granted.
You might get lucky with a subject matter expert who’s spent 20 years supporting a system. But we still need to prove that the system itself agrees with their description. If we don’t complete this due diligence, we run the very real risk of delivering a totally different system. A system that does what we were told the old system did, sure. But one that is not compatible with the organization.
By minding the gaps between intention, user experience and reality, we can build a system that ticks every box and solves the problem at hand.