a data-driven approach to UX and UI

We are re-engineering APAS, our planning and built-environment platform, into a true cloud-native SaaS product. That work is often described in infrastructure terms such as multi-tenancy, elastic scaling and continuous delivery, but for the people who use APAS every day, the change they will feel first is the interface. So alongside the platform rebuild we have been designing a new design system and working through several iterations of the key screens. 

This post explains how we are approaching that design: the principles guiding it, the evidence shaping it, and the first iteration our customers can already see taking shape. 

Planning officers, technical staff and validators spend much of their working day inside a system like APAS. They move between applications, consultations, documents and decisions, often under time pressure and against statutory deadlines. Small amounts of friction, such as a menu that hides the thing you need, a screen that buries the number that matters, or an action that leaves you unsure whether it worked, add up across hundreds of cases. 

A cloud-native rebuild gives us a rare opportunity to rethink the experience from first principles rather than carrying old constraints forward. We want the new APAS to be modern and fast, but above all we want it to be clear: information organised the way people actually work, so users can find what they need without friction. 

Everything starts with a shared design system. Rather than styling each screen individually, we are building APAS from a library of reusable components and consistent patterns, including accordions, dialogs, dropdowns, command menus, inputs, selects, popovers and hover cards, each with defined behaviour and a single, coherent visual language. 

A shared component library does two things. It keeps the product consistent, so an interaction learned on one screen behaves the same everywhere. And it lets the interface grow in a structured, maintainable way, which matters enormously when a platform is being rebuilt and extended at pace. The design system is the vocabulary; the principles below are the grammar that decides how we use it.

The first question on any APAS screen is not “how should this look” but “what matters most here”. We use visual hierarchy to answer it deliberately. 

Working from what we know about our users, the way they use the product and the devices they use it on, we rank the content on a screen by importance and structure the layout so the most important elements are given the most prominence. The highest-priority information and actions are placed and styled to draw the eye first, and supporting detail sits below. Done well, this means a user can glance at a screen and immediately understand where they are, what needs their attention, and what to do next. 

Visual hierarchy tells us how to arrange a single screen. Red routes tell us which screens and journeys to prioritise across the whole product. 

A red route is a critical path, a key task that users must be able to complete successfully. We identify these by looking at user behaviour: how often a task is performed, and how many people perform it. Tasks that are done frequently, by many users, are the journeys where friction is most expensive and where good design pays back the most. By mapping tasks against how often and by how many people they are carried out, we can concentrate design and testing effort on the journeys that genuinely matter, and remove friction where it counts rather than spreading attention evenly across features that are rarely touched. 

This is what makes the approach data-driven rather than decorative. We are not guessing at what belongs on a screen; we are using evidence about how APAS is actually used to decide. 

The two principles meet in the key screens. Once red routes tell us which tasks matter most, and visual hierarchy tells us how to rank content, we can take a first pass at what actually goes where on each screen, mapping prioritised content and actions onto the real APAS layout of header, search, primary panels and cards. 

The result is a modern UI built on data-driven UX principles: screens whose structure reflects real user behaviour rather than the historical shape of the underlying system.

Our first major iteration tackled one of the clearest sources of friction in the current product, which is navigating a large planning application. 

Previously, the many sections of an application were presented in a menu that users had to scroll through horizontally. Horizontal scrolling is slow to scan, easy to lose your place in, and gives no sense of what lies inside each section. We replaced it with a mini navigation menu inside the page: a vertical, grouped list of sections that stays in view as you work. 

Three changes make this more than a cosmetic swap: 

Users can filter the menu, typing to jump straight to the section they need instead of hunting for it. Each menu item carries a useful count alongside it, so the numbers that matter, such as replies received, consultees on the application, and media and documents attached, are visible at a glance without opening anything. And the sections are grouped logically (application, consultation, assessment, decision, property and records) so the structure mirrors the way a case actually progresses. 

Those counts are a small detail with a large effect. A validator or planning officer can see at once that an application has, say, five consultees and three replies outstanding, or twelve items of media to review, and prioritise accordingly. It is a direct application of visual hierarchy, surfacing the most decision-relevant information first, driven by an understanding of the red routes through a case. 

The same iteration also introduces simple reporting directly into the most common screens. In the video you can see a prioritised list of application decisions due soon, with filtering available across a number of key fields, so a user can narrow the view to exactly the cases they care about. 

APAS already has dedicated reporting dashboards for deeper analysis, and those remain. But much of the value of a report is lost if you have to leave your workflow to find it. So wherever it makes sense, we are bringing lightweight dashboard-style reports into the key screens themselves, putting the most relevant, time-sensitive information in front of users at the exact point they need it rather than in a separate reporting area. A prioritised, filterable list of decisions due soon is a clear example: it turns a routine “what needs my attention” question into something a user can answer at a glance, without navigating away. 

This is the same principle at work throughout the redesign. Red routes tell us which questions users ask most often, and visual hierarchy tells us how to surface the answers. Embedding simple reporting into the key screens is another way of removing friction from the journeys that matter most. 

A good interface is more than layout and navigation. As we build out the new APAS, the same design system carries a set of experience principles into every screen: 

Clear states for every moment. When the system needs time, the interface acknowledges the wait and shows progress, so users never wonder whether something has failed. When something goes wrong, error messages explain what happened and what to do next in plain language, placed where the problem occurred. When a task succeeds, the interface confirms it clearly, so users can move on with confidence. 

Language that guides. Microcopy, including button labels, field hints and confirmations, is written to be direct and human, reducing confusion and giving the product a consistent voice. 

Motion with a purpose. Micro-interactions and transitions confirm that an action has registered and help users stay oriented as they move between screens, without distracting from the task. 

Responsive by design. Flexible grids and scalable components let APAS adapt across desktops, tablets and larger displays, so the experience holds up wherever and however it is used. 

None of this is designed in isolation. The principles and iterations here are our informed starting point, not the finished answer. Over the coming period we will be engaging directly with current APAS customers, the planning teams who use the product day in, day out, to test these designs, challenge our assumptions and help shape the direction of the platform. 

That partnership matters. The red-route thinking behind this work depends on real behaviour and real priorities, and no one understands those better than the people doing the job. Re-engineering APAS for the cloud is our commitment to the platform’s future; designing it with our customers is how we make sure that future is one they actually want to work in. 

APAS is IEG4’s planning and built-environment platform. We are rebuilding it as a cloud-native SaaS product with a new design system and a data-driven approach to UX and UI. If you are an APAS customer and would like to take part in the co-design work, we would love to hear from you.