Line Designer / UX case study
Redesigning a 30-year-old industrial product for the web
Reworking a 30-year-old industrial application for the web - using workflow analysis to separate what needed fixing from what needed to stay familiar.
Role
Senior UX Designer
Team
Sole designer, Developers, Product Manager, Project Manager
Timeline
July 2026 — ongoing
Scope
Product + design system
Final browser-based workspace — an interface built to retain the confidence of familiar industrial tools while creating a clearer visual language.
Context / challenge
A specialist tool, rebuilt for a new medium.
"Line Designer" supports industrial teams creating and managing label layouts. Its desktop application carried decades of workflow knowledge, yet its browser transition began without an established design system or a shared language for modern interaction patterns.
01
Legacy behaviour held real domain knowledge.
Changing the visible interface could unintentionally disrupt patterns operators had learned over years.
02
The product was shipping component by component.
The work had to support a sprint rhythm, not wait for a single end-state redesign.
03
No shared system existed to make decisions repeatable.
Every solution needed to make the next component easier to design, build, and maintain.
Original UI
Early explorations
Design principle
Lower risk / move decisively
Visual consistency
Improve hierarchy, states, language, and visual communication where the intent was already clear.
Higher risk / validate first
Interaction familiarity
Preserve or carefully test workflow changes where current behaviour is embedded in expert muscle memory.
Understanding the product
I started with tasks
The legacy product was too complex to understand through isolated UI reviews.
I evaluated seven core workflows, asking what users were trying to accomplish, what the system revealed at each point, and where the intended path became uncertain.
Questions used in each walkthrough
01
What is the operator trying to achieve in this moment?
02
What does the interface make visible — or keep hidden?
03
Which changes clarify the product without changing its contract?
From observations to patterns
A small set of decisions could address many symptoms.
I grouped raw notes from walkthroughs into themes, then separated work according to its risk: protect the familiar, validate changes that touch workflow, and fix communication failures that were already evident.
KEEP
Established workflows that SMEs confirmed carried essential domain behaviour.
VALIDATE
Interaction changes with the potential to disrupt expert muscle memory.
FIX
Communication and visual inconsistencies where the product already knew the correct answer.
Raw Observations
Analysis
Patterns
From observations to patterns
Two systemic problems surfaced across the product.
Across task-based evaluations, different symptoms repeated with the same underlying causes. Naming them shifted the work from screen-by-screen cleanup to a product-wide design strategy.
Working with SMEs
Expert explanation is not the same as product resolution.
SMEs were essential to reconstruct legacy behaviour: what a control meant, why a workflow had evolved, and which details could not be broken. Their knowledge gave context — but the design work was to translate that context into an interface that helps more people act correctly.
What SMEs made possible
“This behaviour looks strange until you see the production context it was designed for.”
The resulting pattern: preserve the rule, reveal the reasoning, and make the next action explicit.
Stakeholder feedback through One Note
Design exploration
Four surfaces where the new system learned its shape.
Each exploration moved from an observed friction point to a component decision, then became a reusable implementation reference.
Toolbox
Exploration → a clear select state, compact tool structure, and behavioural documentation that developers could implement without interpretation.
Field List
Exploration → selection, grouping, drag feedback, and density were tested as one system rather than isolated states.
Property Panel
Exploration → a controlled hierarchy turns advanced options into visible, progressive decisions rather than an opaque wall of controls.
Constraints
Exploration → constraints communicate the problem, the consequence, and the recovery path before an operator loses time.
Designing with AI
A faster loop in the design process
I used Figma’s AI and design agent throughout the work to generate UI, modify components, create variants, explore layouts, maintain documentation, and investigate design-system standards.
The tools accelerated the practical work of trying ideas - while product context, risk assessment, and final decisions remained human responsibilities.
AI reduced the cost of iteration. It didn’t remove the need for design judgment.
01 / Generate
Quickly produce a concrete starting point for a UI question.
02 / Modify
Refine a component in place while keeping the system’s logic visible.
03 / Build
Create variants and structured components that can survive real product use.
04 / Iterate
Compare alternatives at the pace a sprint needs — then choose deliberately.
05 / Document
Turn decisions into a legible record for the next designer and developer.
06 / Cross-check
Challenge outputs against established standards, legacy behaviour, and real task needs.
First Result
Final result with my refined instructions
Design system
A system, designed
I built structured components and Figma Variables so product decisions would move cleanly from exploration into engineering. The system was not a visual library on the side; it became the mechanism for maintaining coherence as new parts shipped each sprint.
Elements
tokens, type, icons
Composites
panels, rows, controls
Assemblies
workflows, workspace
Creating variables on Figma for developer hand-off
Iconography created per use
Tokens
The source of truth stayed structured.
Figma Variables held the foundations of the system: colour, space, radius, typography, and states.
Naming and grouping were designed around the conversations happening in product and engineering.
Design → code pipeline
Figma Variables
JSON
Style Dictionary
CSS variables
colour / purple / 600
space / 4 · 8 · 16 · 24
radius / medium / 10
Designing beyond Figma
The design file for everyone's needs
Components were designed with code, documentation, and developer collaboration in mind.
Each pattern carried behaviour, state, edge-case notes, and visual rationale so the implementation could preserve the decision.
Code-ready component structure
Documentation that makes states explicit
A shared reference for collaboration
Current state
A component-by-component sprint rhythm.
The product is actively moving through development in an intentionally tight loop:
Design → Implementation → Edge cases → Refinement.
The system keeps each incremental release connected to a coherent longer-term product direction.
Learnings
What I’m carrying forward.
01
Legacy behaviour needs to be understood before it is redesigned.
What initially looked like poor UX often had operational reasons behind it. Working with SMEs helped me separate “this is intentionally complex” from “the interface simply never explained itself.”
02
A design system can become a decision-making tool
Building the system alongside real product work forced me to define rules around what should be consistent, what needs flexibility, and what engineering can own independently. That made each subsequent component faster and more predictable to design and build.
03
AI is valuable when the designer stays accountable for the decisions.
Using AI throughout exploration, iteration and documentation significantly lowered the cost of trying alternatives. But the quality of the outcome still depended on the context I provided, the constraints I established, and the decisions I rejected.
MEASURING SUCCESS
The redesign is still being implemented, so I’m treating these as the measures I’ll use to evaluate whether the changes are actually improving the product.
Make existing capabilities easier to discover
Task success rate for actions such as Undo, multi-select and type switching; time-to-discovery; reliance on SME/help
Surface problems earlier
Errors caught during authoring vs. preview/printing; recovery success rate; time to resolve
Reduce interaction friction
Task completion time, misclicks/backtracking, and number of steps for priority workflows