Martin Alcock

Product · Service design · Front end · Sheffield

I turn complex problems into useful products.

I bring people together to shape the direction, then stay hands-on to design and build it. Consultancy, startups, and a health site with 18 million users a month, since 2008.

Open to product, design and transformation roles. Sheffield, hybrid or remote.

Selected work

Five problems, and what they turned out to be

Each one starts with what I was asked for, then what the problem actually was. Open the reasoning for the detail.

HomeServe

HomeServe · Discovery, service design, front-end build · At Razor

Asked for
Fix inaccurate boiler surveys and poor quote conversion.
Actually
Customers were told which boiler they'd get, with no reasoning and no say. Surveyors carried the installation rules in their heads, and installers paid for every slip.

+50%

sales conversion, which I attribute to the choice screen I designed and built

HomeServe already knew surveys were going wrong and quotes weren't converting. I started with their senior people, then booked a boiler quote at my own home to see it from the customer's side. The answer was a guided survey that codified the install rules, and a final screen that let the customer choose.

  • Discovery
  • Service design
  • Front end
The reasoning
Client
HomeServe
Through
Razor
My role
Discovery lead, designer, front-end developer
Built
Progressive web app for quoting

Starting where they were

HomeServe came to us knowing two things. Surveys were often incomplete or wrong, and too many quotes didn't turn into sales. I spent the first stretch with their senior stakeholders, working out what they believed was happening and why.

Then I did the obvious thing nobody had done. I booked a boiler quote at my house.

What I saw at home

The surveyor spent most of the visit muttering at an iPad. Then he told me which boiler I'd be getting. I had no idea why, and no idea there was a choice.

That visit didn't discover the survey problem. HomeServe already knew about that. What it showed me was the customer's side of it: the reasoning was hidden, the options were hidden, and the person being asked to pay for a new boiler was the least informed person in the room.

It also explained the survey errors. The surveyor was working the installation rules from memory: the gas pipe route and its bends, where the flue can exit and what it has to clear. Miss one and an engineer turns up on install day to a job they can't finish, with an unhappy customer watching.

The quote visit

Before

  • Rules from memoryPipe routes and flue clearances, recalled on the spot
  • One boiler, prescribedThe reasoning stays on the iPad
  • Errors found on install dayEngineer can't complete the job

After

  • Guided surveyThe app asks every question the install needs
  • Rules applied as you goConstraints narrow the boilers that will fit
  • Customer choosesEvery boiler that suits the house, side by side

How to present the recommendation

  1. One boiler, better explained

    Least change for the sales team. Still asks the customer to trust a decision they can't see.

  2. The whole range

    Honest, but most of it wouldn't fit the house. Choice without the constraints is just noise.

  3. Chosen

    Every boiler that suits this house

    The survey has already done the filtering. The customer gets a real choice and the surveyor stops being the bottleneck.

Building it

I designed the app and built the front end myself, including that final choice screen. Being both designer and developer meant the survey's guardrails and the layout of the choice could change together, instead of being negotiated across a handover.

+50%

sales conversionReported uplift after launch, which I attribute to the choice screen. It wasn't a controlled test.

Permalink for this case

Fixie

Fixie · Discovery, solution direction · At Razor

Asked for
Automate the preparation of 3D models.
Actually
Nobody was waiting for a model. Customers were waiting for a price.

6h → 5m

time to quote, from around six hours to under five minutes

Fixie described their problem in technical terms and asked for a technical fix. Underneath it was a human problem: customers waiting most of a working day for a quote. Reframing the work around time to quote changed what we built.

  • Discovery
  • Service design
  • Product direction
The reasoning
Client
Fixie
Through
Razor
My role
Discovery and solution direction
Measure
Time to quote

A well-specified request

Fixie came to us with a clear ask: automate the preparation of 3D models. Preparing models was where the hours went, so automate that and everything speeds up. Perfectly reasonable, and a genuinely hard technical problem.

The trouble with a hard technical problem is that it's very easy to fall in love with it.

