Modernizing Widget Designer through a design system
Rebuilding an aging control interface by turning real product decisions into reusable system rules.
Role
Solo UI/UX Designer
Timeline
Ongoing
Team
Product manager · Devs
Methods
Heuristic evaluation · Feedback review · Competitive analysis · AI-assisted research
Context
A professional tool for dense, high-pressure workflows
Twoloox builds software for real-time media control: show control, interactive installations, and professional visual production. One of its products, Widget Designer, lets users build control interfaces, wire widgets to logic, manage properties, and run live technical workflows.
This is not a consumer app. Operators, technicians, and system integrators work in environments where speed, precision, and control matter. They need to read the current mode, the selected object, the available actions, and system feedback without friction, often under live conditions.
Used by operators, technicians, and integrators
Live and time-critical workflows
Dense property and configuration surfaces
Errors carry real operational cost
Problem
The interface needed more than a visual update.
Twoloox needed a modern interface, but updating screens one by one would not be enough. The product already had many repeated interface decisions across dialogs, inputs, properties, spacing, states, and layouts. Without a shared system, those decisions could stay inconsistent even after the redesign.
The design system became necessary to make the redesign scalable and repeatable. It gave the product a way to define components, states, spacing, color, typography, hierarchy, and interaction behavior once, then reuse those rules across the interface as the product grows. as the product grows.
The goal was not only to make the product look newer. It was to make future design decisions faster, more consistent, and easier to scale.
My role and approach
Defining the design system inside the redesign.
As UX designer on the project, my role covers user research, interface analysis, component and pattern definition, dialog redesign, and design system documentation.
The work did not start from a blank canvas. It came with real constraints, and my approach was to turn each one into a working method.
Designing inside a live product
The product is live, the development team needs to keep moving.
→ I took a staged path: define decisions through real product work, document them clearly enough for developers to use, and build the Design System alongside the redesign.
Limited direct access to operators
Direct access to operators is limited at this stage, but the product is built for expert users working in technical and live environments.
→ I started from available research signals: existing product feedback, current interface analysis, project lead requirements, developer needs, competitive analysis.
A large and unclear scope
The interface scope was broad, from workspace and dialogs to inputs, buttons, states, spacing, responsive behavior, and documentation.
→ I narrowed the scope deliberately and began with dialogs. They are an important part of Widget Designer and bring many core system decisions into one contained, repeated surface.
Discavery
Mapping Widget Designer problems
Live technical workflows depend on fast orientation, clear system status, and user control. Users need to understand the current mode, the selected object, available actions, active changes, and system feedback without searching or guessing.
The product already had depth and professional control. The issue was not a lack of capability, but the effort required to read the interface, understand the current state, and act with confidence.
Because Widget Designer connects interface elements with interaction logic, clarity also had to support predictability. Users need to understand what a change affects, whether it is editable, disabled, locked, active, or pending, and what will happen before they confirm or apply it.
Expert users rely on Widget Designer for complex control workflows, but the interface does not always make the current state, available actions, and consequences of changes clear enough. This creates cognitive load at the exact moment users need confidence: when they are editing, testing, or applying changes in a live technical workflow. The design challenge was to make the product easier to read, control, and trust without reducing its professional depth.
Foundations
Grid and color first, for consistency
Before defining components, I set two shared foundations:
an 8px grid for alignment, spacing, and visual rhythm.
Color and state language to represent states, actions, and feedback consistently.
A functional color system for consistent states, actions, and feedback across Widget Designer.
A base spacing structure for alignment, rhythm, and layout decisions across the interface.
Starting point
Start where the rules can spread
I started with Dialog Box because it is one of the most important and repeated surfaces in Widget Designer. Dialogs bring many core system decisions into one place: inputs, buttons, labels, spacing, states, validation, layout behavior, and footer actions.
Instead of starting atom by atom, I used a product-led, pattern-first approach. I began with a real product surface, understood how the larger pattern worked, and then broke it down into reusable rules for components, states, spacing, and behavior.
This is a live case study. The Dialog Box pattern is currently being designed, and the next stages will be added step by step as the work continues.