LiquidX · 2024

GVRN

Designing the first dashboard UI kit for a Web3 legal stack—before there was a design system, a pattern, or a visual identity.

UX/UI DesignUI KitFigmaRetool

Early dashboard Overview from the Figma source. Live product at gvrn.ai (maintained separately since this work).

Founders incorporating a Web3 company face a unique problem: the legal and compliance workflows are built for traditional businesses, but the product needs to feel native to crypto. I was brought in to design the first dashboard for GVRN—before there was a design system, before there was a pattern, before the product had a visual identity.

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.

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.

GVRN is the product founders use to incorporate an AI, Web3, crypto, or blockchain company, and to handle the legal and operational work around that—entity setup, fundraising, compliance. It is live at gvrn.ai.

The founders needed a place to see incorporation status, manage documents and requests, and eventually run fundraising—without the UI feeling like a generic enterprise SaaS bolted onto crypto. Early objectives covered founder and investor fundraising workflows, including equity/token visibility and wallet autonomy.

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.

{
  "color": {
    "bg": { "value": "#0A0915" },
    "surface": { "value": "#141225" },
    "primary": { "value": "#2E7DFF" },
    "text": { "value": "#FFFFFF" },
    "muted": { "value": "#9CA3AF" },
    "success": { "value": "#22C55E" },
    "warning": { "value": "#EAB308" },
    "danger": { "value": "#EF4444" },
    "neutral": { "value": "#6B7280" }
  },
  "spacing": {
    "xs": { "value": "4px" },
    "sm": { "value": "8px" },
    "md": { "value": "16px" },
    "lg": { "value": "24px" },
    "xl": { "value": "32px" }
  },
  "type": {
    "heading": { "value": "28px/600" },
    "body": { "value": "14px/400" },
    "meta": { "value": "12px/400" }
  }
}

Token values reconstructed from the early kit visuals for handoff clarity—not a shipped tokens pipeline.

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.