Working back from the ask

  1. Automate model prepThe request as it arrived
  2. Who's waiting?The customer, not the engineer
  3. Waiting for what?A price they can act on
  4. Redesign the quoting serviceTime to quote becomes the measure

The reframe

So we stopped treating model preparation as the problem and started treating time to quote as the problem. That moved the whole quoting service onto the table, not just the one step everyone was staring at, and we redesigned the service and platform around it.

6h → 5m

time to quoteFrom around six hours to under five minutes, as reported on the project.

Permalink for this case

Sheffield Forgemasters

Sheffield Forgemasters · Facilitator, discovery lead · At Razor

Asked for
Show us what a modern steelworks could look like.
Actually
Before anyone would fund looking properly, the leadership needed a shared picture of where they might go.

200+

people engaged, shop floor to C-suite, in a three-month discovery. The proposal that followed didn't go ahead.

I ran a future-vision workshop with senior management, then wrote and narrated a playful story-style video of one possible future. That secured a three-month discovery with a team of six and more than 200 people across the business, ending in a future-state vision for the board.

  • Facilitation
  • Discovery
  • Service design
  • Leadership
The reasoning
Client
Sheffield Forgemasters
Through
Razor
Team
Six
Discovery
Three months
People
200+

Selling the looking

Large, established organisations rarely fund a proper discovery on the strength of a slide deck. People need to be able to picture where they might end up before they'll agree to go and find out.

So I facilitated a future-vision workshop with senior management, then turned what came out of it into a short story-style video, which I wrote and narrated. It was deliberately a bit playful. A future you can picture is much easier to say yes to than a list of capabilities.

How the engagement grew

  1. Senior workshopA future-vision session with management
  2. Story videoWritten and narrated. One possible future in a few minutes
  3. Three-month discoveryTeam of six, 200+ people, shop floor to C-suite
  4. Board-level visionFuture services, applications and technologies

The video did its job. It secured the wider discovery.

Three months on site

The discovery was about the operating model: how work actually moves through a steelworks, and where software and data could help the people doing it. That meant as many conversations with steelworkers on the shop floor as with the board. We came out with a future-state vision of services, applications and technologies, presented at board level.

200+

people engagedFrom shop-floor staff to the C-suite, over three months.

Permalink for this case

Doxzoo

Greens Digital · Service and product designer · 2026

Asked for
Redesign the site for V3.
Actually
A lot of what looked like interface problems were problems with how the service worked. The leadership needed to tell the two apart before anyone drew a screen.

4 → 1

information architectures, assessed against production, pricing and delivery. One direction signed off by leadership.

Doxzoo is a profitable online print platform. Before redesigning anything I ran a full-day workshop with eight senior leaders, mapped the current journeys and separated service issues from design issues. Four IA propositions later, leadership signed off a direction, and I've been delivering the front end with AI-assisted development.

  • Facilitation
  • Service design
  • Product direction
  • Front end
The reasoning
Client
Greens Digital
Product
Doxzoo
My role
Service and product designer
Status
Launch expected late 2026

Evidence before opinions

I prepared with surveys, post-purchase data, funnel analysis and walkthroughs of the site, grouped into four journey themes. Then a full day in a room with about eight senior leaders: the CEO, operations, IT, finance and marketing.

The prep meant the day could be spent on decisions instead of on whose hunch was right.

What the day surfaced

Many of the problems on the list weren't design problems. They were how the service worked, showing up on the screen.

Mapping the current journeys made that visible. Some fixes belonged in the interface. Others belonged in the service model underneath it, and no amount of redesign would touch them. Helping the leadership see which was which was the most useful thing I did on the project.

Every proposition had to respect

  • Production
  • Pricing
  • Delivery

From evidence to a direction

  1. Four journey themesSurveys, purchase data, funnels, walkthroughs
  2. Current-state journeysMapped with the leadership team
  3. Service vs interfaceIssues sorted by where they really live
  4. Four IA propositionsCo-designed and compared
  5. One directionSigned off by leadership

Into delivery

The output wasn't a deck. It was reusable product-page specifications, components, acceptance criteria and competitor analysis, ready for development.

