Case Study · Brain in Hand · 2023

From fragmented workflows to a single source of truth

A B2B SaaS platform serving 25,000 neurodivergent individuals had a data problem nobody had named yet. The real cost was carried by the people working around it every day.

Role

Lead Product Designer

Sector

B2B SaaS · Higher Education · Local Government

Team

PM, Business Analyst, Dev Team, CST Lead

Timeline

March to September 2023 · 6 months

The Context

The tools had multiplied.
The truth had not.

Brain in Hand is a regulated, cloud based platform used by universities and local authorities to support neurodivergent individuals through daily life. When someone is referred to the service, a 90 day registration window opens. The Customer Service Team must coordinate that user's journey to activation with no automated status tracking, no shared system, and no single view of where anyone is in the process.

Data had grown organically across three separate platforms: Insightly for CRM, FreshDesk for support, and the core Brain in Hand platform for registration and licencing. None of them talked to each other. Changing privacy laws had added a compliance deadline to a structural problem that already existed: user data hosted on US servers needed migrating to UK infrastructure. That migration couldn't happen safely until the data architecture made sense.

The core problem wasn't a lack of data. It was that the data was invisible and disconnected, scattered across systems that had no way to talk to each other.

CRM

Insightly

Referral source, org details, contact records

Support

FreshDesk

Support tickets, communication history, case notes

Platform

Brain in Hand

Registration status, package type, licence data

Product Context

Three platforms. No shared view. A compliance deadline that made the status quo unsustainable.

Design Principle

The architecture problem had to be solved before the interface problem could even be defined.

Diagram showing Brain in Hand data split across separate systems with no single source of truth
SAS Platform: Internal
CRM: Insightly
Support system: FreshDesk
"

We give 90 days for a registration to be completed. As there are no notifications about status updates, it means constant checking. And the days remaining have to be calculated manually each time.

Jo, CST Lead

What I Found

The CST weren't the problem.
The tools hadn't kept pace with the work.

I didn't rely on process documentation. I spent several sessions shadowing the CST as they managed active user registrations in real time, watching their screens, listening to how they described their work, and noting where friction had become part of the daily rhythm.

What I witnessed was a team of highly skilled professionals who had built a sophisticated system of workarounds: personal spreadsheets for tracking 90 day windows, sticky notes for case status, manual calculations repeated every time someone checked a user's progress. This wasn't inefficiency. It was competence working harder than it should have needed to.

The workarounds weren't problems to design around. They were precise requirements that only became visible through direct observation.

90
Day window, calculated manually each time
3
Separate tools for every user lookup
0
Automated notifications or status alerts
25k
Users managed across this process

Product Context

The CST's workarounds, spreadsheets, sticky notes, and manual countdowns, were their actual workflow. Hidden expertise the system had not yet been set up to support.

Design Principle

Shadowing surfaces what documentation misses. The requirements were already there. They only became visible through direct observation.

Workflow map: processing a referral end to end

Early Ideation

One profile or many? Testing the structural question before committing to a direction.

At this stage the central question was structural: one profile or many? The scamps were testing whether consolidation was even possible without creating a view so dense it became unusable. The answer shaped everything that followed, a single profile with a subnavigation that let CST members move between depth and speed depending on what they needed in the moment.

Early scamping: testing whether a single profile view could replace the three tool lookup without losing the context CST members needed

The Work Before the Interface

Every incomplete registration was someone who didn't get the support they needed.

Brain in Hand exists to help neurodivergent people live more independently. When a referral comes in, a 90 day window opens. If that registration isn't completed because the CST couldn't track where it was, couldn't see what was blocking it, or couldn't find the information they needed without switching between three separate systems, that person doesn't get access to the platform. For a neurodivergent individual waiting on support, that's not an administrative failure. It's a gap in their daily life.

For the company, every incomplete registration represents lost revenue and, where government funding is tied to activation, lost income that directly affects what the service can offer. The CST weren't failing. They were absorbing a structural problem the data architecture had created, and carrying the cognitive load of a system that had never been designed to support the work they were actually doing.

Before a single screen could be drawn, that architecture had to make sense.

Data Model

Making the data coherent enough to act on.

Working with the Business Analyst, I mapped data relationships across all three platforms, including Funder, Programme, User, and Licence chains spanning DSA, Access to Work, Group, and Private funding types. The goal was a unified data model: a single blueprint for what a source of truth would actually contain, and the technical foundation for a GDPR compliant UK data migration.

