← Back home

Work

I'd rather show how I think than a gallery of polished mockups. These are products and features I designed and helped build — the problem in front of me, how I reasoned about it, and what actually shipped. The screens are deliberately low-fidelity: they're here to carry the idea, not to look pretty.

Cantina

A platform for security researchers. I led platform design from inception — launching new products, redesigning core flows, and maintaining the design system — then moved into a Design Engineer role to build the interfaces I was designing, directly in the codebase.

01

Clarion

A response console for security researchers to detect, triage and mitigate live exploits under pressure.

+--------------------------------------------------------+
| (*) Clarion   Security agent      [Okta]  ( PR ready ) |
+---------------------------+----------------------------+
| AGENT ACTIVITY            | FINDING             [HIGH] |
|                           | Okta session fixation      |
| [x] Flagged login burst   | Session stays valid after  |
| [x] Traced to Okta SSO    | logout - a stolen token    |
| [x] Session not cleared   | can be replayed. CWE-384   |
| [x] Wrote fix + test      |                            |
| [>] Opened PR #482        | PULL REQUEST               |
|                           | #482 Invalidate Okta       |
|                           | session on logout          |
|                           | +38 -4    3 files          |
|                           | [x] All checks passed      |
|                           | [  Review & merge  ]       |
+---------------------------+----------------------------+
Clarion works a security issue end to end. Here the agent has flagged an anomalous login, traced it to the Okta integration, and opened a pull request with the fix and a regression test — the whole thread on one screen.

The problem

When an exploit is live, minutes cost money. Researchers were coordinating across scattered tools with no shared source of truth, so response was slow and easy to get wrong exactly when precision mattered most.

How I reasoned about it

  • Designed the interface around the one question a responder asks first — “what is happening right now, and what do I do next?” — instead of burying it under configuration.
  • Consolidated the critical incident data into a single dashboard so the state of an incident is legible at a glance, not reconstructed from five tabs.
  • Structured the flow around playbooks tied to specific attack vectors, so established protocol is one click away rather than tribal knowledge.
  • Treated it as a collaborative workspace from the start: assigning tasks, sharing insights and coordinating a team is the job, not a feature bolted on later.

What shipped

  • A real-time incident dashboard consolidating detection, analysis and mitigation.
  • Vector-specific response playbooks built into the workflow.
  • Shared workspaces for task assignment and coordinated response.
  • Configurable alerts that pull the right expert in at the right moment.
02

Agent Creation Wizard

The primary way people use Clarion: turn an existing security playbook into a working agent, with the right tools already wired up.

