When the fire brigade needs to know your app exists.

Strategy · 6 min read

I was in a meeting with a client who builds apps for industrial safety. He was explaining how workplace permits work. And about ten minutes in, he started describing a chain of real-world obligations that I had never considered. When a fire protection system on a manufacturing site gets turned off for maintenance, a whole series of things have to happen. The site manager has to be notified. Key people on site have to be told that there's no fire protection in that area. The local fire brigade has to be informed that the automatic alarm won't trigger, so if there's a fire, someone will need to call them manually. And if the system is offline for more than 24 hours, the insurer has to be notified too. Because the insurance policy is based on that system being active. If it's not, the insurer might change the terms. Higher excess. Requirement for a physical security guard. Additional conditions.

None of those people are users of the app. The fire brigade doesn't log in. The insurer doesn't have an account. But the app has to account for all of them.

Stakeholders who never touch the screen

When you design an app, you think about users. The people who log in, tap through screens, and interact with the interface. That's correct. But in regulated industries, there are stakeholders who never touch the app and still need to be part of the system. They receive notifications. They require documentation. They impose rules that shape how the app behaves. And if you don't design for them, the app might work perfectly from a user experience perspective and still fail its regulatory purpose.

In our case, the app needed to know that certain permit types trigger external notifications. A standard hot work permit might not require any external parties. But an impairment notice, where a protection system goes offline, triggers a cascade of obligations. The app has to know the difference. It has to prompt the manager to notify the right people. And it has to record that the notification happened, because the audit trail needs to show that the process was followed.

The app as a compliance chain

Think of the app not just as a product but as a link in a compliance chain. The worker does the job. The app records the evidence. The manager reviews the record. The insurer can audit the history. The fire brigade has been notified when required. Every link in that chain has to work. And most of the links involve people or organisations that will never download the app.

This is where the client's industry knowledge was absolutely critical. I would never have known about fire brigade notification requirements. I wouldn't have known about the 24-hour threshold for insurer notification. I wouldn't have understood that a company might use this app's audit trail as marketing material to insurers, proving that they employ best practice safety processes. All of that came from the client sitting in a meeting and explaining how the real world actually works.

The client even mentioned that insurers and risk surveyors should eventually have their own access to the system. Not to manage permits. Just to audit them. To go in, review the data, and confirm that the company is doing what they say they're doing. That's a user type we hadn't planned for in the MVP, but it shaped how we structured the audit trail and the export functionality.

Design for the people who aren't in the room

If your app operates in a regulated industry, ask this question early. Who needs to know what's happening in this app, even if they never use it? That might be a government agency. An insurer. A compliance officer. An external auditor. An emergency service. Those stakeholders shape the data you collect, the records you keep, the notifications you send, and the exports you support. They're invisible in the interface but foundational to the product.

The app we designed doesn't send an automatic notification to the fire brigade. That's not in the MVP. But it does prompt the manager to do it, records that the prompt was shown, and logs whether the manager confirmed the notification was sent. That's the design solution. The app can't call the fire brigade. But it can make sure someone does and prove that it happened.

Your users are the people on the screen. Your stakeholders are everyone else who depends on what happens inside the app. Design for both.

Sources
Emergency Plans and Procedures (Safe Work Australia) - Requirements for emergency notification and response in Australian workplaces.
Insurance Council of Australia - Industry body representing insurers, including standards for risk management and compliance in commercial properties.

Related blog posts:

Compliance isn't a feature →

When you can't cut the audit trail →

One app, three users: permission layers →