myPub
Wetherspoon checks every pub through audits and calls. As Lead Product Designer I designed myPub, the phone app and web console that replace the third-party system those audits ran on.
The situation
Seven roles, one audit, and nobody could change a question
Audits ran in MarketForce, a third-party app. Head office couldn't change a single question in it, and everything around it was done by hand.
The brief was one line: a front-end app and back-end web tools to manage Wetherspoon's audits in-house.
Audit in MarketForce
Callers answer questions set inside a third-party app.
Results stay in the vendor system
Reporting is limited to what MarketForce offers.
Finance pulls scores with SQL
Score, visit and bonus reports are built by hand.
Quotas tracked in a spreadsheet
Reporting checks guest calls one by one.
Pub manager prints the report
Results are kept in paper folders for the next visit.
Discovery
Sessions with five parts of the business
I ran sessions with Audit, Property Maintenance, Reporting, Finance and the Area Managers. These are the things they said that changed the design.
Only failures matter. The question is which pubs have failing fire doors, not which areas passed.
Reporting built around failures, with a filter for any question that scores under its threshold.
A full audit takes about three hours, and the signal drops in cellars and kitchens.
An app that works offline, saves every answer as it is given and confirms when head office has the call.
Changing a single question means waiting on the vendor's roadmap.
A questionnaire builder head office runs itself, with versions and an approval step.
I want to go through the report with the caller, photos included, before it is sent.
A review step where the caller and pub manager check every answer and photo before submitting.
Pub bonuses are paid from these scores, and they go into the bonus system by hand.
CSV export in the first release, so the bonus process kept running until it could be automated.
Personas
Seven roles, very different jobs
The proposal named six user groups. The persona work found seven, because Finance and Reporting want different things from the same data.
The pub manager is the only one being audited. The names are made up.
Owns the questionnaires, the permission levels and every report amendment.
Looks after 6 to 15 pubs and runs a Blue Bag visit at each one every week.
Covers 17 pubs. A full compliance audit takes her about three hours.
One of 12 managers with around 70 pubs each. Only interested in what failed.
Builds score and pub bonus reports by hand, with SQL.
Tracks every caller's quota in one large spreadsheet.
Is audited rather than auditing. Wants his results without using the app.
Scope
Cutting it down to launch
The first proposal covered everything. In 2025 we cut it to what replaces MarketForce for internal callers, so the project could start sooner.
- Role-based questionnaires
- Works offline
- Several photos per question
- Review with the pub manager before submitting
- Previous reports before a repeat visit
- Food specs beside food questions
- Questionnaire builder with scores and weights
- Question reuse across groups
- Who receives which report
- Reports filtered by venue, caller, date and failure
- CSV export
- Compliance calendar
- Call quotas and automated matrices
- Mystery shopper import and export
- Role-based dashboards
- Personal home screen with quotas
- Scores straight into the pub bonus system
- Pub manager's own view
- Franchise use in the UK and abroad
- Automation and AI on top of the data
Flows
Four flows, each tied to a person
Each one follows a persona through one task. All four ran as working prototypes in Claude, and were tested against the personas, before any Figma.
Runs a food safety audit
- Picks the nearest pub from the list
- Confirms the questionnaire and her arrival time
- Answers by category, adding photos and checking each dish against its spec
- Goes through every answer with the pub manager
- Submits, and the score locks
Changes a question
- Opens the live questionnaire
- Starts a new version based on it
- Pulls a question from the bank and sets its weight
- Adds a follow-up that only appears on a No
- Previews it, then sends it for approval
Finds every failing fire door
- Opens reports in the web console
- Filters by the fire door question and failures only
- Gets the list of pubs that failed
- Opens the last report for each one
- Exports the list as a CSV
Fixes a mistake after submitting
- Spots an error on a submitted call
- Requests an edit from the result screen
- Head office reviews the request
- The change is approved and logged
- The original score stays on record
How I worked
Research in Gemini, prototypes in Claude, Figma last
Research starts in Gemini, with deep research and then voice calls where it plays an auditor or a pub manager. I do this before stakeholder sessions to sharpen my questions, and after them to test features against what people said.
Then every flow runs as a working prototype in Claude, from offline sync to the questionnaire builder.
Figma comes last, built from the design system once the flow works.
Screens from the Claude prototype, built to the myPub design system.
Design system
One design system for both products
The app and the console share one set of tokens and components. One chip component carries every status in both.
Written guidelines for AI tools keep the Claude prototype on the same rules as Figma.
Every status in both products goes through one chip component. A dashed border always means provisional.
Decision 01
Head office writes its own questions, within limits
Head office wanted full control. Too much freedom gives you questionnaires that contradict themselves, or nest so deep a caller gets lost.
Questions live in one shared bank, with weights set per questionnaire. Follow-ups stop at three levels. Every questionnaire goes from Draft to Approval to Active, with a preview first.
Decision 02
A submitted score never changes
Finance wanted scores to recalculate when thresholds changed, because bonuses are paid from them. I argued that a pub that failed in March failed in March. That argument went my way.
Scores lock on submit. Edits go through head office, with a record of who changed what.
Decision 03
Built for a cellar with no signal
An audit can take three hours, often with no signal. The app works offline, saves every answer as it's given and shows when head office has the call.
Before submitting, the caller goes through every answer and photo with the pub manager.
Timeline
Discovery to pilot in about two years
Sessions I ran with Audit, Property Maintenance, Reporting, Finance and Area Managers.
Personas, scope and the first concepts for the app and console.
Scope cut back so the project could launch sooner.
Roles, planning and the phased delivery agreed with Wetherspoon.
First release and phase 2 split confirmed.
Every flow prototyped in Claude, then built in Figma from the design system.
Callers running real audits ahead of the full rollout.
Learnings
What I'd do differently
Bring the pub manager in sooner. Their own view moved to a later phase, so the one role being audited was the one that waited. Next time I'd have a pub manager in discovery and testing from the start.
Put the smallest version in the first proposal. The project only started once we cut it down.
Measure before the pilot: how long an audit takes today, and how long a question change waits.
Use AI role-play to sharpen the questions. The personas still come from real people.
Where it is now
In pilot, ahead of the rollout
Callers are running real audits on it before it replaces MarketForce across the estate. Head office can now write, preview and publish a new question the same day.
