Lighting manufacturer

B2B ecosystem redesign for technical manufacturing

2026
Digital product design
E-commerce · Retail
Challenge

A mature ecosystem with massive technical attribute layers and a UI that no longer matched the engineering.

Approach

Treat the redesign as infrastructure, not decoration. Unify the foundation across teams and simplify the discovery flow.

Result

A token-driven design system, a flow-by-flow migration with zero rollback events, and a documented foundation that engineering owns.

4×
Faster discovery
2×
Time-to-value
+40%
Doc downloads
Redesigned product page of a lighting catalogue on a laptop: a downlight with its specs on a dark panel (sample data)
Timeline

24 weeks

Industry

E-commerce · Retail

Stack

Figma, FigJam, React frontend

Details marked * are generalised under NDA
Names, figures and screens are adjusted to protect the client. We show the shape of the work: the industry, the constraints, the result.

Challenge

The brief was not visual. It was structural.

An end-to-end product redesign for a leading lighting systems manufacturer* with a high-fidelity catalogue of products, families and technical resources.

The challenge was to transform a complex, technically layered environment into a structured, scalable and user-centred experience that supports both rapid browsing and specification-driven decision-making.

The client operates a regulated e-commerce and retail platform serving hundreds of thousands of B2B and institutional users. Their product had matured rapidly over 25 years, but the interface had not. Multiple independent teams owned three loosely related codebases, each with its own idea of what a primary button should look like.

The goal: a system that could carry the next five years of growth without the next redesign starting from scratch.

Sample catalogue listing: categories, systems and families of downlights, each card with output, colour temperature and lumen range

Principles

Four non-negotiables, agreed in week one

Every design and engineering decision after that traced back to one of them.

01 · Hierarchy is the UI

Every component must respect the technical layering of the products, from high-level systems to specific technical components.

02 · Guided discovery

Search is not a field; it is a powerful discovery layer. It must turn raw technical data into a guided exploration flow.

03 · Engineering owns the tokens

Whatever we shipped had to map directly to variables already used in three different codebases.

04 · Decision-making hubs

Product pages must function as technical comparison tools, not just marketing descriptions.

Product hierarchy from category to system, family, product and item, each level with its own page template
Every level is its own page template: the hierarchy is the navigation.
Under NDA · 30 min call
See the full case on a call

Real screens, the complete benchmark and the design system, walked through live by the team that built them.

Sviat Luchyn, Co-founder and CEO of Flying Age
Sviat Luchyn
Co-founder & CEO
sviat@flying-age.com

Benchmark

Measured against the surface it replaced

Each row was a metric the team agreed mattered before the redesign began. Numbers are pulled from production telemetry.

Criterion
New
Legacy
Guided discovery
Yes
No
Time-to-spec-sheet
18 sec
72 sec
Attribute filtering
Yes
No
Mobile-first technical view
Yes
No
Decision-making hubs
Yes
No
Sample product page: spec sheet, instructions, IES files and brochure one click from the product hero, with key features and specs below

Key flows

Three flows that turn a catalogue into a specification tool

Principle 04 in practice: product pages work as technical comparison tools, not marketing descriptions. Three flows from the catalogue show how.

Compare without leaving the catalogue

A product opens inline with key specs, downloads and the spec sheet. Up to four products can be pinned to a compare tray and reviewed side by side.

Sample quick view with key specs and downloads, and a compare tray holding up to four products
A valid part number in three choices

The builder turns a long order code into plain choices: output, colour temperature, beam. The final code is copied together with its spec sheet.

Sample product number builder: output, colour temperature and beam choices that assemble a valid part number
See the beam before choosing the lens

An interactive control shows how each lens shapes the light, from a narrow spot to a wide flood.

Sample beam angle control: a slider from 10° to 60° shows how each lens shapes the light

Process

Twenty-four weeks, one exit criterion per phase

Each phase was measurable, documented and signed off in writing.

Week 0–4 · Forensics

Sat with the client’s* support agents and rebuilt top user journeys from session recordings.

Week 4–12 · Foundation

Buttons, inputs and complex filtering components rebuilt in lockstep with engineering.

Week 12–24 · Migration

Catalogue first, then search, then technical hubs. Each flow rolled out only after its target metric moved.

Outcome · Modular system

12 reusable templates.

Outcome · Publishing

An engineering-owned release workflow.

Outcome · Reusable system

A token graph the team extends in code without calling design back in for every launch.

Sample catalogue with an open lumen filter, result counters and removable chips for active filters

Results

Catalogue performance, 90 days after rollout

Each metric is owned and verified by an internal team. The headline numbers sit at the top of this page.

VP of Product, Lighting manufacturer*
“This redesign didn’t just fix the UI; it unlocked the entire product* ecosystem.”
A legacy interface was the only thing standing between our users and the most advanced technical hardware on the market.