This wasn't preliminary work. It was the design work that determined whether the interface could be trusted at all. A profile built on disconnected data would have surfaced the wrong information, in the wrong place, at the wrong moment, and the CST would have been back to workarounds within weeks.

Proposed data flow from the BA
CST workflow map

Workflow Map

Understanding where registrations were stalling and why.

Eight manual steps from Purchase Order to user activation. Each one requiring a status check across separate systems. No automated handoffs. No alerts when a registration was approaching the end of its 90 day window. No way to see, at a glance, which registrations were at risk.

The workflow map made the bottlenecks visible for the first time. It showed exactly where the three system handoffs were creating delays, and gave the design a precise brief: not just a better interface, but a view that would let the CST see risk before it became a missed registration.

Information Architecture

From tool structure to task structure.

The existing IA had been built around the shape of three separate systems, not around the work of the people using them. It was deeply nested, inconsistently structured, and required CST members to hold context in their heads that the interface should have been holding for them.

The proposed IA consolidated everything into a single profile with four clear sections and a subnavigation built around how CST members actually moved through a case, from quick status checks to deeper case management. The structure wasn't designed around the tools. It was designed around the moment a CST member needs to know whether a registration is on track, and what to do if it isn't.

Current user IA
Proposed user IA

Product Context

The unified profile is only as reliable as the data beneath it. Getting the architecture right first wasn't a delay. It was the only way to build something the CST could actually trust.

Design Principle

When incomplete registrations have a human cost, the data architecture is a design problem, not a technical one.

The Design

One profile. Everything a CST member needs. Nothing they don't.

The unified user profile was designed as a single source of truth, a hub where CST members could see everything and take action without switching tools. The shadowing sessions had shown two distinct working modes: quick status checks many times a day, and deeper case management when actively processing a registration. The design needed to serve both without compromise.

Status at a Glance

Quick View

Born from a single piece of feedback heard during shadowing: "I need to see registration status without opening the full profile." The Quick View is a light touch overlay surfacing the 90 day countdown, case owner, registration status, and key actions. The most frequent manual lookup task was eliminated in seconds. Existing components were reordered and prioritised rather than rebuilt, reducing dev overhead while delivering immediate value.

Quick View: registration status surfaced without opening the full profile

Case Management

Full Profile

The single source of truth. Organised into four sections: user summary, registration timeline, package details, and support history. The order reflected how CST members said they actually moved through a case. The Packages section introduced the concept of episodes of use, separating a user's journey as a DSA student from their later journey as an Access to Work recipient. This made the history legible without overloading the active view.

Full Profile: four sections in the order CST members worked through a case

The New Single Source of Truth

From five separate lookups to one.

The screens below show the annotated handoff views prepared for development, from the Quickview through to the package detail states.

Ready for development: Overview Tab, Activity and Progress

Placeholder copy for the overview screen. Use this space to explain why this became the central view, what CST members needed to understand first, and how the layout reduced the number of places they had to check.

Placeholder copy for the development detail. Use this space to call out the annotation layer, reusable components, data surfaced from connected systems, and any decisions that helped the internal team move into build with less ambiguity.

01Ready for development: Quickview
02Ready for development: User Profile, Summary
03Ready for development: User Profile, Overview Tab
04Ready for development: User Details Tab
05Ready for development: User Details Tab, Packages

Package MVP Solution

A deliberate fallback for phase one.

A Brain in Hand user might hold more than one active package simultaneously, a DSA package as a student and an Access to Work package as they move into employment, for example. Surfacing both clearly, without one obscuring the other, was a design problem the full packages view was built to solve. Where that complexity couldn't be fully supported in phase one, this stripped back view surfaced the single active package clearly. It was a deliberate fallback, not an oversight, and the data model fully supports the complete solution in the next phase.

Where multiple packages couldn't be supported in this phase, a stripped back view surfaced the single active package clearly. It was a deliberate fallback, not an oversight.

Short term packages: temporary support arrangements surfaced separately to avoid cluttering the main package view

Technical Scope

Documenting what could be reused and what needed to be built.

Stakeholder interviews with the CRM and Dev teams surfaced constraints that shaped the phasing decisions, including the choice to defer HubSpot integration and focus on a stable foundation first. A component library audit against the Vuetify upgrade identified what could be reused and where new patterns were needed. Content mapping grouped every data point into four logical clusters: registration, referral, package, and support. These clusters became the information architecture the profile was built on.