I was then retained to build the front end with AI-assisted development, using a DESIGN.md as guardrails so generated code stays on-system, and deploying on every commit to main. The process is deliberately lighter than it would be on a big team. It's sized to the project.

Permalink for this case

Tubr

Tubr · Fractional Chief Product Officer · 2026 to now

Asked for
Keep building the chat-first app over the forecasting models.
Actually
Hospitality operators don't have time to ask an app questions. They want to glance at what's coming and get back to service. And a forecast that says an event is worth £3 to you isn't information, it's noise.

Tubr uses machine learning to forecast trade for hospitality businesses. I lead product and a small data team, and I ship code. The two calls I'd defend hardest: moving the app from chat-first to a dashboard feed, and replacing precise event forecasts with a broader picture of the local scene.

  • Product direction
  • Data UX
  • Engineering
  • Leadership
The reasoning
Role
Fractional CPO
Team
Lead data scientist, ML engineer
Since
February 2026
Status
Working towards launch

Chat-first to glance-first

The app started as a chat interface. Ask it about your week and it would tell you. I spent a lot of time talking to people who work in hospitality, and the picture was consistent: a manager with one eye on the kitchen and one ear on the floor doesn't want to start a conversation with an app. They want to look at it and know.

So I made the call to rebuild it around a dashboard fed by insights. They arrive, you scan them. People can comment on forecasts and come back later to see what actually happened, so the feed becomes a record of the business rather than a stream that scrolls away.

How to show forecasts for local events

  1. Money per event

    What the model produces. But a predicted £3 contribution invites false confidence, and events rarely repeat exactly.

  2. Leave events out

    Safe, but it throws away a signal operators genuinely care about.

  3. Chosen

    The local scene

    Summarise what's happening nearby as busier or quieter. Closer to how operators already think about their patch.

Under the hood

I designed the data model for the insight feed. It's multi-tenant across companies and outlets, with visibility resolved by user, role, outlet and company. Each person's state lives apart from the generated content, so regenerating a forecast can't wipe out someone's comments.

Making a small team faster

When I arrived, deploying infrastructure meant running Terraform from someone's laptop. The newer parts of the stack now build from pull requests, each with its own preview environment that tears itself down after seven days if it isn't merged.

I've moved the team onto AI-native ways of working: agentic workflows for parallel development and bug fixing, Linear tickets raised from Slack, and PostHog usage stats asked for in plain English. Less context switching, more shipping.

Permalink for this case

Also

Shorter notes
  • 2011–2018

    Patient.info

    Front end and UX for a health site with 18m monthly users. Over several redesigns the community grew from 20% to 66% of traffic.

    • Front end
    • Product direction
  • 2016–2019

    Sheffield Children's Hospital

    An AR distraction therapy app for children during treatment. Winner at the Design Week 2020 awards.

    • Front end
  • c. 2024

    Viadex

    Solution Director on a single customer-facing view of ICT estates. Delivered in months, with requirements found along the way.

    • Leadership
    • Product direction
  • At Razor

    Platinum Stairlifts

    Discovery, and an AR tool for on-site teams to measure and survey staircases.

    • Discovery
    • Front end
  • 2025–2026

    Koala

    Brand, a design system in Figma and React, and the first product UI for an early-stage startup.

    • Product direction
    • Front end
  • 2023

    Razor website

    Rebuilt on Storyblok and Vue, generated at build time and republished on publish. The prototype for this site.

    • Engineering
  • 2023–2024

    ArchVR

    A solo rewrite of 3D View Pro: Nuxt, tRPC, Prisma, a BabylonJS editor, and a node graph that wires device data to 3D objects.

    • Engineering

How I work

