30 years of product design. A live app shipped solo in 2026. An AI-native workflow that produces specifications a machine can build from. Here's why I'm the right fit for Defaqto.
You've named five requirements explicitly. Here's my specific evidence against each one — real work.
I built a dual-brand design system for Artfuly.com and rachaelpage.com from a single shared token base — one colour system, one type scale, brand-specific layers on top. It's live and in production.
View the live dual-brand guidelines →
Tokens → components → page templates: the same structure your brief describes. And I built it in a single afternoon using Claude to demonstrate the approach.
I built the Terra Listens design system using atomic design methodology — atoms, molecules, organisms feeding into page templates, with a master Figma file that propagated changes across all product screens. Two-plus years as Principal Product Designer maintaining that system across multiple product surfaces.
I also built Ticklists brand guidelines as a structured HTML doc: atoms (colours, type, icons), molecules (form states, card variants), organisms (navigation, list patterns). The app itself is currently a functional beta — visual polish is intentionally deferred until the product concept is validated. Because everything is built from this system, that polish phase will be fast and consistent when it comes.
View Ticklists design system →
This is rare, and it's genuinely my strongest differentiator. I don't just use AI tools — I design for how AI builds and maintains UIs. My day job for the past year has included evaluating AI design outputs for a major AI company, giving structured feedback on typography, colour, hierarchy, layout, and constraint systems.
The result: I write component specs in a format AI can act on without ambiguity. See the live example below — I've written a real Defaqto-style status component spec to show what my output would look like.
Skip to the AI-ready spec demo →
I've used Figma across long, complex projects — component libraries, auto-layout at every level, shared styles feeding all screens. For Terra I maintained a living Figma system across multiple product lines for 2+ years.
My working style now uses Figma variables and tokens as the source of truth, with design decisions made at the root level to propagate automatically. I can show you the Terra Figma file on request — it demonstrates the systematic approach you're describing.
Veda/Inivio: Senior UX Architect on a complex self-serve B2B data platform for financial and marketing professionals. Multi-step data processing workflows, lead generation, address validation, data profiling — directly analogous to Unity's adviser workflow.
ING banking app (new product from scratch), Bob Finance (mobile loan UX), Inyova (impact investing startup). KPMG and PwC enterprise user research.
Fintech is not new territory for me.
Ticklists solves this exact problem in production today. ticklists.com (marketing) and ticklists.app (the Progressive Web App — installable on any device, no App Store needed) share the same design tokens, component language, and visual rhythm. No visual reset when you move from one to the other.
I also run Artfuly.com and rachaelpage.com from a single shared codebase — same system, different brand expression. That's the exact multi-brand-one-family model you're describing.
Both apps are live and working in production. The UI is deliberately MVP (Minimum Viable Product) stage — built to validate the concept before investing in visual refinement. The system is already in place to make that upgrade fast.
Not mockups. These are real guidelines driving real products you can open in your browser right now.
One shared token base. Two distinct brand expressions. Colour system, typography scale, spacing grid, component variants — all built with CSS custom properties so a single root change propagates everywhere. This is the same architecture Defaqto needs.
Open live guidelinesAtoms to organisms: colour tokens, type scale, spacing, icon system, card variants, form states, navigation patterns. Built as structured HTML — AI-readable as well as human-readable. The live app UI is MVP (Minimum Viable Product) stage; the system is the foundation that makes visual polish a fast, systematic upgrade rather than a rebuild.
Open live guidelinesAtomic design methodology across a complex multi-feature SaaS: native apps, marketing site, data dashboard. Principal Product Designer and PM for 26+ months. Figma system feeding multiple product surfaces. Client testimonial from Scott Whittle.
View the product siteEvery colour, spacing value, shadow, and type size on this page is defined as a token — a CSS custom property. To rebrand the entire page, I change values at the root. Nothing else. That's the architecture I'd build for Defaqto.
Selected for relevance to your brief: B2B SaaS, fintech, complex adviser workflows, and multi-brand systems.
Full-stack product designed and shipped solo from zero. Real-time shared lists, cross-platform Progressive Web App (PWA — installs from the browser, no App Store needed), Stripe payments, full brand and design system. Proves I can take a product from nothing to live without a team — the same challenge Defaqto faces with Unity.
The closest match to Defaqto Unity in my portfolio. Complex self-serve B2B data platform for financial and marketing professionals. Multi-step workflows: lead generation, address validation, deduplication, data profiling. Agile with BAs and market experts. Same DNA as an adviser workflow.
Two-plus years as Principal Product Designer and PM on a complex native app with live device data, onboarding flows, data entry, device management, and streaming UX. Managed developers. Went through multiple major design iterations. Client testimonial available from Scott Whittle.
Financial services across banking, lending, and impact investing. Plus enterprise user research with KPMG and PwC. Not adjacent to fintech — I've been doing it for years.
Not starting from blank. Starting from what you have, building on it, testing at every stage. This is how you get to a system that scales — not by designing everything up front.
Map what already exists — Defaqto brand materials, the design file from your in-house UX designer, Unity's current patterns. Understand what's working before changing anything.
Extract the tokens that must be consistent across all brands: layout grid, spacing scale, base type scale, motion principles. This is the foundation every surface inherits from.
Defaqto.com, Unity, VouchedFor, RSMR each get a brand-specific token set that overrides only what needs to change. Colour, tone, imagery emphasis — not structure or interaction.
Each component and pattern validated against all brand contexts before moving on. Defaqto.com live in September doesn't mean the whole system is done — it means the first phase is solid.
The system can be rebranded at any time because I work with variables, global colour tokens, and type styles at the root level. Change a brand colour once and it propagates through every component, every page, every brand surface — automatically. That's not just good practice. For Defaqto, managing 6–7 acquired brands, it's the only way that scales.
What "rebrand at root" means in practice:
Your brief says: "Structured. Explicit. Unambiguous." Most designers don't know what that actually means in practice. I do. Here's a real component spec in the format I'd deliver for Defaqto.
What you're looking at: a specification for a StatusBadge — the small coloured indicators that show "Pending", "In review", "Submitted" etc. across a financial dashboard. Instead of a Figma annotation a developer has to interpret, this defines every variant, every rule, and every visual constraint in a format that can be read by both humans and AI code-generation tools without ambiguity.
// COMPONENT: StatusBadge // Purpose: Communicates the current state of an entity (adviser, product, submission) // Used in: Unity dashboard cards, table rows, adviser profile headers, submission review { "component": "StatusBadge", "version": "1.0", // ─── INPUTS ─────────────────────────────────────────────────────── "inputs": { "status": { "type": "enum", "required": true, "values": [ "active", "pending", "review", "submitted", "expired", "error" ] }, "label": { "type": "string", "required": false, "default": "derived from status", "maxLength": 20, "note": "Override only when status label must match local language or brand voice" }, "size": { "type": "enum", "required": false, "values": ["sm", "md"], "default": "md" } }, // ─── DISPLAY MAP ───────────────────────────────────────────────── "displayMap": { "active": { "label": "Active", "token": "--status-green", "icon": "dot-filled" }, "pending": { "label": "Pending", "token": "--status-amber", "icon": "clock" }, "review": { "label": "In review", "token": "--status-blue", "icon": "eye" }, "submitted": { "label": "Submitted", "token": "--status-teal", "icon": "check" }, "expired": { "label": "Expired", "token": "--status-grey", "icon": "minus" }, "error": { "label": "Error", "token": "--status-red", "icon": "alert" } }, // ─── RULES ──────────────────────────────────────────────────────── "rules": { "use": [ "To communicate the current lifecycle state of a record", "In table rows, cards, and profile headers where state is actionable information", "Alongside the entity name, not in isolation" ], "doNotUse": [ "For decorative categorisation (use a Tag component instead)", "When state is not directly actionable by the current user", "More than one StatusBadge per row or card" ] }, // ─── CONSTRAINTS ────────────────────────────────────────────────── "constraints": { "layout": "Inline flex, icon left of label, no wrapping", "padding": { "sm": "4px 8px", "md": "6px 12px" }, "typography": "font-weight: 600; font-size: var(--text-xs); letter-spacing: 0.04em", "iconSize": { "sm": 10, "md": 12 }, "borderRadius": "var(--radius-sm)", "backgroundOpacity": 0.12, "behaviour": "Never interactive (not a button, no hover state)", "accessibility": "aria-label must include status value; colour alone must not communicate state" } }
No notice period, no other contracts blocking a start. I'm happy to begin with 10 hours and reassess from there. No pressure and no hard feelings if the fit isn't right — I'd rather both sides know early.
I can invoice weekly or on agreed milestones. Based in Germany (Brandenburg), invoicing as a sole trader with German tax registration. Weekly invoicing works well for a time-tracked engagement.
As a German-registered sole trader providing B2B professional services to a UK company, German VAT does not apply. Invoices to Defaqto would be issued without VAT, which means no VAT for you to reclaim. (Please confirm with your finance team — this is my understanding of the post-Brexit cross-border B2B rule.)
Collaboratively, with clear decision-makers. I bring a point of view and I push back when I think a decision will hurt the system's integrity — that's part of what you're paying for. I work AI-natively, which means faster iteration and better-documented outputs than traditional design processes.
I'm excited about this project. The multi-brand, AI-ready design system problem is exactly what I'm set up to solve — and September is a tight but achievable deadline for the first phase.