Anatomy
Components: Icons
Components: Buttons
Components: Typography
Components: Common Components
Components: Page Furniture
Components: Spacing
Components: Modal Window
Components: Colour

Handoff

Designed to be built without the designer in the room.

The prototype delivered to the dev team wasn't a set of static screens. It included anatomy documentation, component specs with exact values, a spacing system, colour token mapping, and "use once" annotations guiding reuse decisions throughout the build.

The Vuetify component upgrade running in parallel shaped every handoff decision. Where new components were unavoidable, they were specified precisely. Where existing components could be reused, that was called out explicitly, reducing build ambiguity and keeping the team moving without constant designer input.

That was the intention from the start. A handoff that needs the designer to explain it hasn't finished being designed.

Handover Prototype for internal team usage

Design Decisions

Decisions worth naming

01

Accessibility as a design input

Brain in Hand's users are neurodivergent. That made accessibility a design input, not a compliance checkbox. Colour contrast was validated against WCAG standards throughout, not at the end of the process, but at every decision point along the way. A proposed colour token system mapped existing brand colours to a structured palette, giving the dev team a consistent reference for every component state.

02

Stability over new patterns

Drawers were explored as an alternative for editing in context. Modals were chosen deliberately in response to the Vuetify component upgrade happening in parallel. Fewer new components meant a more stable build. A visible tradeoff, made early and documented explicitly.

03

Deferred, not dropped

A dashboard showing case ownership, outstanding tasks, and countdown summaries across all active registrations was what every discovery conversation pointed toward. It was deferred, not dropped. The data model fully supports it. The decision was documented, communicated, and handed over as the next sprint defined.

Validation

The hypothesis: a unified profile would eliminate manual status tracking.

Testing was conducted with CST members against the unified profile. The results confirmed the core hypothesis and surfaced two refinements that shaped the final design before handoff.

✓ Validated

Quick View understood immediately. CST members could check registration status in seconds. The interaction model required no explanation.

✓ Validated

90 day counter eliminated manual calculation. The single most time consuming daily task was completely eliminated. Every participant noticed this without prompting.

△ Refined

Multi field editing needed refinement. Some users wanted to edit multiple fields in a single session. This informed an iteration grouping related fields more consistently within editing modals.

△ Refined

Profile and ticket link not immediately obvious. The connection between user profiles and support tickets wasn't immediately visible. This became a documented requirement for the future FreshDesk integration phase.

What Changed

From three disconnected tools to one, with a foundation built to last.

Registration status is now visible in a single view. CST members no longer maintain personal spreadsheets or calculate 90 day countdowns by hand. One profile surfaces everything: registration status, licence details, support history, and case ownership in a single place.

The GDPR compliant data migration resolved the compliance requirement that had made the existing architecture unsustainable. The unified data model supports white labelled instances for individual university and local authority clients, and fully supports the case management dashboard the CST identified as their most urgent unmet need.

This was a contract engagement, so long term usage metrics sit with the internal team. What can be reported is what was delivered: a tested design, a validated data model, and a foundation documented well enough to be built on by the in house design team.

What I Carry Forward

What this project sharpened in me.

01

Knowing when the foundation is the deliverable

Every discovery conversation pointed toward a dashboard: case ownership, outstanding tasks, and countdowns across all active registrations. That view wasn't in scope for this contract, and deferring it was the right call. The data model was designed from the start to support it. Knowing the difference between what belongs in this sprint and what belongs in the next one, and being able to articulate that clearly to the team, is part of what senior design experience looks like.

02

Shadowing is essential in internal tool design

Jo's quote shaped the entire project, and I only heard it because I was in the room watching real work happen. The workarounds the CST had built weren't problems to design around. They were precise requirements that only became visible through direct observation. Documentation tells you what a system is supposed to do. Shadowing tells you what people actually do instead.

03

Data modelling with a BA is design work

The unified profile only works because the data beneath it is clean and coherent. Mapping Funder, Programme, User, and Licence relationships across funding types including DSA, Access to Work, Group, and Private came before a single screen was drawn. It wasn't a precursor to design. It was design. An interface built on disconnected data is an interface that can't be trusted. Getting the foundation right first isn't a delay. It's the only way to build something reliable.

04

Tradeoffs should be visible, not defaults

Deferring the dashboard, phasing the FreshDesk integration, and choosing modals over drawers were the right calls for delivery. What matters is that they were deliberate, documented, and communicated. A decision that falls out of scope quietly is a risk. A decision that's named, explained, and handed over is a plan. There's a significant difference between the two.

Back to top