Management systems come in all sorts of packages. Their effectiveness varies tremendously.
A useful analogy is an operating system. Software can perform its intended functions and still be clunky, confusing, and difficult to navigate. It may make perfect sense to the people who built it, while demanding considerable effort from the people who use it.
Our expectations of software have changed. We expect clearer interfaces, simpler navigation, and relevant information when we need it—not after searching through layers of menus.
We should bring those same expectations to management systems.
The requirements are not the user experience
Regulatory requirements and international standards help define what a management system must address. They do not require it to be cold, grey, or unnecessarily complex.
There is room to make a system more accessible without weakening its substance.
That matters because a management system is more than a collection of documents. It should help people understand their responsibilities, make decisions, coordinate work, and put requirements into practice.
A procedure can be technically correct and still be difficult to use. A requirement can be documented and still be hard to find. A system can look complete without making the work any easier to manage.
We should not still be designing for 1997
We should be learning from human-factors research, user experience, system design, and modern approaches to drafting procedures and requirements.
That means looking beyond what information a management system contains to how people find it, interpret it, and use it. Clear language, deliberate information architecture, and well-designed connections between requirements and work are part of that—not cosmetic extras.
Yet inherited formats often survive because they are familiar. We update the content, add another requirement, and issue another revision, while leaving the underlying design largely untouched.
A document can have a current revision date and still offer a user experience inherited from 1997.
The answer is not simply to put the same documents onto a newer platform. It is to reconsider their structure, language, navigation, and relationship to the work.
Standards and regulations establish expectations. They should not become an excuse to stop improving how those expectations are communicated and applied.
Design around the work—not just the document structure
The starting point should be the person using the system.
What are they trying to do? What decision are they making? What information do they need at that moment?
Someone planning a job may need the relevant requirements, controls, responsibilities, and approval steps together—not scattered across several documents organized around different standards.
A leader preparing for a field engagement may need a clear connection between the operation's risk profile, the controls that matter, and the questions worth exploring with the crew.
This is where just-in-time information becomes valuable: the right information, in the context of the work, when it is needed.
Streamlined does not mean less rigorous
The goal is not to remove necessary detail or make complex risks appear simple. It is to remove unnecessary friction.
Clear navigation, usable procedures, visible ownership, and connected information can support rigor rather than compete with it.
The question is not only whether the management system contains everything it should.
Can the people using it find what they need, understand what is required, and apply it in the work?
That is a better test of the system's design.
NovaPath Insights / Field perspective
Back to all insights