+------------------------------------------------------+
| Create agent                               [#][ ][ ] |
| Turn a playbook into a working agent                 |
+------------------------------------------------------+
| (1) Playbook    2 Tools    3 Test    4 Review        |
|                                                      |
| UPLOAD PLAYBOOK                                      |
|   .--------------------------------------------.     |
|   |                   [ ^ ]                    |     |
|   |             Drop your playbook             |     |
|   |          PDF or DOC - up to 20 MB          |     |
|   '--------------------------------------------'     |
|                                                      |
| [PDF] incident-playbook.pdf   Uploading 100%         |
+------------------------------------------------------+
The wizard's core move, start to finish: upload an existing playbook — often just a PDF — and it drafts a dedicated agent to run it, with the right tools already wired up. A few guided steps take a non-engineer from document to a working, testable agent.

The problem

Teams already had playbooks — often just a PDF or a doc — describing how to handle a class of incident. But turning one into an automated agent meant wiring up tools, monitors and instructions by hand: slow, technical, and easy to get wrong. The playbook and the agent it was supposed to power drifted apart.

How I reasoned about it

  • Made the playbook the starting point, not an afterthought: you upload the existing document and the wizard drafts an agent to run it, tools already connected.
  • Broke agent creation into a clear multi-step wizard, so someone who isn’t an engineer can go from playbook to running agent without touching configuration.
  • Learned from real usage and reframed a step — replacing “Playbook” with a “Test” step — so people validate an agent’s behaviour before shipping it.
  • Auto-connected and categorised the tools an agent needs (GitHub, Okta and the rest), with helpers for the integrations that were fiddliest to set up.
  • Kept iterating on the management side as the feature matured: a revamped edit page, redesigned agent cards, tabbed monitors vs. common instructions, and an active/inactive toggle.

What shipped

  • The Agents page and multi-step creation wizard — the platform’s primary user-facing feature.
  • A playbook-to-agent flow: upload a playbook, get a configured agent with tools connected.
  • A dedicated Test step, tool categorisation, and GitHub integration helpers.
  • A revamped agent edit and management experience — monitor editing, tabbed monitors/instructions, redesigned cards, and active/inactive control.
03

Code Reviewer & Findings

A collaborative environment where researchers read code, flag vulnerabilities and talk to clients — without leaving the codebase.

+----------------------------------------------------------+
| FINDINGS / CODE REVIEW                                   |
+------------------------------+---------------------------+
| CODE   Vault.sol             | ANNOTATION                |
|                              | [ Private ]  ( Public )   |
|   1  function withdraw() {   |                           |
|   2    checkBalance(user)    | +---------------------+   |
|   3    send(user, amount)    | | Reentrancy: state   |   |
| > 4    balances[user] = 0  < | | written after send. |   |
|   5  }                       | | Mark as finding?    |   |
|                              | +---------------------+   |
|                              | @teammate     client >    |
+------------------------------+---------------------------+
Discovery and documentation live in the same place. You highlight a line, annotate it right there, and choose whether the note is a private thought or a client-facing finding — the reasoning stays attached to the evidence.

The problem

Security review lived across the code, a note-taking tool and a chat app. Context was constantly lost in the gaps, and clients had no clean way to follow the reasoning behind a finding.

How I reasoned about it

  • Kept discovery and documentation in the same place: you highlight a code segment and annotate it right there, so the reasoning stays attached to the evidence.
  • Separated private working notes from public annotations, so researchers can think out loud before anything is client-facing.
  • Made collaboration first-class — tag a teammate for input, or open a direct line to the client for clarification, inline.
  • Designed the Findings view as the shared hub where every result from reviews, competitions and bug bounties is tracked from discovery to resolution.

What shipped

  • Inline scoping and annotation directly on the codebase.
  • Private and public annotation layers.
  • Teammate tagging and direct client communication in context.
  • A central Findings view for triage, discussion and resolution tracking.
04

Dashboard Onboarding

The first five minutes: turning sign-up into a productive first session.

The problem

A powerful security platform is intimidating on day one. New users landed on a dense dashboard with no sense of where to start, and drop-off happens fastest before anyone sees the value.

How I reasoned about it

  • Framed onboarding as “get to the first useful action,” not “tour every feature.”
  • Used a guided flow with interactive tutorials and contextual tooltips, so guidance appears where the user already is instead of in a separate manual.
  • Suggested concrete first actions to give momentum and an early sense of payoff.

What shipped

  • A guided onboarding built into the dashboard.
  • Interactive tutorials and in-context tooltips.
  • Suggested first actions to shorten time-to-value.

Soplaya

A B2B marketplace that lets chefs and restaurants discover, compare and buy fresh ingredients directly from local producers. I led the product design end-to-end — from vision and user flows to the interface across iOS and Android — and created the brand.

05

Soplaya App

Procurement for chefs, in a couple of taps instead of a stack of phone calls.

.------------------.    .------------------.
| BROWSE           |    | YOUR ORDER       |
| [ search...... ] |    |                  |
| (Meat)(Veg)(+)   |    | [x] Beef    x2   |
| +------------+   |    | [x] Eggs    x3   |
| | Beef       |   |    | [x] Basil   x1   |
| |   8.50 /kg |   |    | -------------    |
| +------------+   |    | Total    42.10   |
| | Eggs       |   |    |                  |
| |   3.20 /dz |   |    | [  Checkout  ]   |
| +------------+   |    '------------------'
'------------------'
A B2B marketplace that reads like a consumer app. Chefs browse local producers, compare fresh ingredients on price and origin, and reorder in a couple of taps — so procurement stops eating the day.

The problem

Sourcing fresh ingredients meant juggling phone calls, WhatsApp and paper lists across many suppliers. It was slow, error-prone, and stole time chefs would rather spend cooking.

How I reasoned about it

  • Started from the flows, not the screens: how a chef discovers a producer, compares options, and places (and repeats) an order — end to end.
  • Made a B2B tool feel like a consumer app: clear product cards, price and origin up front, so comparing is instant.
  • Optimised for the real pattern — reordering the same ingredients weekly — so the frequent path is the fastest one.
  • Kept one consistent, intuitive interface across iOS and Android, in close collaboration with the PO and engineers.

What shipped

  • Native iOS and Android apps, designed end-to-end.
  • Discovery and comparison of ingredients from local producers.
  • A streamlined ordering and reordering flow.
  • A consistent cross-platform interface and component library.
06

Brand & Visual Identity

A logo that puts the two sides of the marketplace — chefs and producers — in plain sight.

The problem

A young marketplace needed an identity that signalled its values — sustainability, transparency, technology — and represented both communities it served, without overcomplicating things.

How I reasoned about it

  • Made the two faces in the logotype stand for the two entities at the heart of Soplaya: chefs and producers, in one ecosystem.
  • Embedded two leaves in the letterforms as a quiet nod to the circular economy and an eco-friendly supply chain.
  • Leaned into transparency literally — the logo is simply the name, nothing hidden — and kept the shapes minimal to say “technology means simplicity.”

What shipped

  • A new company logo and logotype.
  • A visual identity system spanning product and marketing.

Want the short version? Read the resume or get in touch.