Mirko Book a call

Case study · GroupNexus

Parking Operations & Intelligence Platform

Designing a complex platform that helps parking operators manage sites, permits, enforcement and ANPR infrastructure while turning millions of vehicle movements into actionable operational insights.

OutcomeCompany-wide, the network grew by 150 sites and the user base by 20% after the Permit & Form Builder launch.

  • UX Design
  • UI Design
  • B2B
  • B2B2C
  • Data Platform

Overview

The company

GroupNexus operates a technology-driven parking ecosystem connecting physical car parks, ANPR cameras, enforcement processes, permits, client reporting and millions of vehicle movements — a much more complex operational system than the simple parking journey drivers see.

Client
GroupNexus
Role
Lead UX/UI Designer
Date
Oct 2019 – Apr 2023
Scope
Design · MVP
Website
groupnexus.co.uk ↗
The permit Form Builder's Questions step: a five-step progress tracker above a list of form sections, with Employer details open to show its two questions, and Save as draft, Preview, Back and Next controls along the bottom The Insights Dwell Time screen: average dwell time as horizontal bars for four sites, with a tooltip on Drake Circus, Plymouth, above a by-site table of visits, vehicles and average dwell time

Brief

Turning a complex parking ecosystem into a usable product

My role was making that system easier to understand and operate: less friction in everyday workflows, and each user seeing the information and controls their job needs.

A CCTV notice above a no-smoking sign on a post in a hospital car park
Birmingham car parks with ANPR cameras installed
A 'Permit Holders Only' road sign above a 'Staff Permit Holders Only' parking notice
Hospital car parks restricted to staff permit holders
A car park payment terminal with 'Ways to pay' instructions
Drivers paying at the car park payment terminal
The GroupNexus exhibition stand, with banners for NexusPark, NexusFM and NexusInsights
The product family: NexusPark, NexusFM and NexusInsights

The problem

Complex workflows, fragmented tools and manual processes increased cognitive load and created opportunities for operational error.

The goal

Create clearer, faster and more scalable workflows without disrupting critical existing operations.

The outcome

A more consistent product experience across management, monitoring, permits, enforcement and analytics.

Users

One platform. Very different responsibilities.

  • Internal Operations

    Internal GroupNexus teams monitoring the network, reviewing ANPR activity, managing enforcement and spotting operational problems.

    Speed, accuracy, visibility

  • Client Administrators

    Manage users and permits for one or more car parks, and track occupancy, duration, visits and vehicle movements.

    Control and insight

  • Approvers / Restricted Users

    Support administrators with specific tasks, under controlled permissions rather than full platform access.

    Minimal complexity

  • Permit Applicants / End Users

    Drivers, employees, tenants and others applying for a permit.

    Fast, clear completion

The challenge

Designing around an interconnected system

A change to one workflow could ripple through several others. The chain below traces one example, from ANPR hardware to client-facing insight. The job was to keep each task simple without losing sight of that system.

  1. ANPR / Devices
  2. Vehicle movements
  3. Visits & occupancy
  4. Permits / Enforcement
  5. Operational & client insights
Parking Platform
Operations & Management

Configure and run the parking ecosystem.

  • Users & permissions
  • Enforcement
  • Permit & Form Builder
  • Device management
  • Camera monitoring
Insights & Analytics

Turn raw ANPR activity into information clients can act on.

  • Movements
  • Visits
  • Occupancy
  • Duration
  • Filtering

Process

How a feature moved from requirement to live

An Agile team: internal users and clients (B2B) came first, then end users (B2B2C). Product owners, engineers, developers and the business joined at the stages that needed them.

  1. UXRequirement, research, define
  2. UIWireframes, design, testing
  3. DevelopmentBuild, QA, UAT, production
  4. LaunchUser feedback, then maintain

Discover

Understanding the system before redesigning it

Before changing screens, I explored the product as a system and worked with users and stakeholders to find where friction occurred and which processes carried the most operational risk.

2 weeks

Research sprint for the permit builder

12+

Interviews across every user role

3

Roles interviewed: Admin, Request Approver and End User

Also in the sprint: existing and competitor solutions, SWOT analysis and affinity mapping.

Whiteboarding a workflow during the research sprint, mapping out the permit application and approval process by hand
Paper wireframes for the application builder: question setup, answer options and tariffs, the new-section modal, and the sections/questions/score/workflow step flow

Asked for in the interviews. End users: mobile first, single sign-on, Apple Pay. Admins: minimum user criteria, a workflow they can set up, and a tariff set from the answers.

What the research found

Too many steps

Common tasks needed several screens or configuration stages when one would do.

Manual set-up caused mistakes

