A few years ago I walked into a meeting with a customer and asked the CEO what they wanted from their application monitoring.

The response was immediate:

“I only need a traffic light. Is my application green, amber, or red?”

At first glance this sounds simple. In reality, it’s not. A modern application sits on top of many layers of infrastructure, services, and dependencies. Often, there is AI involved. It all needs to be architected well. Different users may experience different outcomes at the same time. Translating that complexity into a single signal is not a trivial engineering problem.

But the request stuck with me because it captured something deeper: the innate desire of humans to make complex things easier for us to understand and manage. To reduce our cognitive load. That is the fundamental function of a good design.

In engineering-led cloud operations many teams default to the opposite. Add more dashboards, try the latest tools, introduce new alerts, build something for one user or a group that another one doesn’t need. Over time the operational environment could become harder to navigate, especially during incidents when engineers are under pressure. For example, when a P1 alert is triggered at 2am.

Around that time of the abovementioned meeting, I read The Design of Everyday Things by Don Norman. It’s a book about everyday objects like doors, switches, appliances…but many of the principles translate surprisingly well to cloud platforms or anything humans use or interact with. Which made me think about the parallels between physical good design and design operations in a digital services context.

One concept that resonated with me was signifiers: signals that make the right action obvious. A button suggests “press me.” In cloud operations, a good signifier might be a runbook action clearly labelled “Restart service safely,” or a dashboard that highlights the root cause instead of showing twenty unrelated metrics. How well signifiers are designed directly impacts the outcomes delivered by the service. It also impacts the working environment for people using it.

Another is constraints, i.e. designing systems so dangerous actions are harder to take. Guardrails in infrastructure templates, role-based access to production systems, and safe deployment pipelines are all examples.

Then there’s feedback. In the physical world you hear a click or see a light turn on. In cloud operations, feedback comes through alerts, deployment pipelines, and observability signals that help engineers understand what’s happening in real time.

These concepts matter because cloud platforms are still, for now, managed by people. And despite increasing investments in AI, I’d say they will always need a level of human oversight and management to ‘keep an eye on the robots’.

Think about the experience of receiving an alert at 3am and trying to diagnose a P1 incident. Or a CFO trying to understand the cost of running applications in the cloud. Or a CEO who simply wants to know whether the company’s customer-facing platform is healthy.

Each of these users needs a different view of the system, but the same principle applies: good design makes complex systems feel simple to operate.

To achieve this, I start with better inputs into the design process. Observing how people actually engage with the system, asking good questions, and working with teams that are trained to write strong user stories…with empathy for the end user.

Good, well written user stories help anchor design decisions in real human needs rather than technical possibilities. When these stories guide the design of observability, alerting, and operational tooling, the system naturally starts to simplify. Dashboards become clearer. Alerts become more meaningful. Workflows become easier to follow under pressure.

And sometimes, after all that engineering and design work, the outcome really can be as simple as the CEO originally asked for:

A traffic light.

Green.
Amber.
Red.

Behind it sits a complex cloud platform, dozens of services, and a lot of careful engineering. But to the person who needs to make a decision, the system communicates exactly what it should.

That’s what good design does.