Four moves I make on most projects

  1. Get close to the work

    I go where the problem happens: a living room during a boiler quote, a steelworks shop floor, a busy service. What you see there beats any opinion in the meetings that follow.

    See it in HomeServe →

  2. Reframe the ask

    Clients usually arrive with a solution. I work back to who is waiting, and what for, and check that's what we're solving.

    See it in Fixie →

  3. Decide in the open

    Options on the table, constraints named, trade-offs argued with the people who'll live with them. Then a direction everyone in the room can explain.

    See it in Doxzoo →

  4. Build it

    I design it and write the code, so the decision survives contact with reality. Small loops, AI-assisted, instrumented so we can see what happened.

    See it in Tubr →

Record

Work history, without the PDF

What each job was, what it was really about, and where to find the work.

  1. 2026Now

    Tubr

    Fractional Chief Product Officer Fractional

    Leading product for a machine-learning forecasting startup in hospitality, and writing a fair amount of the code.

    • Rebuilt and replatformed the customer experience in six weeks, then redid the brand and a mobile-first app.

    • Lead a data scientist and an ML engineer: priorities, technical review, coaching.

    • Built partner APIs and embeddable widgets, and pitched Tubr at Britain's Got Startups three weeks in.

    TypeScript, React, Python, Terraform, PostHog, Claude Code

  2. 2026Now

    Doxzoo (Greens Digital)

    Service and Product Designer Freelance

    Discovery and service design for a profitable print platform's V3, then building the front end.

    Workshops, journey mapping, AI-assisted front-end delivery

  3. 20252026

    Koala

    Principal Product Designer Freelance

    Brand, design system and the first product for an early-stage startup, from discovery with the founders to shipped UI.

    • Identity, logo, visual language and a component system in Figma and React, set up for consistent AI-assisted development.

    • Built the public website and the initial product UI myself.

    Figma, React, shadcn/ui, Tailwind

  4. 20192025

    Razor

    Principal Consultant, then Solution Director

    Six years of discovery, service design and delivery for established businesses, and building the design team.

    • Founding member of the strategy consultancy function. Scoped, estimated, pitched and won work with C-suite clients.

    • Grew the design team from one to four, with hiring, one-to-ones, mentoring and performance management.

    • Led cross-functional teams of up to eight. As Solution Director at Viadex, owned product decisions and client liaison on a customer-facing view of ICT estates.

    • Rebuilt Razor's own site on Storyblok and Vue in 2023, the ancestor of this one.

    Figma, Vue, Storyblok, workshops, estimates and proposals

  5. 20182019

    Obitus

    Senior UX and Front-End Lead

    Modernising web applications for the bereavement sector: the UX, the front-end architecture and the workshops to agree both.

    Vue, Nuxt, AWS Lambda

  6. 20162019

    Freelance, and 3D View Pro

    Consultant and founder Founder

    VR, AR and UX work alongside the day job, including founding a SaaS for VR architectural visualisation.

    • 3D View Pro: turned architectural models into VR walkthroughs with automated cloud conversion.

    • Sheffield Children's Hospital: an AR distraction therapy app for children during treatment. Winner at the Design Week 2020 awards.

    • The Big Word: discovery, UX and UI.

    VR, AR, automated cloud conversion

  7. 20112018

    Patient.info

    Lead Front-End Developer, UX and Product Strategy

    Front end and UX for a health information site with 18 million unique users a month.

    • Built up the community through several redesigns. Its share of total traffic grew from 20% to 66%, and pages per visit went up with it.

    • Helped shape and launch Patient Access for NHS appointment booking, working with EMIS.

    • Ran research and workshops with patients and clinicians. Managed a small team.

    Orchard CMS, front-end development, research with patients and clinicians

  8. 20082011

    10th Planet

    Creative Web Developer

    Where I learned to take an idea from concept to a working build: interactive work for commercial clients, PHP and heavily customised WordPress.

    PHP, WordPress

Writing

For peers, mostly

Nothing published yet. The first pieces are on their way.

All writing →

Lab

Small experiments

  1. OKLCH colour ramps

    A palette generator that builds the full 50 to 950 ramp from a single colour. It works in OKLCH, so lightness steps look even whatever the hue.

Everything in the lab →

Got a knotty one?

I'm looking for my next role in product, design or transformation: permanent, contract or fractional. Tell me what's stuck.