×
01 / 30

About Jonathan Simcoe

I’m a very curious designer, writer, photographer, husband, father, and more. I draw inspiration from architecture, science fiction, poetry, mythology, and theology.

Jonathan Simcoe
A child reading A Kids Book About BelongingA child holding A Kids Book About CreativityA child holding A Kids Book About FeminismHands holding A Kids Book About Adventure

Demo journeys

In a week we shipped an interactive layer to Mercury demo that was deeply connected to our marketing site.

Try out Mercury for yourself
  • Send money to contractors
  • Invite your team members
  • Create cards for your team
  • Request vendor payment details
  • Issue SAFE to investors
Understand your dataTry Command

We launched the Mercury Demo in early 2022

Mercury Demo dashboard drawn in gray outlines, showing the navigation, account balance chart, accounts, cards, bill pay, and invoicing.

It all started with the demo bar...

Mercury dashboard in gray outlines
Explore the Mercury Demo.Customize your experience
Viewing as Admin

...that was driven by Mock.

MOCKOur internal-facing mock site, similar to the public demo.
Customize Mock
DEMOExplore the Mercury product.
Customize Demo
Mercury dashboard in gray outlines
Explore the Mercury Demo.Customize your experience
Viewing as Admin

The Mercury marketing site

Features designed for hockey sticks

Rare tools for companies moving up and to the right.

Explore demo
API access
User permissions
Integrations
Mobile apps
Cash management
Sharp security
...and more

The site changed but demo visits decreased

Start with banking basics that just work

Store, manage, and move your funds.

Open FDIC-insured checking and savings accounts.

Easily issue employee debit and credit cards with custom limits.

Pay vendors and employees through ACH, wires, checks, and foreign exchange.

Explore Demo

Fast forward to Hackweek 2026

What if we could revamp the whole journey and guide users around demo to create deeper engagement?

WebsiteDemo journeyProduct features
mercury.com/ecommerce
MercuryProduct
Ecommerce

Built for your
next big order.

Explore demo
Try out Mercury for yourself
StartupEcommerceAgencyMore
Understand your dataTry Command

Virtual cards

Bank accounts

Working capital

The first task was to iterate and explore what a guided journey could look like.

Coachmarks

demo.mercury.com
Create a virtual card

Category first

demo.mercury.com
Try out Mercury for yourself
01

Choose your business

Startup
Ecommerce
Agency
More
02

Explore Ecommerce

Assign virtual cards to your team
Manage bank and treasury accounts
Track your working capital

Anchored side panel

demo.mercury.com
01 / 03

Start with a virtual card

Journey panel permutations

Early v0 prototypes helped our team align

We also explored a deeper, more natural integration on the website

Funding for what’s next?
Add to cart.

Flat-fee pricing and competitive rates

Easy-to-understand terms so you know your true cost of capital.

Fixed weekly repayment schedule

Forecast your finances without the unpredictability of revenue-based payback.

Long-term partnership

Get a helpful consultant with ecommerce expertise as you run, grow, and scale.

Transparent terms designed to help you grow

Get the most for your business

With our holistic underwriting process, we look at revenue from all your ecommerce sales platforms to ensure you get the best offer.

Unlock funding that doesn’t hold you back

  • Use funds for anything your business needs — we trust you to know what’s best.
  • No personal guarantee, so your personal assets aren’t on the line.
  • No prepayment fees because we don’t think you should be penalized for growth.

Forecast the road ahead

With fixed weekly payments on your working capital loan, you’ll know exactly how much you’re paying and leave the unpredictability of revenue-based repayment behind.

Explore working capital in MercuryTry Demo

All the permutations

Try out Mercury for yourself

Continue your journey by signing up.

Try out Mercury for yourself
  • Send money to contractorsCompleted
  • Invite your team membersCompleted
  • Create cards for your team
  • Request vendor payment detailsCompleted
  • Issue SAFE to investorsCompleted
Understand your dataTry Command
Try out Mercury for yourself
  • Make a payment
  • View transactionsCompleted
  • Create a cardCompleted
  • Send an invoice
  • Track tasks across MercuryCompleted
Understand your dataTry Command
Try out Mercury for yourself
  • Assign virtual cards to your team
  • Manage bank and treasury accountsCompleted
  • Track your working capital
  • Review and edit team card limits
  • Set team permissionsCompleted
Understand your dataTry Command
Try out Mercury for yourself
  • Send payments to vendors
  • Set up accounting integrations
  • Create and track invoicesCompleted
  • Manage your subscriptions
  • Set card limits per merchant
