Design principles

The core beliefs that guide every design decision across AppSignal. When priorities conflict, these principles help us choose.

Earn every pixel

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

In practice:

  • 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 instead of showing it by default.
  • When two components compete for attention, the one tied to the user's current task wins.

 

Less is more

Simplicity is not a style preference. It is a design strategy. Every element, every component, and every 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 a single edge case adds maintenance cost and cognitive load without earning its place in the system. If the answer to either question is uncertain, solve the problem with what already exists.

In practice:

  • For every element on a page, be able to explain why it's there. If you can't, remove it.
  • Before proposing a new component, check whether an existing one can do the job. New components should have a clear, recurring use case, not a one-time need.
  • When a page tries to communicate too many things at once, prioritize ruthlessly. Guide the user's eye to the one thing that matters most.

 

Speed to signal

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

In practice:

  • Lead with the data that matters — status, metrics, error counts — not with navigation or settings.
  • Use color 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 issues that only surface with actual metric values, long error messages, or large datasets. If you can't use live data, use realistic extremes — a 6-digit request count, a 3-line error title, an empty state with zero results.

 

Interaction cost

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

For example, a field label that says the following costs attention without adding information:

Don't

A field label that says the following costs attention without adding information.

Do

Instead, prefer the following approach, it costs the same attention but earns it.

 

Respect the context

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

In practice:

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