Atlas

Personas lived as static images spread across different formats and platforms. They were hard to update and inconsistent between products. The three distinct audiences — the clients who buy, the people who use the tool daily, and the learners in training — were blurred together and sometimes duplicated. And a persona wasn't linked to the journeys or goals it was meant to represent, so teams didn't rely on them.

The work ran from auditing what existed, through primary research, to a documented structure the teams could maintain themselves.

The personas are grounded in primary research with the teams closest to users. Interviews and a survey did most of the work; a follow-up collaborative study captured tasks the interviews didn't reach.

• One shared template, so personas read consistently across products and levels.
• The three groups are separated, so product, UX, marketing and training each work from the audience that's theirs.
• Each persona links to journeys, use cases and features — usable in product decisions, not just a reference.
• Kept as living, versioned documents: easy to update and extend as we learn more, instead of static images.

Below is one completed persona, Fraud Analyst (Internal) — shown in full so the depth is visible, not just described. It is one of a larger set: the Fraud group alone spans five roles, and that pattern repeats across all three persona groups and three market segments. Every persona follows this same template.

I owned the review and improvement of the team's design ops. I audited the library, file structure and handoff, pinpointed where they broke from best practice, set the direction to fix them, and drove the changes through with design and engineering.

I kept what was working and strengthened the foundation for growth — improving the system, not restarting it.

• Components now follow Atomic Design with proper connections.
• Figma files are organised — the latest version is always accessible and up to date.
• The handoff supports continuous product growth: faster and more flexible.
• Automation reduced errors and routine work, freeing designers to focus on creative solutions.
• The reorganised file structure and corporate-style covers improved navigation and clarity.

Structure and automation across the library, files and processes let the team move faster and with confidence — no time lost to routine work or hunting for the right version.

Designers now focus on meaningful solutions, and the product has a stable foundation to grow on.

I owned the review and improvement of an inherited design system. I audited the library end to end, pinpointed every gap and inconsistency, set the direction to fix them, and drove the changes through with design and engineering.

Rather than restart, I strengthened the foundation already in place — building on the chosen framework and the in-flight MUI migration, and shaping the library around real product needs.

The library had grown from Bootstrap plus a vendor-built custom design — a mix that, over time, became incompatible, inconsistent and hard to maintain.

A migration to customised MUI was already underway, but the library beneath it was still disorganised and incomplete: components were inconsistent, unfinished, and off best practice.

My job was to give it the dedicated review it needed — so the MUI migration would land on a solid, sustainable system instead of carrying the old problems forward.

We adopted the Figma Branching best practice for a product on Agile — a fast, “hot-potato” handoff where work happens on a branch, gets reviewed, and is merged back into main so the main file is always current.

Integrating the updated components into design and giving developers detailed recommendations for transitioning to the new system.

Every component runs the same pipeline — finalize → apply → build & QA → ship — so it becomes reusable across design and development. Goal: automation and consistency.

The design system spans foundations, core components, patterns and documentation. Below is a small sample of the library — a few representative pieces, not the whole system.

Foundations & core components — typography, colour, icons and buttons, each documented on the new system.

Interactive components — checkbox, select and autocomplete with full states, applied in a real product screen.

• Faster, at lower cost
  Both designers and developers move quicker — process optimisation, the core payoff of a design system.
• Shared language
  Consistency across products that directly improves the user experience.
• Consistent library
  Components are consistent across products and aligned with best practices.
• Reliable components
  Designers have clear, dependable components to work with.
• Living documentation
  Docs stay up to date and simpler to use with the system.
• More time to create
  Less time fixing the system, more on new product solutions.
• Modern stack
  Bootstrap and outdated custom elements removed; migrated to customised MUI.
• Stable migration
  The MUI migration landed on a stable foundation — no new errors or chaos.

The Double Diamond maps the whole journey — diverge to explore, then converge to decide: first on the problem, then on the solution. The six numbered stages live inside it — each one is expanded in detail below.

The work runs in three iterations, not a straight line — each repeats until its gate is met, and the whole thing loops again after launch.

Every stage is a gate — I don't move on until its output exists and the team agrees it's done.

The checklist I actually run at kickoff — abbreviated here. For a new feature or product I work through all of it before diverging into discovery; for an enhancement, a lighter subset, reusing prior research.

One of several ideation boards — ideas clustered by audience, voted (❤️ / 👍), then prioritised. Result: the top-voted ideas became the block-management dashboard and bulk actions.

Atlas had grown into several tools with separate logins. I mapped it into three clear areas so everything a case needs sits one or two steps from the queue. Result: a scattered, multi-login workflow collapsed into one workspace.

The core task — an analyst works an alert from the queue to a documented, auditable decision.

◇ = decision point. Every branch is reversible and logged, and outcomes feed back into triage. Result: fewer steps to a decision, and no dead ends.

The same task from the analyst's side — what they do, how it feels, and where it breaks down. The pains here — no triage, scattered data, risky final actions — set the redesign priorities.

Front-stage and back-stage — what the user sees, what the team does, and the systems behind each step. Result: design, engineering and ops aligned on one flow, front to back.