Understand your dataTry Command
Try out Mercury for yourself
  • Send money to contractors
  • Invite your team members
  • Create cards for your team
  • Request vendor payment details
  • Issue SAFE to investors
Understand your dataTry Command

Play with it

Agentic Design System

Our project shaping design intelligence through agent tooling and a skills platform to guide consistent output.

Code
Prose
Context
mercury.dsds.yaml
Buttoncomponent
Inputcomponent
Colorfoundation
Spacingfoundation
Form layoutpattern
Resolved · v0.20.1
Humans
Agents

About the project

An agentic extension to our design system in partnership with engineering. We built a way for humans and agents to have one legible system that produced deterministic output at the component level.

It started with a documentation problem we could no longer ignore...

My role
Lead designer
Our team
Myself, 1 engineer
Mercury
DSDS spec
ManifestOne legible system
DesignersEdit guidance
EngineersDocs near code
AgentsStructured detail

Four sources of truth was no source of truth

Mercury's design system documentation had become outdated and scattered across four places. Each source was useful in isolation, but none could resolve the others.

A designer, engineer, or agent asking the same question could get a different answer depending on where they looked. The bigger a product team is, the more this compounds.

Which Button
is right?
Code JSDocsPartial
/** Primary action. */
variant?: "primary" | "ghost"
size?: "sm" | "md"
Notion + custom siteStale
  • ButtonEdited 2023
  • BannerEdited 2022
  • BadgeDraft
Vibe-coded toolDivergent

Three versions of Button

ButtonButtonButton
FigmaSporadic

Docs for some frames

A two-person undertaking

I got buy-in from our VP of Design and engineering leadership, then drove the project end-to-end with one engineer.

We built a new source of truth on top of the DSDS spec, then a skills platform that scaffolded the YAML manifest and mined insights from GitHub, Slack, and Notion.

GitHub
Slack
Notion
design-system
  • AGENTS.md
  • .agents/skills
  • scaffold-manifest
  • mine-system-context
  • SKILL.md
  • references
  • github.md
  • slack.md
  • notion.md
  • author-documentation
  • manifest
  • mercury.dsds.yaml
  • components
  • foundations
  • patterns

mine-system-context / SKILL.md

Mine system context

Resolve what the team already knows into the manifest.

  1. Read merged component PRs on GitHub
  2. Collect decisions from Slack threads
  3. Sync guidance pages from Notion

Write findings to manifest/

Structured for machines, written for people

The schema made design system knowledge portable without flattening it: agent clarity, human texture. Guidelines, definitions, metadata, and references are modeled explicitly instead of buried in page layouts.

The same resolved source produces a concise human view and a more verbose agent view.

mercury.dsds.yaml
schemaVersion: "0.20.1"
name: Mercury Design System
entries:
  - kind: component
    id: button
    name: Button
    purpose: Gives users one
      consistent way to act.
    sections:
      - kind: guidelines
        items:
          - level: should
            statement: Limit each
              surface to one
              primary button.
      - kind: definitions
        title: Anatomy

Human view

ButtonGives users one consistent way to act.
ShouldLimit each surface to one primary button.
ContainerLabelIcon

Agent view

kindcomponent
idbutton
guidelines[0]should
statementone primary per surface
anatomycontainer, label, icon
refsaccessibility.dsds.yaml

One resolved system, available everywhere

Human-authored prose still mattered. We combined it with JSDocs and resolved the result inside Storybook, with the Storybook manifest and MCP turned on.

Engineers keep documentation near code, designers edit explanatory prose, and agents read a structured version with the detail they need.

Code + JSDocsComponents / behavior
Human authoredPurpose / guidance
Agent minedGitHub / Slack / Notion
Storybook
ManifestMCPSkillsDSDS
One resolved source
Cursor plugin
Other AI tools
Figma plugins
Future platforms

Deterministic output in Cursor

I pioneered the Cursor plugin, including its structured DS slash commands and MCP integration. Instead of prompting an assistant to imitate Mercury from screenshots or memory, anyone could ask for deterministic output backed by the same manifest.

We were not tying the design system to one model, editor, or vendor.

The results

The best outcome was what we did not need to build: no new third-party documentation site and no parallel publishing workflow to drift out of date.

Our tests showed a massive difference in the specificity, determinism, and quality of agent output.

plugin.json
{
  "name": "mercury-design-system",
  "description": "Deterministic Mercury
    design system guidance",
  "version": "0.1.0",
  "author": { "name": "Mercury" }
}

What we didn't build

Third-party docs site
Parallel publishing workflow

Early results

Faster lookupsDS components in one command
Improved guidancePurpose and rules, not just props
Deterministic outputSame answer across tools

Final Q&A