Design principles

The core beliefs behind every design decision. When priorities conflict, these help us choose.

Earn every pixel

Every element on screen has a cost: the user has to see it, decide whether it matters, and act on it or skip it. The goal is not "fewer elements" but fewer unnecessary elements.

• Before adding a tooltip, label, or badge, ask whether the user needs it at the moment they see it.
• If an element only matters in rare cases, reveal it on demand rather than showing it by default.
• When two components compete for attention, the one tied to the user's current task wins.
• A label that costs attention without adding information should be cut. Prefer wording that earns the same attention.

Merged while seeding. The live page publishes this principle twice — once as "Earn every pixel" and again as "Interaction cost", opening with a byte-identical paragraph. De-duplicate it on the live page too.

Less is more

Simplicity is a design strategy, not a style preference. Every element, component, and page should justify its existence. If it doesn't serve the user's goal, it's noise.

Before creating a new component, ask two questions: why does this need to exist? and will this be used again? A component built for one edge case adds maintenance cost and cognitive load without earning its place. If either answer is uncertain, solve the problem with what already exists.

• For every element on a page, be able to explain why it's there. If you can't, remove it.
• When a page tries to communicate too many things at once, prioritise ruthlessly. Guide the eye to the one thing that matters most.

Speed to signal

AppSignal exists to help developers find problems fast. Every choice should shorten the distance between opening the app and understanding what happened.

• Lead with the data that matters — status, metrics, error counts — not with navigation or settings.
• Use colour and hierarchy to make anomalies visible at a glance, without requiring the user to read every row.
• Always validate designs with real production data. Placeholder text and sample numbers hide layout problems that only surface with actual values. If you can't use live data, use realistic extremes: a six-digit request count, a three-line error title, an empty state with zero results.

Respect the context

Developers use AppSignal alongside their editor, terminal, CI, and a dozen other tools. Our interface should fit into that workflow, not demand full attention.

• Support keyboard navigation and shortcuts for frequent actions.
• Keep information density high. Developers expect data-rich interfaces, not oversimplified ones.
• Don't interrupt with modals or alerts unless the situation is genuinely urgent.