Complex systems, designed so someone can own them.

Context

Most portfolio work happens inside somebody else's constraints. This is the one case where the strategy, positioning, pricing, brand and build were all mine to set. Small businesses need a genuine brand system, an accessible site and, increasingly, AI tooling, but rarely the budget or patience for an agency process built for enterprise clients. Bespoke engagements mean every enquiry needs a scoping call before anyone knows if it's worth having, which filters out exactly the clients who need the work most.

Approach

Stopped selling design hours and started selling a defined outcome at a published price: a fixed fee build, a monthly care subscription from launch, scope returned in two working days, build landed in three weeks. Built the brand system first, as a Figma library, then applied it across brand systems, website design and custom AI tooling built to WCAG AA. The offer is modular (site build, local search, AI handling of inbound enquiries), each standing alone and each more useful with the others.

Position

The site states plainly that the design work is done by a person with a design degree and ten years of practice, and that AI is used for admin and code but never for the visible design.

Outcome

Seven client engagements delivered since October 2025, including The British School of Excellence, ADHD Andy and JLJ Real Estate.

Problem

A saved JQL filter starts life as a convenience for one person. At organisational scale it turns into infrastructure that nobody owns: boards and reports depend on it, teams inherit filters from people who have left, and provenance, permission and sync state existed in the data but not the interface. Every question about a filter meant opening it.

Approach

Ran a workshop with team members and customer service agents, then shipped folder creation, advanced search filters, and group, project and team based filtering, testing with real users before locking anything in. Every filter card states who owns it, when it last synced, and its permission position in words rather than a disabled control. "Not Synced" was promoted from an individual discovery to its own triage view, backed by a global JQL Sync Status indicator in the header. One list carries three densities (Compact, Regular, Full) instead of three separate screens.

Outcome

Ownership became visible without opening anything, and stale filters became triageable as a group instead of one discovery at a time.

Context

Trading in a phone requires the customer to assess its condition honestly, then trust the quoted number reflects it. Overstate the condition and the final offer drops on inspection, which reads as a bait and switch; understate it and the customer walks away from money they were owed. Each of the eight European markets had its own regulatory requirements and commercial priorities, which pushed naturally toward eight different journeys and eight places for the experience to drift apart.

Approach

Held the platform together with a single design system rather than a market by market build, coordinating with nine product owners and their development teams to keep releases aligned. The assessment was a short sequence of plain condition questions, each phrased around what the customer can actually see, with concrete examples of what counts as wear against damage. The quote holds for seven days, so no one is forced to decide inside the flow. Multi-language user testing and pricing experiments ran across all eight markets.

Outcome

Drop-off fell 32% for users trading in a phone. The platform shipped into eight markets on one design system, coordinated across nine product owners and their development teams to keep releases on time.

Context

Brought in off the back of FinTech work for banks, onto a platform built with one of the Big Four, inside a five-year IBM programme aiming at the largest-value Watson product in the company's history. Worked daily with EY Transaction Advisory Services' CTO, CDO and CEO. The toolset was the full Watson suite: Discovery News, Social Media Brain, Watson Analytics and Cognos Analytics. The job was turning that capability into something an analyst would choose over the several tools already in use.

Approach

Discovery broke the application into four parts, any of which could have shipped as a standalone product: Orchestration (sign-in, workspace, project setup), Outside In (company research: news, social, financials), Smart Data Room (document classification, OCR, keyword search) and Analytics (visualisation and correlation). Wireframes came first because the argument was about structure. A single site map held everything agreed for beta, pushing the rest explicitly into release one and two, which is what stopped scope creep on a programme this size.

Outcome

The beta shipped to its four month deadline with the MVP intact, the outcome that matters on a programme this size: the scope held.

Context

Chargeback disputes are deadline-driven, with money and liability moving between a cardholder, a merchant and two banks. At Barclaycard, significant parts of it were still carried by fax and post: no state, no audit trail, no way for an agent to answer where a case had got to. Joined an established team in Northampton with strong data flow and requirements, but no design or usability perspective, on a deadline that left no room to discover that late.

Process