Scoring rules, conditions and enforcement actions were configured by hand, which added effort and room for error.

Critical information was buried

Device health and questionable ANPR captures needed to be spotted at once, not found.

Journey map for Natalia Smith, an end user (B2B2C), whose goal is to apply for and pay for a permit. Five steps from registration to making changes, each with how she feels, what she thinks and what the service side should do about it
Journey goal: apply for and pay for a permit

Define

Simplify the task, not the capability

The product had to support sophisticated parking operations without showing that complexity to every user equally. I used progressive disclosure, clearer hierarchy, reusable patterns and role-based access.

Clarity before density

Prioritise the information required to make the next decision.

Automate repetition

Reduce unnecessary manual actions where rules could safely handle them.

Design around roles

Expose functionality according to responsibility and permission.

Create reusable patterns

Solve recurring interaction problems consistently across the platform.

Information architecture of Permit Management: four areas (Permit application, Permit groups, Change requests, My activities), the states inside each, and which of five roles sees each state
Permit Management: four areas, their states and the five roles that see each

Feature deep dive · Permits & Form Builder

Making complex permit rules easier to configure

Administrators needed to construct permit applications with different questions, scoring requirements, conditions, permissions and approval rules. The original process took too many steps and too much manual configuration to get right.

The problem

The number of permit requests from end users was too large to be managed individually.

The objective

Design an end-to-end feature, starting with an MVP that streamlines car park permit requests and improves efficiency.

Faster form construction

Made relevant controls available closer to the object being edited, rather than forcing users through repeated multi-step navigation.

Clearer scoring logic

Made minimum requirements, automatic-rejection rules and scoring behaviour easier to understand before publishing an application.

Conditions & automation

Let actions and outcomes respond to predefined conditions, rather than requiring administrators to manually process every scenario.

The research sorted into three buckets: an application builder for custom permit forms, change requests so end users can update an active permit instead of resubmitting, and usability wins such as autofill in the application itself.

The Form Builder's Settings step: form name, application window, applicant attempt limit and a site-selection table, with a five-step progress tracker across the top
The Form Builder's Set score step: optional per-question scoring thresholds against the same five-step progress tracker
The 'Calculate permit application score' panel with two conditions: scores 0 to 100 reject the application and send a text message; scores 101 to 300 approve it, allocate a car park and send a text message
2021 designConditions and actions: reject, approve, allocate or send a text message
The template builder: a document canvas with a heading and a text block, empty layout sections, and a tools panel for headings, paragraphs, dividers, images and dynamic code
2021 designTemplate builder: permit and PCN documents assembled from content blocks
The application itself, on tablet and phone: an Oxford University car park permit form on step 2 of 6, entering vehicle details with the fields pre-filled and auto-confirmed
End users get a mobile-first application, as the interviews asked

Working within a live product

LegacyNot everything could be redesigned at once, so new flows sat beside older ones.

Live operationsChanges to enforcement, ANPR or devices had operational consequences, so simplicity was balanced with control and accuracy.

EngineeringSolutions reused the existing architecture and components instead of adding bespoke behaviour.

Feature deep dive · Permit management

Everyday permit work in fewer clicks

Administrators approve, reject and edit applications, group permits, and renew or end many at once. Two decisions kept the screen calm: show the next action where it is needed, and keep rarely used actions out of the way.

Permit management inside the NHS_MFT-1 group: three status cards (Active 57, Inactive 132, Expired 2K), a permit table with four rows selected, and a bulk action bar with End permits, Renew permits and More actions
2021 designInside a permit group

  1. Status cards

    Permits grouped as Active, Inactive and Expired, each with its own actions.

  2. Bulk selection

    Select several permits to renew or print in fewer clicks.

  3. A tidy action bar

    End permits in red as a warning, Renew as the main action, and print or download behind More actions.

Application states A new application waits for approval. Approving it moves it to Pending payment, then Payment received, then Paid. Rejecting it, or a low score, moves it to Pending rejection. From there the rejection can be approved, which makes it a Rejected application that can be restored to Waiting approval, or the rejection can be rejected, which returns it to Pending payment.
How an application moves between approval, payment and rejection

RuleOnce an application is paid, it never moves back to Waiting approval.

Feature deep dives · Monitoring & Insights

Keeping cameras reliable and data readable

Device & camera monitoring

A camera that stops working means missed vehicle activity, so device health was an operational and commercial issue, not a technical detail. The views make abnormal states easy to spot, show which problems need attention first, and give operators the site, camera and vehicle context to check an ANPR read without extra navigation.

The Operations overview: a donut chart of 55 open issues by device type, a table of the last 10 issues with status and priority, and a map of device locations across the UK
Operations overview: issues by device type, status and priority

