Skip to main content

Command Palette

Search for a command to run...

Why “Easy” Is Harder Than It Sounds

Accurate monitoring is essential. But for non-developers and solo builders, accuracy alone is not enough.

Updated
5 min read
Why “Easy” Is Harder Than It Sounds

From the beginning, we wanted website monitoring to feel easy.

In almost every discussion, we return to the same question:

Is this really easy to understand?

Accuracy is essential. A monitoring tool should clearly show whether a website is reachable, whether something is wrong, and what the current status is. But accuracy does not automatically make a tool easy for everyone.

When the person using it is not a developer, the question changes.

They may not know much about servers. They may not be familiar with HTTP status codes. Terms like SSL certificates or DNS settings may feel intimidating. But they may still want to know whether their website is okay right now.

Checking your own website should not feel scary or overwhelming.

Accuracy is the baseline.

Ease is the experience.

A monitoring tool has to be accurate. Without accuracy, the rest of the experience loses its meaning.

The tool should correctly check whether a website is loading, whether the response is getting slower, whether an error is happening, or whether there is a problem with a certificate. A tool that reports the wrong status or misses an important issue is hard to trust.

But showing accurate information does not always mean that the information is immediately understandable.

For example, terms like HTTP 500, Timeout, DNS Error, or SSL Certificate Expired may be technically correct. They may also be familiar to developers. But for non-developers who run a website themselves, these words may not immediately turn into a clear situation.

  • Is this a big problem or a small one?

  • What would a customer see?

  • What should I do right now?

  • Can I wait and see?

  • Should I ask someone for help?

Accurate information is necessary. But it becomes truly useful only when people can understand what that information means in their own situation.

That is why we started to think of accuracy and ease as two different problems. Accuracy is the foundation. Ease is the experience that helps people understand what that information means in their own situation.

An easy experience is more than a simple screen

At first, it is tempting to think of easy in a very simple way.

  • Would fewer buttons make it easier?

  • Would hiding settings make it easier?

  • Would a simpler screen make it easier?

Sometimes, yes. These choices can help. But we do not think an easy experience is created only by removing things.

A user can still feel lost even when there is less information. A screen can look simple and still fail to tell the user what to do next. There may be fewer settings, but the result may still be hard to interpret.

An easy experience is not necessarily an experience with less information. It is closer to an experience where people see the right information in the right order.

First, they should be able to understand the current status. If there is a problem, they should be able to understand what that problem means. If they need more detail, they should be able to find it. And if they need to explain the situation to someone else, they should have the words to do so.

In the end, ease is not only about how simple the screen looks. It is also about how well the product understands the user’s situation, and how it presents the right information at the right moment.

What we really want to reduce is uncertainty

For non-developers, the difficulty does not always come from technical terms.

  • Not knowing what to look at first

  • Not knowing whether the issue is serious

  • Not knowing how visitors are affected

  • Not knowing how to explain the situation to a developer or teammate

  • Not knowing whether there is anything they can do right now

Reducing that uncertainty is closer to what we mean by easy.

If there is a problem, the tool should say so clearly. If everything is normal, it should also say that clearly. Users should not have to check the same thing again and again just to feel sure.

And when something goes wrong, the experience should not stop at showing the name of the error. It should help the user understand what is happening, how it may appear to visitors, and how they can make sense of the situation.

We began to think that easy monitoring is not just about detecting errors. It is about helping people make sense of what those errors mean.

The question behind every decision

As we explore this experience, we keep returning to the same set of questions.

  • Is this wording immediately understandable?

  • Is this information needed right now?

  • Can users tell what to do next?

  • Is this explanation too technical?

  • Are the normal and problem states clearly different?

  • Can this information be easily shared with someone else?

Helping people understand the most important status first may matter more than offering many features. Explaining the situation in words that feel close to the user’s context may matter more than listing professional terms. For first-time users, a calm flow may matter more than exposing every possible setting.

The standard is simple.

Is this experience really easy?

We do not have the final answer yet. We are also learning that making something easy is harder than it sounds. We will need to keep thinking about the balance between simple explanations and accurate information.

Still, we want to keep this question with us.

More people can now build websites. We believe operating those websites should become easier too.

This is our second Build Note. We will keep writing as we explore how solo builders, small teams, and non-developers can understand and operate their websites with more confidence.

Build Notes

Part 2 of 4

A series of build notes on making website monitoring easier to understand for solo builders, small teams, and non-developers.

Up next

Why Website Monitoring Feels Hard for Users?

To make website monitoring easier, we first need to understand where users feel lost.