Elastic Borealis
Pitched and led Elastic’s visual design refresh (“Borealis”) — my first project at Elastic — refreshing core foundations of the design (colours, icons, dark mode, typography) while standing up the design system team’s first real capability to ship global changes company-wide.
Role
Design lead
Timeline
2023 — 2024
Discipline
Design refresh
Scale
3 colour modes · company-wide
In short
Elastic’s design system was open source and heavily used both inside and outside the company, but had become overgrown — far too many props and components. This was the first project tI took on when I joined, and I moved fast, drawing on a similar design-language refresh I’d already run at XING.
The challenge
There was internal sentiment that Elastic’s UI was outdated and unloved — “Soviet era design” was a phrase people actually used. The system needed real trimming, but touching the foundational tokens of a mature, in-use product used by thousands of customers meant any change carried real risk.
Before: improving the Dashboards and data visualisations were a key focus of the project
Approach
I assembled a core team of platform designers, with early input from solution-area designers, and ran a three-week cross-org sprint exploring different directions before converging on one through open feedback sessions.
Opportunites and goals, project principles
A smaller core team of two to three refined the winning direction, then handed specs to the design system team to roll out through a “shepherding process.”
Three diverse concepts for the team to get feedback on. Reduced to one direction.
I included a designer from the brand team in the core setup — brand had recently updated its own look, and we needed that carried through to product. They paired directly with another designer on icons and other key elements to keep brand and product aligned.
Refreshing the colour palette and typography incrementally improved our visualisations
The work focused heavily on Discover and Dashboard — Elastic’s two most heavily used and most complex products — since rules proven there carried through consistently to every other touchpoint. We rolled it out via a new, feature-switched theme (A for Amsterdam, B for Borealis) layered on top of the existing foundations rather than a rip-and-replace — a genuinely more complex change than the engineering team had made in years.
Re-setting the foundations meant concentrating on the details and how to transition from now > next
Changes were complex and had to be brought in iteratively
Iterative changes were also planned at feature level, for example out metric visualisation
We used the same moment to realign design tooling with what was actually available in code, building a separate, temporary Figma file with the new designs so designers had something accurate to work from during the transition.
Outcome
icons redrawn (from 400)
gray tokens (from ~30)
colour modes shipped
Amsterdam theme → Borealis
We refreshed foundational tokens for colour, icons and spacing — gray tokens went from roughly 30 created programatically down to a clear, controllable set of 12, and the icon set shrank from 400 to 250 after removing duplicates and redrawing the rest.
Three colour modes shipped — light, dark, and a new “Borealis blue” — with improved user-preference-dependant switching. Beyond the visual refresh, the project gave the design system team its first real capability to roll out global changes company-wide, absent for years before — we built on that the following year with further “component sweeps” across the product.
Borealis blue mode - we implemented a new monospace font for numbers, enhanced the colour palette and tightened the grid
Light mode
What I’d do differently
Solution-area designers’ time and input waned as the project moved into real decisions — sustaining that participation would have given the work deeper roots across the design org.
I also should have identified the real core stakeholder at the start: it took months of stakeholder-mapping to discover the founder/CTO was our most important stakeholder, and by the time he engaged it was too late for him to ever feel truly connected to the work.
The VP of UX — the project’s original sponsor — left mid-pitch, and the substitute sponsors who followed left too, until the stakeholder group had essentially disappeared. I pushed forward on momentum rather than pausing to secure a real replacement, which caused real buy-in problems later on.
I underestimated how much legacy and version complexity a mature SaaS product carries — defining the design was maybe 10% of the effort, the other 90% was rollout.
Relying on designers’ spare-time contributions on top of their main work also proved unsustainable; it’s a minor miracle the project shipped at all. I fixed that directly afterwards by restructuring the team around dedicated, full-time designers supporting the platform work.