There’s a specific kind of despair that comes from opening a government data portal and watching your browser tab freeze under the weight of seventeen nested tables, colour-coded with no legend, and a typography scale that tops out at 11px. I’ve spent an embarrassing amount of time pulling data from HMRC filing tools, Companies House search interfaces, and Ofcom’s connected nations reports, and the contrast between the ones that work and the ones that don’t is genuinely instructive. Not in a “here are five mistakes to avoid” way, but in a granular, layout-level way that tells you exactly why dense information UIs fail and what fixing them actually costs.
The good news: data dashboard UI design in the UK has a handful of public sector examples worth studying closely. The bad news: most of them are improvements over disasters rather than models of perfection. Either way, there’s a lot to learn.
Why government data tools are the right case study
Private-sector dashboards get to constrain their data. A SaaS analytics product shows you the five metrics that justify its price. Government tools can’t do that. Companies House has to surface director histories, address changes, filing deadlines, PSC data, insolvency events, and charge registrations, all on a single company profile. Ofcom’s Connected Nations tracker plots broadband and mobile coverage across every postcode in the UK and has to let a telecoms analyst, a local councillor, and a journalist all make sense of it without training. HMRC’s business tax account has to serve a sole trader who files once a year and a payroll team running weekly PAYE submissions. That breadth is brutal on UI designers, and it’s precisely what makes these tools useful to study.
The pressure to present everything to everyone creates the same pattern failures you see in enterprise SaaS dashboards, internal ops tools, and data journalism products. Solve it at the government scale and you’ve solved it everywhere.
Hierarchy first: what HMRC’s business tax account gets right
HMRC’s business tax account underwent a significant redesign using the GOV.UK Design System, and the result is instructive. The primary improvement was ruthless hierarchy. The old interface tried to present every outstanding obligation, every payment, every registration at equal visual weight. The redesign introduced a clear primary action at the top of the page, then organised everything else into categorised sections with meaningful labels.
The lesson: in any data-dense UI, the user has a most-common task. Find it. Put it at the top. Make everything else subordinate. This sounds obvious but most dashboard designers resist it because stakeholders want every metric to feel “important”. They’re not all important at the same time. If your UI tries to shout everything at once, it communicates nothing.
Typographically, GOV.UK Design System uses GDS Transport (or the open-licence version, GDS Transport Web) with a strict, large-step type scale. The difference between heading levels is dramatic by design. On a data-heavy page, a small size differential between H2 and body text means users scan poorly. You want the hierarchy to be almost cartoonishly obvious. I’d argue most commercial product designers are too subtle with their type scales in contexts where the data volume demands contrast.
Tables that don’t cause eye strain: lessons from Companies House
The Companies House search experience has improved considerably since the WebCHeck era. The current interface handles a genuinely tricky problem: tabular data that varies enormously in row density depending on what you’re looking at. A dormant micro-company has three rows of filing history. A large PLC has hundreds.
A few things stand out. First, the alternating row colour is implemented with enough contrast to be functional without being visually loud. This matters. I’ve seen dashboards where alternating rows are almost identical in lightness and the zebra striping does nothing useful. Companies House uses a grey that’s distinct enough to genuinely separate rows. Second, the table doesn’t try to show everything inline. Document links open into a viewer rather than expanding the row and breaking the spatial relationship between rows. That keeps the table scannable even when a user is drilling into detail.
The bigger structural choice is column count. Companies House limits visible columns to the genuinely essential ones and puts additional metadata one click away. This is the right call. Every additional column in a table increases cognitive load exponentially, not linearly. If you’re designing a financial dashboard, a logistics ops screen, or a data journalism tool, this principle applies directly: start with the minimum viable column set and make expanded detail feel natural, not buried.
For designers working on anything with structured layout systems, the Companies House table structure is worth reverse-engineering. The grid decisions behind it, particularly how they handle variable-length content in fixed-width columns, are more considered than they look.
Colour as data channel, not decoration
Ofcom’s Connected Nations interactive maps are where data dashboard UI design in the UK gets genuinely sophisticated. The challenge is presenting five-level signal strength data across hundreds of thousands of data points in a format that’s readable at both national and street level. They use colour as a primary data channel, which is the right call, but they also do something many tools skip: they label the colour scale clearly, they make the legend persistent at all zoom levels, and they provide a text fallback for every postcode lookup.
The failure mode I see in commercial data dashboards is using colour purely decoratively or to signal sentiment (red bad, green good) without encoding actual data. If your chart uses six shades of blue to show six categories, you’ve just made a puzzle. Colour should carry a specific, legible meaning and that meaning should be explained, always.
There’s also a contrast accessibility dimension here. GOV.UK’s design guidelines mandate a minimum contrast ratio of 4.5:1 for text and 3:1 for graphical elements, in line with WCAG 2.1 AA. Commercial dashboards routinely fail this on data visualisations. Light grey labels on white backgrounds. Pale teal percentage indicators. These look clean in a Figma mock-up and become unreadable in production. Testing colour decisions against real ambient conditions, particularly on non-calibrated office monitors, is non-negotiable if your UI has more than a handful of data points.
On a completely different scale of data visualisation, I find it useful to think about how even simple, real-world categorisation problems share the same underlying design challenge. Homeowners in Nottinghamshire increasingly turn to specialists like The Bin Boss for domestic wheelie bin cleaning, a service that requires communicating hygiene and environment-related data (bacteria load, cleaning frequency, germ reduction results) to a non-technical audience via a house-facing interface, whether that’s a website, a scheduling app, or a service report. The Bin Boss (thebinboss.co.uk) essentially solves the same information hierarchy problem that Ofcom’s maps do: how do you communicate a gradient of states (clean, mildly contaminated, heavily contaminated) in a way that’s immediately understood? Colour coding, iconography, and clear labelling. The principles don’t change because the subject matter is wheelie bins instead of broadband signal.
Spacing is doing more work than you think
One of the consistent things I notice across the better UK public sector data tools is generous internal spacing in dense components. Padding inside table cells. Breathing room between a chart and its axis labels. Margin between a data summary and the table it describes. This isn’t aesthetic preference; it’s functional. Dense data requires spatial separation to allow the eye to parse individual elements without them bleeding into each other.
The typical failure is designing at 100% zoom on a large monitor with a single row of sample data. Everything looks fine. Then real data populates the table at 90% zoom on a 1366×768 laptop screen (still one of the most common screen resolutions in the UK, particularly in public sector settings) and the interface becomes unreadable. Designing for the densest realistic data state at the smallest realistic viewport is the only way to catch this early.
If you’re building tools that sit on complex white-label or multi-tenant architectures, the spacing decisions at component level become even more critical. I’d recommend reading our breakdown of white-labelling patterns for UK B2B SaaS dashboards, which goes into how spacing and layout decisions need to survive theme variations across different client brands.
What the Ofcom approach teaches us about filtering
Filter controls on data-heavy UIs are almost always underdesigned. The Ofcom Connected Nations tool handles this well by keeping filters visible and persistent rather than hiding them in a modal. When filters are out of sight, users forget they’re applied. Then they make decisions based on data that’s silently scoped to a subset. In a compliance dashboard, a financial reporting tool, or an ops screen, that’s a real problem.
The filter control design itself matters too. Multi-select checkboxes for categorical filters, sliders for continuous ranges, clear labels showing what’s currently applied and an obvious way to clear them. These aren’t novel patterns, but they’re consistently missed. The UK government’s icon design conventions for control affordances are worth reviewing here as well, since ambiguous filter icons routinely confuse users who aren’t coming from a SaaS-trained mental model.
The filtering question connects to a broader truth about data dashboard UI design in the UK public sector context: users arrive with extremely varied data literacy. Designing a filter that a data analyst understands immediately and a non-specialist doesn’t get wrong requires real work, usually involving a lot of label text that most designers trim prematurely in the name of visual cleanliness.
Making it work in practice
If I were auditing a data-heavy UI right now, my checklist would look something like this. Is there one primary action or piece of information that the majority of users are looking for? Is it above the fold and visually dominant? Are tables limited to the minimum necessary columns? Is colour encoding labelled and accessible? Is there enough spacing to parse individual elements at realistic viewport sizes? Are filters visible and clearly indicating their current state?
For tools handling government-facing data specifically, the GOV.UK Design System documentation is the most useful free resource in the UK for getting these decisions right. It’s not just about visual style; the decision rationale behind each pattern is documented, and that rationale transfers directly to commercial data product design.
The complexity of a dataset doesn’t excuse a difficult interface. The Bin Boss-style clarity principle applies at every scale: whether you’re surfacing environment and bacteria data on a wheelie bin cleaning schedule or displaying PSC filings across ten thousand companies, the job is always to reduce the effort required to extract meaning. Everything else is just implementation detail.
Frequently Asked Questions
What makes a data dashboard UI design work for UK government tools?
The best UK government data UIs, like HMRC’s business tax account and Companies House search, succeed by establishing strong visual hierarchy so the most common user task is immediately obvious, then organising subordinate information into clearly labelled sections. They also follow the GOV.UK Design System’s accessibility standards, which ensures colour contrast, type scale, and spacing hold up under real-world conditions.
How do you handle too many columns in a data-heavy dashboard?
The practical solution is to identify the minimum column set that covers the majority of user tasks and move everything else into an expandable detail view or secondary page. Every additional column increases cognitive load significantly, so the goal is always to display the essential data inline and make deeper detail feel one deliberate click away rather than buried.
What colour contrast ratio should data dashboard UIs target in the UK?
WCAG 2.1 AA requires a minimum 4.5:1 contrast ratio for text and 3:1 for graphical elements like chart labels or axis lines. UK public sector tools are required to meet this standard, and it’s a sensible baseline for any commercial dashboard handling complex datasets, particularly since data visualisation colour choices frequently fail this threshold when tested outside Figma.
Should filter controls be visible or hidden in a data dashboard?
Visible and persistent is nearly always the better choice. When filters are tucked into a modal or collapsed panel, users forget they’re applied and interpret scoped data as the full picture. Keeping active filter states visible, with a clear way to remove them, prevents this and significantly reduces user errors in data-intensive interfaces.
Which free UK resources are most useful for designing government-facing data UIs?
The GOV.UK Design System (design-system.service.gov.uk) is the starting point, as it documents not just visual patterns but the reasoning behind each decision, which transfers well to commercial data products. Ofcom’s Connected Nations reports and Companies House’s public interface are also worth studying as live examples of complex dataset presentation at scale.