From 9 months of spreadsheets to a digital scheduling solution

01 · Overview

Overview

Training Schedulers (TSs) had to produce an training schedule across 21 sites, with every resource and dependency fitting a set of planning constraints. An earlier system had been built for this, but people stopped using it because it was flawed. They went back to spreadsheets and emails, and the planning of feasible schedule took about 9 months.

The manual schedule planning was a tidious job which didn't allow the allocation of resource in advance, Schedulers would only do this 8 weeks prior.

The new system takes in a large set training and course data, and generates a schedule that deconflicts resources and dependencies automatically. I joined as the only UX designer on the build and became Lead UX Designer in the last year.

02 · The problem

The problem

• Slow, manual planning. 9 months of spreadsheets and emails to reach one feasible schedule.
• Low trust. Users had already abandoned one system, so this one had to earn their confidence.
• Complexity. 6 user roles, 21 sites and many dependencies and constraints.
• Standards. The service had to meet the client's design standards, GDS and WCAG 2.2.

03 · Research

Mapping the whole service

Process-mapping workshops

Working with 2 business analysts and a service designer, I presented a draft process map to stakeholders to validate it and fill knowledge gaps. In workshops, stakeholders placed sticky notes wherever they felt they belonged. I then translated those business-as-usual notes into user requirements the team could design and build.

Service Blueprint

The Blueprint showed what the screens alone would have hidden:

• back-end data calculations the engine considers
• background processes running alongside the workflow
• business activities that were out of scope
• handovers and approvals between user roles

04 · Design

Designing faster, more consistently

Wireframing took too long, components didn't match across the design team, and developers ended up building inconsistent versions. I built a UI kit aligned to the client's standards.

Each component is labelled with when to use it. Add: time saved, e.g. prototype build time before and after. Note that how-to-use docs are still to be written.

The hardest problem: changing a live schedule

Planners need to change parts of an existing schedule, adding, removing or editing items, while every resource stays deconflicted. Rather than pushing back on costly requirements, I found workarounds and tested them with users to see which gave the most value without too much time or effort.

Add: how you solved it, e.g. a preview of changes, conflict warnings or confirmation steps.

05 · Testing and accessibility

What testing changed

Usability testing uncovered further requirements and scheduling rules nobody had considered. That caused friction: users felt testing something that didn't yet produce feasible results wasn't worth their time. So we validated the new requirements, made sure developers understood them, and tested internally before taking the product back to the client for UAT.

The audit found poor colour contrast, confusing form labels, and colours that were hard to perceive for users with dyslexia. A deeper audit is planned.

06 · Launch and adoption

Designing for adoption

The old system failed because people didn't use it, so adoption was a design problem too.

1. 01Discovery
2. 02Design and build
3. 03UAT
4. 04Live pilot
5. 05Dual running

• Ran adoption training workshops, which also uncovered bugs and improvements.
• Wrote 5 support materials: an end-to-end workflow guide, a Change Request guide, an FAQ built from questions raised in UAT, pilot and dual running, a best-practice and troubleshooting guide, and a video demo.
• Tracked 96 tickets during dual running: questions, bugs, improvements and new requirements. The most important were anything stopping users doing what they could already do in spreadsheets.
• Improvements identified included Gantt chart functionality, a dashboard with infinite scroll and a more concise solution metrics page.

07 · Outcomes

Outcomes

• 21sites planned in one service
• 100+users across 6 roles
• 96dual-running tickets tracked
• ?time to a feasible schedule (was 12 months)

Add: how many users actively use it compared with the old system, and whether the 96 tickets and audit issues were resolved.

08 · Reflection

What I learned

• Draft for you to review: keep research findings visible. Some requirements raised early were deprioritised and later requested by users.
• Add 1–2 more: what leading the UX taught you, and what you'd measure earlier next time.