01
Frame the problem
I use research, product context and writing to make the decision visible before polishing an interface around it.
Workbench
The tools are part of the design process.
I move between research, visual systems, product flows, working software and content. The useful question is not which tools are in the stack. It is what each one lets me see, test or ship before I make the next decision.
Tools I use
Different tools for different kinds of certainty.
Using · Interface & visual craft
Figma
The main surface for interface detail, systems, composition and visual judgement.
I use Figma to resolve the parts of a product that need visual precision: hierarchy, responsive composition, interaction detail, components and presentation.
Figma →
Using · Reasoning & implementation
ChatGPT + Codex
A working partner for synthesis, product reasoning, implementation and critique across a codebase.
I use the loop to interrogate decisions, work through implementation constraints, inspect evidence and carry design intent closer to production instead of stopping at a handoff.
ChatGPT →
Using · Parallel design & build loop
Claude + Claude Code
A second reasoning and code path for prototyping, critique and implementation work.
I use it to pressure-test product structure, explore alternatives and work directly against implementation, especially when a design question is easier to judge in a running interface.
Claude →
Using · Structured content
Sanity
The content layer behind this portfolio and other systems where editors need control without breaking the product.
I model content so product structure, editorial control and presentation stay separate. This site is deliberately moving more of its public surfaces into Sanity instead of leaving them hardcoded.
Sanity →
System · Production surface
Next.js + Vercel + GitHub
The layer where prototypes become inspectable software, deployments and versioned decisions.
I use code and preview deployments to test the actual responsive behaviour, content model, performance and edge cases rather than treating the final Figma frame as the end of the design.
Design engineering on GitHub →
The loop
A design workflow that gets closer to the thing itself.
02
Prototype the behaviour
Flows move between interface design and working prototypes so states, data and edge cases can push back on the concept early.
03
Make the system coherent
Once the behaviour holds, I tighten typography, composition, motion, components and content into something people can actually use.
Things I am building
Some problems are easier to understand once I build the tool.
Building · Working software
ApplyOS
An AI-assisted job-search operating system for assessing fit, finding roles, running applications and learning from outcomes.
It is also a test bed for my current design-build loop: journeys and system rules become working software early enough for real usage to expose what the static design missed.
See the build notes →
Building · Live product
Fleetpass
A simple way to track vehicle and driver documents before expiry becomes a roadside surprise.
The product is organised around one question: when I open it, can I immediately tell what needs my attention? Document upload, missing-document logic and urgency sorting all follow from that.
See Fleetpass →
Building · Public resources
African visual infrastructure
African Icon Library, Nigerian Mockups and Retna are three responses to the same old problem: generic visual material standing in for African people and products.
Icons, local mockups and photography become shared visual infrastructure rather than one-off brand assets.
Explore the public work →
What stays constant
The stack changes. The loop matters more: get close to the problem, make the uncertainty visible, build enough to test the decision, then refine what survives.