Active Cloud Management (ACM): From internal chaos to market ready.

The origin

I didn't win this project through a pitch. In 2023, I built a personal CRM prototype to help manage my family's property rental business, just a practical tool designed around real workflows. Paul Osborne, a business mentor connected to my agency, saw it and recognised something: that the way I'd thought through the user experience suggested I could untangle something far more complex.

Paul was CFO at Transforming Learning Group at the time. TLG had developed an internal tool called ACM (Active Cloud Management) and they had a problem. He connected their development team with Upshot, and I was brought in as Lead UX/UI Designer.

What ACM was

ACM was genuinely sophisticated software. It pulled live pupil and staff data from a school's MIS platform, mapped pupils to teachers and year groups, and then provisioned the necessary user accounts and workspaces across Microsoft 365 or Google Workspace - automatically, at scale, across primary and secondary schools throughout the UK.

The technology worked. The interface did not.

Built by an engineer for internal use by technicians who already understood the system, ACM had never been designed for anyone else. TLG's ambition was to commercialise it — to make it a product that any school IT administrator in the country could pick up and use. That ambition had a significant obstacle: the software was so unintuitive that TLG had deployed an entire team just to document it and train people how to use it. Without that hand-holding, users regularly made critical configuration errors — errors that could require a full system reset to resolve. In school IT terms, that meant bricking the infrastructure that managed every pupil and staff account in the building.

The question wasn't "how do we make this look better." It was "how do we make this safe enough and clear enough that it doesn't need a training programme to operate."

Understanding the problem

I started where the software started, with the engineer who built it. Over several video sessions, I worked through the full depth and breadth of ACM's functionality, asking questions and building a mental model of what the system was actually doing beneath the surface. In between those sessions I spent time in a staging environment, navigating the software myself, deliberately trying to break things and understand why.

Once I knew the system well enough to have opinions about it, I arranged interviews with three other people: a developer on the TLG team, a school IT administrator who used the software regularly, and a training advisor — the person whose job it was to teach others how to use ACM. That last interview was particularly revealing. The training advisor knew exactly where every user got stuck, where confidence collapsed, and which parts of the software required the most explanation. They were, in effect, a living map of the interface's failures.

Two distinct problems emerged from this research:

Problem one: no safeguards. The software had no guardrails between a user and a catastrophic mistake. Critical configuration steps had to be completed in a specific, undisclosed order — undisclosed because there was nowhere in the interface that communicated it. Users who didn't already know the correct sequence could, without any warning, trigger errors that required a complete system reconfiguration to resolve.

Problem two: no identity for non-technical users. A significant part of ACM's intended value was giving school stakeholders — headteachers, department heads — visibility and transparency over their IT infrastructure. But those users were presented with the same interface as the technicians doing the configuration work. For a headteacher, ACM was not just unusable; it was completely unrecognisable as something relevant to them.

These were two different classes of problem, and they needed two different classes of solution.

The approach

I started with wireframes, not visuals. Opening Figma to make things look polished before the underlying flows were resolved would have been the wrong instinct — and it would have produced a more attractive version of the same broken experience.

Working from use cases and expected user paths, I mapped out how each user type needed to move through the system. I tested wireframe concepts with technicians trying to complete simple tasks, which quickly surfaced assumptions I'd made that didn't survive contact with real users. Each round of testing produced refinements. Only once the flows and UX decisions were resolved did I begin applying TLG's specified PrimeOne UI kit as the visual layer.

The single most significant design decision of the project was the setup wizard.

The original ACM had no guided onboarding. Users were dropped into the system and expected to know, somehow, the correct sequence of configuration steps. Getting it wrong didn't produce a helpful error message. It produced a broken system. The setup wizard enforced the correct path before a user could access anything else, eliminating the possibility of critical early configuration errors entirely. Once setup was complete, a persistent visual status layer gave users, including non-technical stakeholders, a clear, readable picture of what was working, what wasn't, and whether anything needed attention.

For the headteacher who'd previously found ACM unrecognisable, that status layer was the entire product.

Throughout the project I maintained close collaboration with TLG's development team, providing detailed design annotations and rationale documentation so that the reasoning behind each decision wasn't lost in translation during build. The goal was to make sure they weren't just implementing screens, they were understanding the thinking behind them.

The outcome

The project ran from November 2024 to January 2025. By the end, ACM had moved from an internal tool that required a dedicated training programme to operate, to a product with a guided onboarding experience, role-appropriate interfaces for technicians and stakeholders, and a visual system built to scale as new features were added to the roadmap.

Formal metrics weren't captured within the project timeline, but qualitative feedback from ACM users, training advisors, and TLG stakeholders was unanimously positive - a meaningful contrast to a starting point where the software had been, by their own admission, too difficult to use without significant external support.

If I were to do this project again with more time and budget, I'd have pushed harder for usability testing with a broader set of school IT administrators earlier in the process, and I'd have involved headteacher-level stakeholders in the research phase rather than designing for them based on secondhand insight. Those are the gaps I'd close first.