Insights

ANPR produces large volumes of movement data. Matching entry and exit for the same VRM makes a visit, which turns camera events into occupancy, duration and visit counts that clients can filter by site and date. The old donut-chart filter stopped working past ten selections, so filtering moved to a multi-select dropdown with removable chips.

The Insights 'Activity' screen: a line chart of visits over 24 hours for four sites, a site filter, and a by-site data table with visits, vehicles and movement counts
Shipped Feb 2022Visits over 24 hours across four sites

Design system & accessibility

Creating consistency across a growing product

As the product grew, reusable patterns for navigation, tables, filters, forms, status and feedback shortened the learning curve between areas and made hand-off to development easier. Accessibility was part of product quality, not a separate visual exercise.

The component library in Figma: colour palettes, effects, desktop and mobile type scales, data table components, icons, avatars, and buttons with their states
The component library in Figma: colour, effects, type, data tables, icons and buttons

Accessibility in the product

The Accessibility Settings panel: text size (regular, medium, big), colour settings (grayscale, high contrast, invert colours) and keyboard behaviour (highlight mandatory fields, arrow, Esc and spacebar hints)
Accessibility settings: text size, colour modes and keyboard behaviour
Before

2.56:1, white on teal

  • AA Large: Fail
  • AAA Large: Fail
  • AA Normal: Fail
  • AAA Normal: Fail
After

5.00:1, white on a darker teal

  • AA Large: Pass
  • AAA Large: Pass
  • AA Normal: Pass
  • AAA Normal: Fail
The teal behind white text failed every WCAG level in a contrast checker; the darker teal passes AA for normal text.

Validate

Testing the workflows that mattered

Designs were reviewed and tested around real tasks, and what we saw went back into the design before implementation. Every chart and filter variation on the Insights side was validated with real users before it reached stakeholders or engineering.

  1. Configure a permit
  2. Modify application logic
  3. Review vehicle activity
  4. Find a specific visit
  5. Filter analytics
  6. Check system or device status

Selected screens

One ecosystem, designed around different jobs

A large set of operational tools in one consistent system, so users can move between configuration, monitoring, enforcement and analysis without relearning the product.

Permit management inside a group: status cards, a selectable permit table and a bulk action bar
Permit management · 2021
The Add permit dialog, step 2 of 2, over the permit list
Add permit · 2021
The Edit permit dialog over the permit list: permit holder details, vehicle details, permit duration and timings, with a note to submit a change request to edit any other field
Edit permit
The form builder's question setup panel in the 2021 concept: the question, a mandatory option, answer type icons and answer options with tariffs
Question setup · 2021 concept
The same question setup panel as shipped in 2022: the question, a mandatory checkbox, answer type icons and answer options with tariff amounts
Question setup · 2022 release
The template builder: a permit document canvas with a content-block tools panel
Template builder · 2021
The Operations overview: issues by device type, the last 10 issues and three charts
Operations · 2021
A single camera issue, DVC-83: duration, location, status, assignee and priority, three metric charts and a comment thread
Device issue · 2021
A full-screen events chart with the custom period drawer open, a calendar and a time slider
Device events · 2021
The Insights Activity screen: visits over 24 hours for four sites, with a by-site data table
Insights · Activity
The Insights Dwell time screen: average dwell time as bars per site, with a by-site table
Insights · Dwell time
Movements and Visits: two periods compared side by side, with a ranked chart of visits by car make
Insights · Compare periods · 2021

Screens marked 2021 come from my design files at the time. The product has evolved since.

Impact

What happened after the Permit & Form Builder launch

The feature launched in September 2022. These are company-wide results after the launch, not design metrics from an isolated test. GroupNexus also welcomed new clients, including the NHS and PureGym.

Network growth

+150

Sites the network grew by after launch.

User growth

20%

Growth in the user base over the same period.

Usability measures such as task time and error rate aren't reported here: I don't have verified figures for this release.

Reflection

What this project taught me

Simplifying an enterprise product doesn't mean removing capability. The strongest improvements came from deciding what a user needed at that moment, and from understanding how users, workflows, data and devices affect each other before designing any single screen.

What we learned after launch

  • End users often entered the wrong VRM, which had a big impact on Enforcement.
  • To prevent duplicates, a user can apply for a specific application only once.

What I would do differently

  • Add auto-save.
  • Show an application's progress at a glance.
  • Add a notification system.

Portfolio

Explore additional projects

Next

Building something similar?

I help teams turn scattered products into systems people can actually use, from research through to a design system developers can build from.

Book a 15-min intro call ← Back to selected work