Dashboards & tools
A dashboard is a tool for looking at information and deciding what to do next. Whether it is an internal reporting view, a client portal, or a small piece of software that removes a repetitive task, the goal is the same: less hunting, more knowing.
- Typical build
- Reporting views, internal utilities, client portals
- Data sources
- Spreadsheets, databases, forms, existing platforms
- Designed for
- Decisions, not decoration
- Handover
- Documentation and a walkthrough
The short version
The answer exists. Finding it is the problem.
Most teams do not lack information. They lack a place where that information arrives in a form that supports a decision. The number lives in one tool, the context in another, and the person who needs it is somewhere else entirely.
A good tool closes that gap. It shows the same truth to everyone, explains what each number means, and makes the next step obvious enough that nobody has to ask for a screenshot.
What I build
Reporting views
A single page that answers the questions a team asks every week: what happened, compared to what, and what changed since last time. The view is designed around those questions, so the layout does not have to be rediscovered every Monday morning.
Internal utilities
Small tools that remove a specific, repeated piece of work: producing a weekly summary, checking a form submission, generating a handover document, or moving a record from one place to another. Deliberately narrow, and easy to explain to the person who will use it daily.
Client-facing portals
A place where a customer can see their own status, their own files, and the next thing expected of them. The value comes from removing the status question, not from adding features.
Definitions and documentation
The part that decides whether a tool is trusted: what each measure means, where the data comes from, how often it refreshes, and what happens when it does not. This usually lives next to the tool rather than inside it.
How I keep it honest
A tool that hides its own weaknesses is worse than no tool, because people will still trust it. These are the rules I build to.
- One definition per measure. If two teams mean different things by a number, the tool has to settle it, and the definition belongs where everyone can read it.
- Visible states. Loading, empty, stale, and error states are designed, not accidental. A number from yesterday should not look like a number from right now.
- Access follows need. People see what they are allowed to see, and the interface never displays what it should not, including in exports and cached views.
- Accessible by default. Keyboard support, readable contrast, and semantic markup, because a reporting tool is used in a hurry and often on a bad screen.
- Fast enough to open daily. If a tool takes ten seconds to load, people will go back to the spreadsheet. That is the whole problem returning.
- Documented for the next person. Not just how it works, but why it is shaped that way, so it can be maintained without archaeology.
Where it fits
A good fit
- A team that answers the same reporting question repeatedly
- A service business tracking status, capacity, or delivery
- A small operations group buried in spreadsheets
- Anyone who needs customers to see status without asking
Not the right shape
- A warehouse-scale data platform with a dedicated team
- Analytics that only need to be read once a month
- A product that needs thousands of daily active users on day one
- Reporting built on numbers nobody can define
Questions about dashboards and tools
Do you work with the tools we already use?
Usually yes. A dashboard often sits on top of a spreadsheet, a database, a form, or a platform you already pay for. The work is usually about making those sources legible in one place rather than replacing them.
How do you decide what a dashboard should show?
By starting from the decision. I want to know what someone does differently depending on what they see. Anything that does not change a decision is a candidate for leaving out, however interesting it looks.
Can the tool handle permissions and private data?
Yes, and that is part of the design rather than an add-on. Access is scoped to what each person needs, and the interface never displays data a viewer is not allowed to see, including in exports and caches.
What happens after it is built?
You get documentation, a walkthrough, and a way to keep the tool healthy. That usually means a short handover, a simple way to report an issue, and a plan for what to review when the underlying data changes.
Related work
Dashboards rarely stand alone. Connected systems keep the data moving into them, web experiences give the outward-facing side of the same information a clear shape, and search and growth help the right people find the pages that explain them.
Too much hunting?
Tell me the question that keeps getting asked, or the task that keeps getting repeated. That is usually where the useful tool starts.