Three attempts at the same table. First: everything on the summary screen, complete but too busy to read. Second: columns cut, detail moved to a sliding panel, which fixed the density but broke the job, since the row no longer carried enough to decide without opening the case. Third: user research established the exact fields an agent needs to decide, cutting the heavy modal prototype down to one screen and three modal states, decided from the row in about five seconds. Then the real constraint arrived: the back end was 25 years old, forcing a reversion to an older Barclaycard design language. Compliance with a legacy system is a design material, not an afterthought.

Outcome

The portal replaced a fax and post process with a single record carrying its own state, evidence and history. The interface that shipped was the third attempt, the one that survived contact with real agents, because the research established what a decision actually requires rather than what a requirements document listed.

Context

Energy companies were pushing smart meter adoption onto customers with starkly different trust profiles. Jen, 22, wanted to fully automate her billing and never call npower again, frustrated when meter readings meant staying in from lectures. Alex, 66, wanted to know he was saving money but preferred a human on the phone, and had spent years unable to convince his wife a smart meter wouldn't let hackers into their home. Designing one onboarding flow for both was the actual brief.

Approach

Replaced the sign-up form with a conversation: "Piper", a virtual assistant for energy, takes an email, sends a one-time passcode, offers Face ID, then walks the customer through photographing their existing meter, auto-detecting it in frame before booking an engineer visit. The chat interface answers Jen's need to never phone in, while the plain, step-by-step confirmations at each stage (an engineer's name and photo, an exact arrival window, a completed-job rating) give Alex the reassurance a faceless automated process wouldn't.

After installation

Usage became a gamified relationship rather than a monthly bill: daily consumption compared against similar households, savings tracked year on year, monthly awards for reduced usage, and a friends and referral system with leaderboards by street, town and city, built so a convert like Jen could pull in her own dad.

Outcome

A 39-screen working prototype covering the full lifecycle: sign-up, meter ordering, engineer visit, day-to-day monitoring, and the competitive and referral loop that kept it in daily use afterwards.

Problem

People considering an electric car ask the same questions: will the range cover my week, where would I charge, and would it actually cost less. Brochures answer those in general. The only honest answer uses the driver's own journeys, and nobody keeps a record of those.

Approach

Turn the question into a two to four week experiment the driver runs without effort. Onboarding captures the current car, its miles per tank and cost per tank, plus a handful of regular routes. From then on the app tracks trips automatically and replays each one as if it had been driven in a 2018 Ford Focus Electric: an EV score for the trip, the saving against fuel, and the breakdown behind both. A running EVme score builds across the trial, alongside mileage, money saved, charges needed and energy used.

Designed for trust

Every number traces back to a real trip the driver recognises, from home to work at 08:00, which is what makes a score of 93 believable rather than a sales line. The final report says what the score means in plain language, then offers the next step at the point of highest confidence: book an extended test drive.

Outcome

Built as an IBM pitch asset in three days. The brief had discussed seven or eight screens; the delivered set was a complete, clickable journey of 36 screens from onboarding to final report, which the IBM account lead said helped show Ford that IBM had a serious design capability as well as the ability to build the app. See the Feedback section for Russell Gowers and Paul Andrew Smith on this engagement.

Context

IBM and Ford set up an innovation hub inside Ford, with a target of 3M in added value through cost recovery or new revenue. Discovery sessions, guest lectures and design thinking workshops with Ford executives produced 183 concepts, plotted on a grid of importance to the user against feasibility. They were cut to the three with the highest business value. I was brought in to apply design thinking to those three under tight deadlines, with a few days to understand each before going deep on the experience.

Problem

Building a prototype vehicle means validating its Bill of Materials, the full list of parts. Engineers and BOM operations teams reviewed it largely by hand, which wasted parts and time. A technical proof of concept, trained on 10,000 historical vehicles, showed an AI model could predict a new BOM far more completely than the current process. The question for design was how people would actually work alongside that prediction.

Approach

Two personas carried the design: the BOM operations manager, who delegates parts, and Eddy, a 30-year-old engineer of eight years at Ford who wanted fewer emails and phone calls, less time on the BOM and more on proper engineering. Working directly with Ford's data scientist, I ran exercises to find where the story really started and ended, then mapped the flow on a whiteboard. It had to fit inside the tool Ford already used rather than replace it. Paper mock-ups with Ford users came first, then Sketch wireframes, daily check-ins so no design decision broke the model, and an InVision prototype signed off by IBM and Ford.

