From Backend to Front Line: Designing Dashboards That Anyone Can Use in 60 Seconds

Isaiah Udoh — Thu, 23 Apr 2026 11:07:17 +0000

When a powerful tool is built for engineers but needs to work for everyone else, the design is not a cosmetic layer – it is the product.

By Isaiah Udoh UI/UX and Graphic Designer, UK

There is a category of software product that most UX designers rarely think about when they are starting out, but that they encounter constantly once they are working inside real organisations. It is the internal tool – the dashboard that was originally built by developers for developers, held together by the logic of its own data model, and never really designed for the person who will ultimately have to use it in the field.
I want to talk about what happens when that kind of product has to change. Not because the developers did anything wrong – in many cases, they built exactly what was needed at the time – but because the audience for the tool shifted, the product had to grow, and suddenly the gap between how it was built and how it needed to be used became a design problem that could not be ignored.
This is the kind of challenge I worked through during the redesign of a complex sustainability data dashboard – originally an internal tool for developers and later a client-facing product used by operations managers at live venues, with no training, on their phones, in the middle of events. What I learned in that process has shaped how I approach data-heavy design work ever since.

The Problem with Developer-First Dashboards
Developer-built internal tools tend to share a set of common characteristics. They show all the data. They prioritise completeness over comprehension. They assume the user already knows what everything means. They are not mobile-responsive, because they were built to be used on a desktop, in an office, probably by the person who built them.
None of these things are failures. They are appropriate trade-offs for the original use case. The failure only happens when that same tool is handed to a non-technical user who needs to answer a specific question quickly, in a high-pressure environment, with no manual and no help desk on call.
What I saw in the original product was a wall of data. Information was correct and real-time, but it was presented as if its only purpose was to exist. There was no hierarchy that told the user what to look at first. There was no separation between information you needed to act on urgently and information you might want to review later. Everything competed equally for attention, which meant nothing was actually communicating anything useful.
The question I started with was not 'How do I make this look better?' It was, 'What does this person actually need to know, and when?'

Starting with the User's Moment, Not the Data Model
One of the most important shifts I had to make early in this process was to stop thinking about the data and start thinking about the person using it. A dashboard is not a database. A dashboard is an interface between a person and a decision they need to make.
The typical user of this kind of platform is not sitting at a desk with time to explore. They are standing at the side of a pitch, or in a corridor, or at a festival site, holding a phone with one hand, and they need to know whether something is working or whether they need to act. That context changes everything about what belongs on the screen.
The first structural decision I made was to separate two types of information that had previously been mixed together: impact metrics and operational metrics. Impact metrics are the longer-term data – environmental outcomes, cumulative numbers, and reporting information that tells a story about progress. Operational metrics are the real-time stuff – where things are, whether the system is working or whether anything needs attention right now.
These two types of information serve completely different cognitive modes. Mixing them forces the user to mentally sort through them constantly. Separating them lets the user choose which mode they are in when they open the product.

Zero-Training Design: What It Actually Means
I want to spend some time on this idea because I think it is frequently misunderstood. Zero-training design does not mean making an interface so simple that it is stripped of functionality. It means designing so that the interface itself is the instruction manual – so that the layout, the hierarchy, the labels, and the visual language do the work of orientation that training would otherwise have to do.
In practical terms, this involved several specific decisions. I introduced a real-time location monitor that pulled from multiple sites simultaneously but displayed each site clearly with visual state indicators – so a user looking at the screen for the first time could understand the system status without needing to know how the underlying technology worked. The information was labelled in plain language, not in technical nomenclature. Status was communicated through colour and iconography that was consistent and predictable, not clever.
I also had to think carefully about what happened when things went wrong. Error states in developer tools often show raw error messages – useful for the developer, but meaningless or alarming for the operations manager. I replaced these with plain-language status descriptions and, where possible, with a suggested action. Instead of 'API timeout - 503'. Something like 'Some data isn't loading right now – try refreshing in a moment.'
This is not a complicated idea. But it requires someone to make the decision that the user's experience of an error is a design problem, not just a technical one.

The Practical Framework: How to Approach This Kind of Redesign
If you are working on a similar problem – transforming an internal or developer-built tool into a user-facing product – here is the process that I found most useful and that I would apply again.
Start by identifying the three questions the user needs to answer most frequently. Not all the questions the tool can answer. Just the three they come back for every time. Design for those first. Everything else is secondary until those three are working.
Then separate urgent from non-urgent information. Anything that requires action goes at the top of the hierarchy, with visual weight that communicates urgency. Anything that is useful but not immediately actionable goes below it or behind a secondary navigation. This is not about hiding information – it is about giving the user's attention a clear starting point.
Then audit your labels. Every label in a developer tool is a candidate for replacement. Ask yourself: would someone who has never seen this product before know what this means? If the answer is no, change it. The technical term can go into a tooltip or a help section. The primary label should be what the user would call it themselves.
Finally, build for the worst screen size and the worst context of use. If the tool needs to work in a stadium, design for a four-inch screen in a dimly lit corridor. If it passes that test, it will work fine at a desktop. The reverse is not true.

Scalability Across Different Contexts
One specific challenge in this kind of work is that dashboards built for organisations often need to serve multiple client types simultaneously. A sports stadium has very different operational vocabulary and very different information priorities from a retail chain or a hospitality group. But the underlying data structure may be identical.
The solution I found most effective was a flexible component architecture – building the dashboard not as a fixed layout but as a system of modules that could be arranged and configured based on the client context. The operational real-time monitor is always present for venue clients. The reporting and impact data is always present for sustainability managers. But the layout, the labelling, and the emphasis can be adapted without rebuilding from scratch.
The key discipline here is to design the system before you design the screen. If you jump straight to layout, you end up with a beautiful screen for one client that breaks for the next. If you design the component rules first – what information each module contains, how it scales, how it reacts to different data volumes – the screen layouts follow naturally and consistently.
What I Would Tell Other Designers
Dashboard redesign is one of the most undervalued skills in UX practice, partly because it lacks the glamour of consumer product design and partly because the results are often invisible to anyone outside the organisation. But it is some of the most consequential design work you can do, because the people using these tools are making real operational decisions based on what they see.
The principles I have described here are not specific to sustainability platforms or venue management. They apply to any situation where a data-heavy tool needs to be understood quickly, by a non-specialist, without a training session. That situation comes up in healthcare, in logistics, in finance, and in education. It is everywhere.
The designers who do this well are the ones who are willing to resist the temptation to show everything, to slow down and ask what the user actually needs in this moment, and to treat the act of comprehension – of genuinely understanding something – as a design outcome worth designing for.

A Final Thought
There is something instructive about the moment when someone who has never used your product opens it for the first time and immediately knows what to do. It looks like magic, but it isn't. It is the result of someone having spent a lot of time thinking about exactly that moment in advance.
A well-designed dashboard does not just organise information. It models the user's mental state at the moment they open it, and it gives them a clear, direct path to the thing they need. That is a hard problem. It is worth doing properly.

Isaiah Udoh is a Graphic and UI/UX Designer with over 9 years of experience. He holds a Master of Design from the University of Derby and currently leads UI/UX design across sustainability technology products. You can find him on LinkedIn at linkedin.com/in/isaiahudoh.

DEV Community: Isaiah Udoh

[Boost]

From Backend to Front Line: Designing Dashboards That Anyone Can Use in 60 Seconds

From Backend to Front Line: Designing Dashboards That Anyone Can Use in 60 Seconds