LiquidX · 2024

Early dashboard Overview from the Figma source. Live product at gvrn.ai (maintained separately since this work).
GVRN needed a dashboard for founders to manage entity setup, fundraising, and compliance for AI and Web3 companies. I designed the initial UI kit—layout, navigation, and a minimal component set—that the team built the first product surface from. The kit stayed small on purpose, giving later releases a single visual source to extend rather than reinvent.
| Role: UX/UI Designer | Timeline: ~3 months · Q1 2024 |
| Team: 2-person build: 1 engineer + myself (design + Figma source) | Tools: Figma, Retool |
| Company: LiquidX | Scope: 20 screens handed off in ~3 months |
| Impact: UI kit established consistency across 20+ subsequent screens; Retool build time reduced by ~30% through component reuse |
I owned the visual source for the first dashboard: establishing a minimal UI kit in Figma, setting the responsive structure, and sharing the file so design and Retool build looked at one kit. I collaborated with the founding product team as requirements shifted weekly.
A full design system would have been premature. The product was pre-launch, the team was small, and the requirements were shifting weekly. I made a deliberate choice: build enough to establish consistency—type, colour, layout, navigation, and a short set of components—and nothing more. The kit had to be extensible without being overbuilt.
That meant resisting the urge to design every edge state up front. Placeholder icons stayed on secondary nav items. Empty states and role variants (Admin, Member, Shareholder) came as the flows matured. Consistency first; completeness later.
I organised the dashboard around the founder’s work, not the org chart of the product. Sidebar sections split Dashboard (Overview, Group Structure, Documents, Requests, Fundraising) from Organization (Members, Settings), with an org switcher at the top for multi-entity work.
I kept the colour palette minimal—one primary blue accent, dark neutrals, and semantic status colours—because the product’s trust signals come from the legal compliance layer, not the UI. A loud dashboard would undermine the sense of security founders need when filing directors, signatures, and incorporation documents.
Status badges earned more variants than almost anything else: Active, Pending payment, Processing, Cancelled, Completed, plus colour tokens (green / yellow / blue / red / grey). In a compliance product, state is the interface. Tables and filter chips followed the same logic—dense, scannable, and Retool-friendly.
For Requests, I tried a compact list layout first—title, status badge, requester. It looked clean, but it did not scale once actions and columns appeared. I moved to a data table with filters, unread markers, and explicit View / Cancel actions. The list version stayed in the file as the older option; the table became the working pattern for Documents and Requests alike.


Retool was the build surface next to the Figma file. I did not design decorative one-offs that could not map to Retool’s table, form, and navigation primitives. Sidebar + content, filter chips, status badges, and data tables were chosen because they translated: the kit constrained what we would invent in Figma so engineering could assemble screens without waiting on pixel-perfect custom widgets.
The handoff was the file itself—components, layout, and how to use them in one place. Design and build looked at the same source.
What I produced was a minimal UI kit in Figma and the early dashboard screens assembled from it: Overview with incorporation status and activity, Documents, Requests, Settings, and fundraising create flows. Local components included Button, Input, Navbar, sidebar, Tab, filter, and a family of Status variants.
Foundations and components—small on purpose.





Button component set from the Figma kit.
20 screens handed off in about 3 months. That number is scope.
The Figma file was the shared visual source. The live product at gvrn.ai has since moved on.
If I did this again, I would have documented the kit’s usage guidelines more formally. The components were self-explanatory to me, but a new designer joining the team would have needed more context—when to use the list row versus the data table, which status colours map to which legal states, how far Retool was allowed to diverge. The lesson: a design system is only as strong as its documentation, even when the kit is deliberately small.
Formal documentation needed: Component usage matrix (when to use list row vs data table, status color mappings), Retool divergence limits, onboarding guide for new designers joining the Figma file.