Ten iterations to clarity

The back and forth between engineer and manager made this the hardest part. Early versions showed each part against the AI's predicted total for every control model, with discrepancies highlighted, and were too dense to act on. After roughly ten rounds with users, three changes made it work: showing at most five control models at once, notifications ranked by how urgently parts needed checking, and an inline drop-down so an engineer could judge at a glance and drill down only when needed.

Outcome

The screens went into a pitch to Ford partners, where I answered the design questions, and on to senior management with a four-step plan: find a team to fund a pilot, run it on the current technical model, review the results, then build a full BOM interface if it succeeded.

Problem

GfK's Market Intelligence product tracks point-of-sale data for manufacturers like Lenovo and Panasonic. Channels are genuinely hierarchical, up to eight levels deep, but the platform drew that hierarchy flat, so reading the structure was the job rather than the starting point. Nothing on the market solved this shape of problem directly.

Approach

Planned and facilitated a week-long remote design sprint with around 20 people across the squad and sales department. The governing rule: the user sees the most granular view their subscription permits. Paper prototyping produced three candidates; weekly internal testing narrowed it to lines versus dots, then an A/B test with real sales directors at Philips, Samsung, Hitachi and Miele settled it. Dots won, and not narrowly.

Outcome

Shipped into gfknewron. The more useful outcome was the one nobody briefed: the same flaw in how data was presented surfaced in three further platform features, turning a single-page fix into a case for a platform-wide redesign.

Problem

Faculty's data science platform was adding features faster than the navigation bar could carry them, with no design brief handed down. Research with Faculty's own data scientists found the tell: people kept duplicate browser tabs open and typed terminal commands rather than navigate. Five specific failures were documented, including a "help" link that opened a Zendesk field nobody recognised as support.

Approach

Competitor analysis ruled out the category itself: Databricks had no nesting, SageMaker too many layers, Domino's permanently-present bar shrank the workspace. The useful pattern came from outside data science entirely, from Firebase's collapsible, expandable groupings. Grouping strictly by the six-stage data science workflow produced categories of one feature, so the working rule was coarser: input and output. That gave three groups (Development, Production, Project settings), built in one week as an explicit MVP.

Outcome

First internal review came back around 90% positive, called implementable with a little UI work, while the company itself grew roughly tenfold.

Context

KYC and AML checks are non-negotiable in a regulated product, but handled carelessly they are the single most reliable way to lose a user mid-onboarding. The problem was never whether to ask for verification, it was how to ask without the journey reading as an interrogation.

Approach

Redefined the onboarding journey from user research rather than the compliance checklist outward, balancing the regulatory requirement directly against completion rates at every step, treating each verification step as part of the product experience with its own stated reason. Mentored a junior UI designer through the engagement, working alongside the Head of Design to keep output consistent with Radix's wider language.

Outcome

Delivered three separate projects within a three-month window. The clearest surviving artefact of this thinking is Instabridge, next below, where the AML tier stopped being a back-end rule and became an object on the dashboard.

Problem

Moving value between two independent ledgers is not a layout exercise: the user hands over funds and waits through a settlement process they cannot observe. Ethereum and Radix have different finality behaviour and no shared source of truth. On top sits an AML ceiling; scoped as a back-end rule, a breach is an error message arriving after the user has already committed to an amount.

Approach

Moved the AML position onto the dashboard as a permanent object rather than a rule that fires on submission: current tier, refresh date, ceiling, how much is consumed, how much remains, and a direct path to raise it, all next to the balances it governs. Both chain balances are given equal weight. The swap opens over the dashboard rather than a separate page, and "In Flight" exists as a first-class transaction status rather than the interface going quiet during settlement.

Outcome

A limit the user can see before choosing an amount is a planning input; a limit discovered at submission is a failure state. The transferable lesson: take a constraint the system already knows about the user, and put it where the decision gets made rather than behind the button that fails.