Make the right thing.
Before you build it.

Working prototypes for customer portals, internal tools and the complex workflows behind them. Put the difficult decisions in front of real people before you commit the engineering time.

Explore the working examples Discuss your project

A first testable build in week one. A fixed quote before we start.

A comment box open on a row of the Accounts prototype, with Myles explaining in the picture-in-picture — **Point to the part that needs to change.**Try the workflow → leave feedback → a clearer next decision.

Twenty years solving difficult product problems.Fintech, enterprise software and operational tools.

Experience working with teams at

Selected work

Complexity you can get your hands on.

For product teams facing a difficult workflow, an uncertain redesign or a decision engineering shouldn’t have to guess at.

Live prototypeFintech · Data-vis

Making investment trade-offs understandable.

Could a non-specialist build a portfolio and understand the numbers?

Try thisMove a slider and watch the whole cash-flow picture move.

Explore the prototype ↗ Read the case study

Live prototypeFintech · Portal

Getting onboarding out of the inbox.

Would fund managers complete the process or go back to email?

Try thisLeave a required field empty and see the workflow catch it.

Explore the prototype ↗ Read the case study

Working examples reconstructed from client projects using synthetic data.

Explore all projects ↗

Your designer. Your direct line.

Hi, I’m Myles.
Here’s how we’ll work.

You work directly with the person designing and building your prototype. I’ll show you how we collect feedback, test the difficult parts and turn what we learn into the next version.

Inside: how feedback is collected, how testing runs and what changed as a result.

“Provided a full product design from a bare specification. I’m a developer myself and I must say that working together was a great pleasure.”

Marcin Szamotulski – Engineering Lead
Blockchain infrastructure research

How it works

Build. Learn. Refine.

Small, visible iterations.
You see the work early and help shape what happens next.

01 · Make it tangible

A working version. In your hands.

We agree the decision, then I scope the key journey and build something your team can actually use: the loading, empty and error states people skip in a mockup and the keyboard paths they skip entirely. It runs on realistic synthetic data rather than placeholder rows, so people react to the workflow itself.

Your first milestoneA testable build, usually in the first week.

02 · Find the friction

Feedback where it matters.

Your team comments directly on the screens, with a name and a timestamp against each one, so you get a prioritised list by Wednesday instead of a forty-message thread. When testing is in scope, a different group tries the actual journey while you watch where they hesitate, back out or give up.

Your evidencePrioritised comments and observed problems.

03 · See what changed

A Monday read on what happened.

Every Monday you get Footprints: a report on the week just gone for each prototype. Where your team, stakeholders and any outside testers spent their time, what they said and what was changed as a result. Prototype tracking runs on local hardware, not a third-party analytics service. Privacy & analytics.

Your outcomeA clearer decision about what to build next.

The work leaves with you.

Built in your design system when you have one. Nothing is locked to my tooling or my accounts.

Working prototype
Source
Components
Tokens
Recorded handover

Clear scope. Fixed quote.

Start with the decision
you need to make.

Two ways to get there. We agree the scope, dates and deliverables before work begins.

Prototype sprint

Make the idea testable.

For teams that need a realistic workflow to review, align around and put in front of stakeholders.

$5,000 starting price, USD

Typically 2 weeks. Dates fixed before we start.

Includes

A working prototype of the agreed journey, real states included
Comments: your team’s feedback on the screens, standard on every project
Two build, comment, revise loops
Weekly findings report (Footprints), every Monday
Keyboard paths, focus order and WCAG 2.2 AA contrast checked as I build
Source, components, tokens and a recorded handover

You bring The decision you need to make, one point of contact and your design system if you have one.

Discuss a prototype sprint

Prototype + user testing

Test the difficult assumptions.

For journeys where the cost of getting it wrong makes direct user evidence essential.

$8,000 starting price, USD

Typically 4 weeks. Dates fixed before we start.

Includes

Everything in the prototype sprint
Participant recruitment, starting during scoping
Sessions that run alongside the build rather than after it
Four build, comment, revise loops, up from two
At kickoff we agree which loops carry a user session and which run on your team’s comments
Findings tied to the decision you are making

You bring Your project context, a decision-maker and a clear description of the users we need to recruit.

Discuss a tested prototype

Stop early. Not right after the first loop? Stop there and pay for that first week only, at a figure quoted during scoping so you know it before anything starts.

Or keep going. Another build, comment, revise loop on the agreed workflow is $1,000, fixed before it starts. Your team reviews it, or users when testing is in scope.

Participant numbers, methods and deliverables are set in your quote. New journeys, further research, design systems, UX audits, build-out and support are scoped separately.

Before we start

A few practical questions.

Real screens and interactions, available at a URL your team can open. I include the states that matter to the journey, such as loading, empty, error and no permission, so you can test the experience beyond the happy path. It is built to work with a keyboard and a screen reader. Colour contrast is checked against WCAG 2.2 AA, so access problems show up while they are still cheap to fix.

I can put an NDA in place before you share anything. I normally use synthetic or anonymised data and a private, login-protected environment. If your team needs the work inside its own approved stack, we can plan around that.

Each week follows a visible loop: a new build, comments and review, then revisions. I prioritise changes against the agreed scope so the work stays focused on the decision you need to make.

You receive the working prototype and its source, component structure and tokens, plus a recorded walkthrough of the decisions, edge cases and the accessibility choices behind them. We agree any production engineering requirements separately.

That is useful evidence. The goal is to make a better decision before committing more engineering time. We’ll identify what failed, what could change and what is worth testing next.

Project showcase