Hal McGonigle – Collective 2.0

01 — background

What was going on

Whitespace builds sovereign AI infrastructure for Government, National Security and regulated industries. Collective is the product at the centre of that: an AI operating system designed for organisations that can't hand their data to a third-party cloud and hope for the best.

When I joined Whitespace, Collective 1.0 already existed — a functional Chat Application built on OpenWebUI, shipped by Engineers as an MVP to get something in front of clients. It was templated software wearing a thin layer of Whitespace branding and a User Experience that left
a lot to be desired.

Collective 1.0 — the OpenWebUI MVP we were building on and needed to move away from

02 — problem

What needed solving

The experience of 1.0 was clunky, the architecture wasn't ours and we were layering new features onto a base that was never meant to carry them. Our primary internal users, the Solutions Engineering team who build client-facing applications on top of Collective, were running out of road. The requests coming in from our consultancy side of the business were getting more sophisticated and the platform couldn't keep up.

The business case was clear: we needed to own the platform end-to-end, migrate away from OpenWebUI and build something that could actually scale. Collective 2.0 needed to host apps we hadn't designed yet, support a future app builder for users to create their own, accommodate dynamic prompt-generated UIs and eventually support a knowledge graph approach. The shell had to be ready for things we couldn't yet define.

03 — Constraints & starting conditions

What I was working with

Having no Product Manager for the first five months meant I was gathering requirements myself, writing my own briefs and checking direction with the Head of Design. Architectural ambiguity was another challenge: designing a scalable shell without knowing what would live in it means every structural decision carries downstream risk. All of this, combined with a highly sensitive industry, direct CEO involvement in design direction and a design system that needed to work for both humans and LLMs, left little margin for error.

04 — process

How I worked through it

Discovery & framing I started with a classic UX audit, going through 1.0 feature by feature with the Solutions Engineering team to understand where the product was genuinely failing them. That grounded the work and shaped the feature prioritisation conversation with Engineering directly.

Exploring directions The double navigation problem (i.e. platform shell nav sitting on top of in-app nav) was the structural challenge that needed the most iteration. I looked at how other data-dense platforms handle layered navigation, dropped existing apps into different shell configurations to see how they actually interacted and built rapid prototypes with Claude Code to test interaction behaviours. The Companion AI sidebar was future-state but had to be designed for now: a detachable panel at the shell level, contextually aware of whichever app was open, present without being intrusive.

Testing & refinement Team testing drove most of the navigation decisions. For a product in a regulated environment with a small, specialist user base, internal SE sessions were the primary feedback loop. Direction was validated with the Head of Design and, as the product matured, signed off by the CEO.

Delivery & handoff I introduced Jira ticket templates, Figma file standards and annotated handoff documentation from scratch. On the design system side, I worked alongside the Design Systems contractor to build documentation for two distinct audiences: designers get rationale and guidance, LLMs get precise structural rules and unambiguous constraints. I brought learnings from a previous technical spike on dynamic UIs, where I'd been writing AI system prompts and pattern documentation designed to be machine-readable.

Early direction explorations — navigation configurations and different shell states

05 — solution

What shipped and why

A purpose-built sovereign AI platform with a scalable shell architecture: minimal global navigation at the shell level, a pattern library that codifies how apps interact with it and dual documentation built for both human designers and LLMs. The Operational Learning app, previously standalone in its own environment and built with Chakra, is the first application hosted in the new shell — the proof of concept that the architecture holds.

Collective 2.0 shell — minimal global navigation, built to host applications we hadn't designed yet

Operational Learning migrated into the new shell — the proof of concept that the architecture holds

06 — outcome

What it changed

Still in flight, with release preparation underway. The immediate measure is internal SE adoption: Solutions Engineers building on the new platform rather than working around the constraints of 1.0. The design system built for LLMs is something Whitespace hasn't had before and is already enabling the dynamic UI work. The process infrastructure such as Jira templates, Figma standards and handoff documentation, was recognised by senior stakeholders as a significant improvement in how Design and Engineering collaborate.

To get designs in front of stakeholders faster, I've been using Claude Code alongside Figma MCP to prototype directly from design files into a working frontend. It shortens the gap between Figma frames and something a stakeholder can actually interact with, which in a product this complex has made a real difference to how design decisions get made and signed off.

Collective 2.0 shell prototyped with Claude Code and Figma MCP

From Figma to working frontend — the Collective 2.0 shell prototyped end-to-end using Claude Code and Figma MCP

07 — reflection

What I'd do differently

I'd have pushed earlier for written requirements and formal sign-off during the period without a PM. Staying close to the Head of Design kept things on track, but verbal alignment in a product this complex isn't a substitute for a signed brief. I knew that and let it run longer than I should have, despite all my efforts to tighten up the process elsewhere.