Cortex DXP

Leading the redesign and rebrand of sports' premier Digital Experience Platform — and the Ennis design system that powers it.

2022 — 2024cortextech.io

Client

Cortex

Role

Lead Product Designer

Cortex DXP hero — Ennis design system tokens and the platform

Timeline

2022 — 2024

Team

1 PM · 3 frontend developers · 2 backend developers · 2 product designers

My role

Lead product designer — design system components, key user journeys, accessibility lead, mentoring

What shipped

Cortex DXP rebrand and updated user flows, powered by the Ennis design system; adopted by 30+ new rights-holders

Discovery

Mapping the system we had

When I started the project, I ran a maturity audit on the existing design system — accessibility report, component analysis, a walkthrough of the core user journeys, and five user-feedback sessions with rights-holders running the product day-to-day. The audit gave us a shared baseline and a sharp list of what had to change before the rebrand could ship.

The previous Cortex UI — captured during the audit before the rebrand

Opportunities to improve

After the audit I ran a series of workshops to surface where Cortex could go next — concepts like a smart media picker, mobile-friendly CMS editing, a unified rule-builder for audience segmentation, and a full navigation overhaul. We kept the list visible as the system took shape, so every component decision could be checked against the product directions it had to support.

Audit of the existing design system — gaps and inconsistencies surfaced

System

Tokens first

With the new Cortex brand defined, I started the design-system rebuild from tokens out. Primitives, then semantic tokens, agreed and named alongside the front-end team — so everything that shipped afterwards inherited from the same foundation. Brand changes never had to ripple through hand-coded components again.

On-action
--color-on-action · #FFFFFF
Action
--color-action · #6221F8
Surface
--color-surface · #FFFFFF
Background
--color-bg · #FCFAFF

Testing new patterns

I picked a handful of high-traffic user journeys to put the early patterns against. Post-test we analysed using atomic-research principles — Experiments, Facts, Insights, Opportunities — so the design decisions had clear footprints back to evidence, not opinion.

“Atomic research kept every system decision traceable — what we tested, what we learned, what we'd do next.”

Testing new patterns — atomic-research outputs across high-traffic journeys

A system built for sport

Sport baked into the system, not bolted on. Market research and recurring conversations with our existing clubs and rights-holders shaped which sport-specific patterns earned first-class treatment — match-day flows, fixture lists, rights windows, lineups — alongside the standard SaaS primitives.

A system built for sport — match-day flows, fixture lists, rights windows, lineups

Accessibility

Accessibility in every component

I led an accessibility programme that went well beyond colour contrast. After researching how the best-in-class platforms framed their guardrails, we landed on an 8-category audit checklist that every new release had to pass: Navigation, Controls, Technical compliance, Visual, Content, Tables, Forms, and Graphs. The bar moved with each release; the checklist made sure we knew where it was.

Preview
Label
Style
Icon

Accessibility criteria

  • Action token #6221F8 on white tests at 6.4:1, comfortably above the 4.5:1 minimum. The outline and ghost variants keep the same foreground colour so the label remains legible whichever style is used.

Craft

A bespoke icon library

The product had enough sport-specific affordances that a generic icon library was never going to fit. We built a bespoke set with clear rules — stroke weight, grid, optical correction, and how each icon should sit alongside the new Cortex brand voice.

A bespoke Cortex icon library — stroke weight, grid and optical correction rules applied

Templates and components

Once foundations were stable I moved up the stack — page templates, layout patterns, and the components every team would reach for. We ran usability tests through each iteration so the core layouts kept evolving as the product matured.

Cortex templates and components — page layouts, tables, charts and cards

Shipping

Releasing and learning

Every release was tracked carefully. Google Analytics, Hotjar and Mixpanel for behaviour; per-feature product scorecards plus user feedback rounds for the qualitative side. Each release informed the next, and the system kept getting tighter.

34

Fewer support queries per month

1,250

More articles published per month

30

New rights-holders on the platform in 2 years

Reflections

What I'd do differently

Building a established design system with governance in place from day one could have saved time in the long run. We had to course-correct a few times as the system took shape, and while we got there in the end, it would have been smoother with clearer meetings and documentation surrounding how decisions were made, and who owned what.

Cortex DXP — final design, screen 1
Cortex DXP — final design, screen 2
Cortex DXP — final design, screen 3
Cortex DXP — final design, screen 4
Cortex DXP — final design, screen 5

Next project