DELL TECHNOLOGIES · DESIGN TOOLING · SELF-INITIATED
DesignFlow
A working Figma plugin that turns buried component adaptations and design rationale into shared, searchable knowledge.
MY ROLE
Product Designer — research, design, prototype, and build
SCOPE
Design tooling · Figma plugin · 0-to-1 · self-initiated
TIMELINE
FY26
OUTCOME
Working React + TypeScript plugin prototype, usable end to end
Overview
Across a large design organization, teams constantly adapt shared components to solve product-specific problems: denser operational tables, complex filters, permission models, and countless workflow improvements.
That work is valuable and reusable, but it remains buried inside individual Figma files. The result isn't just duplicated work—it's duplicated thinking. Teams repeatedly solve problems another group has already figured out while the reasoning behind those decisions disappears.
I kept seeing designers ask around for "that table someone made" or share screenshots through Slack because there was no reliable way to discover existing work. Nobody asked me to solve this. I built DesignFlow because the pattern was too consistent to ignore
The recurring problem
The thing teams keep losing is not the component. It is the why.
A screenshot shows what changed. The rationale explains why.
"We reduced row height because operations users scan hundreds of records, and the original layout slowed triage."
The first is an artifact. The second is reusable knowledge.
Most tools preserve the artifact. Almost none preserve the decision. Meanwhile, the adaptations themselves remain locked inside individual files. Designers either ask around, get lucky, or rebuild something another team already solved.
How I approached it
Before designing the interface, I tested whether the core product idea was technically possible.
Cross-file reuse is gated. Figma only lets components move between files if they're published to a team library. Most adaptations are unpublished frames — so they're not directly insertable.
The API can't write design data from outside the editor. The REST API is read-only for design content; moving to a "web app" doesn't unlock it. Only in-editor plugin code can create nodes.
Identity and file context are limited. A plugin can only reliably identify the current file (needed for links back to source) once it's published privately to the org.
This research is what shaped the entire product. The magical "copy it into my file" version was fighting the platform. I could build a heavy engine to reconstruct designs node-by-node — or find a model that worked with the constraints.
The technical insight
The obvious solution was rebuilding components across files.
The better solution was not moving them at all.
DesignFlow stores only three things:
Preview
Deep link to the original source
Metadata and design rationale
When designers find something useful, they simply open the original file and reuse it using Figma's native workflow. This approach kept the product technically feasible while preserving the original structure, ownership, and context.
What I built
A working React + TypeScript plugin—not a clickable prototype
Browse & discovery
Search across components, teams, and patterns; filter by category; sort by recent or trending. Cards show preview, status, product, likes, and a quick Open source action on hover.
Component details
The full story of an adaptation: preview, status, product, author, upload date, Description and Rationale, plus discussion, like, and save.
Publishing — attach, not guess
Select a frame, attach it explicitly, then auto-fill what the file already knows. The only required payload is the part no system can infer: why the change exists.
Where it stands
A complete working prototype, usable end to end
What's left isn't interface design. It's organizational infrastructure: authentication, shared backend, governance, ownership, and adoption.
One realization became increasingly clear as I discussed the concept internally: the technical problem was largely solved, but the organizational one wasn't.
Leadership later introduced an AI idea intake form to collect internal ideas, yet there was still no established process for evaluating, sponsoring, or adopting them. The form solved idea collection, but not the system needed to turn good ideas into supported products.
Impact
→
Turned an unnamed organizational problem into a concrete product concept.
→
Built a complete React + TypeScript Figma plugin rather than static mockups.
→
Developed a constraint-driven architecture ("Link, don't copy") that kept the product technically feasible.
→
Designed a lightweight contribution model focused on preserving design rationale, not just visual artifacts.
Key insight
The hardest part wasn't building the plugin.
It was creating the conditions for it to survive. Figma's constraints shaped the technical architecture. Dell's organizational constraints revealed a larger challenge: great internal products need ownership, governance, and a path to adoption.
The interface was buildable. The surrounding system was not yet established.