DragOn UI Builder
DragOn solved three problems at once: slow onboarding for new and junior developers, no shared way to work through a UI concept, and product teams with no designer. New developers learned our Angular system by dragging its real components into place. Developers and product managers built and shared working concepts without writing code. Some teams started building UI together right after stand-up.
Design lead, platform
Drag-and-drop UI builder for the enterprise Angular Development Kit
Product manager, development team
Custom icon set for every component in the builder
Developers drag components onto the build area and start configuring the layout.
WHERE IT STARTED
Most teams had no designer and no way into the design system.
New and junior developers had no way into the design system that didn't start with weeks of documentation. Teams without a dedicated designer - most of them - had no way to build or share a real interface concept without me.
And teams that hit a UI question mid-sprint had no way to work through it together that produced anything by the time the conversation ended. DragOn answered all three.
The developer couldn't build it wrong
The usual path onto a new team looked the same everywhere: read the design system documentation, guess at how a component was supposed to behave, submit something, and find out in code review what you'd gotten wrong. That loop worked, eventually, but it put the correction after the mistake instead of before it - and on a team with no designer to catch things early, code review was often the first time anyone looked closely at whether an interface decision was right.
DragOn moved that correction earlier. A new developer's first contact with the design system was the system itself, configured correctly, in a build area they could drag pieces into. The builder only offered the components and settings the system supported, so the constraints that usually surface as review comments became the edges of the tool. Developers learned what a correct interface looked like by assembling one, before writing code anyone had to fix.
Once a component is in the build area, the developer adjusts it in the Settings panel.
Developers could copy the code straight into their IDE, share a link to the concept, or save the project for later.
No designer on the team
At the scale DragOn served, this wasn't a queue teams could join to borrow design help. It was that there was no design help to queue for. Across a superdivision of more than 3,000 developers, over 90% of product teams had no design resource of any kind — no designer on staff, no contractor, no realistic path to getting either.
DragOn gave developers and product managers a way to build and share a working concept without a line of code or a running dev environment. A product manager could put together a real interface, not a description of one, and hand it to a developer already mostly done. That's design capacity no single designer, or even a small team, could ever have covered at this scale — the tool supplied it instead.
I simplified each icon as far as it could go while staying recognizable as its component.
Daily stand-ups became build sessions
Plenty of teams ran into a UI question they couldn't answer by talking about it. We reached out to teams our metrics showed as heavy DragOn users. Several said they'd started opening DragOn after morning stand-up to work through UI problems together in a shared screen.
That's a different use than the one I designed for. I built a tool for one person to prototype alone. Teams turned it into a room. Whatever got built in that session was already real code, so the meeting produced something the next meeting didn't have to redo.
A tool built to stand in for a designer ended up being something three roles could stand in front of at once.
What I designed: component and icon design — interaction design for the build/configure/export flow — collaborative-link sharing — code export to working Angular.
Nobody had to use DragOn. Teams chose it.