BT Digital is becoming Antiphono.
We've spent over a decade building digital products that put people first. That work — and the relationships behind it — isn't changing. What's changing is the full scope of what we can offer, and why now is exactly the right moment to do it.
Two voices, in constant dialogue.
Antiphony is a musical term for call and response — two voices in dialogue, each one shaping and improving the other. It's the exact shape of the relationship between human intelligence and AI, and between every product and the people who use it.
That cycle — listening, responding, improving, repeating — is not a feature of what we do. It is the whole method.
The tools changed. The judgement didn't.
Design, research and development have all shifted fundamentally in the past two years. Ideas can be prototyped in hours, not weeks; tested with real users at a scale that was previously unaffordable; and refined continuously rather than in slow, expensive cycles. AI handles the repetitive and the generative — humans bring judgement, strategy and a real understanding of what people need.
What stays
Our traditional services — UX design, research, strategy and prototyping — remain at the core of everything we do. Clients who've worked with us continue to get the same rigour, the same craft, and the same commitment to outcomes over outputs.
What's new
We're not just working AI-first ourselves — we're bringing that same evolution to our clients: embedding AI-powered tools and thinking into your team's own processes, prototyping and testing at a pace that was previously out of reach, and building the kind of continuous intelligence loop that compounds in value over time.
The work we do for you improves. The way your team works improves alongside it.
Faster prototyping
Concepts go from idea to something testable in days, not weeks.
Testing at scale
Real behaviour from real users, continuously — not just periodic research rounds.
Team enablement
AI tools and workflows embedded into your own product processes.
Design governance
Consistency maintained across products and teams without proportional headcount.
Better value
Less budget on routine tasks. More on the decisions that actually shape the product.
The aim isn't to make you more dependent on an external partner. It's to make your team more capable.
"The work we have done together remains the foundation. We are not starting over — we are building forward with the full capability of what is now available."
The stages haven't changed. What moves between them has.
Design used to hand over drawings for somebody else to interpret and rebuild. Now the design stage produces working software — and that single change is what makes everything after it affordable.
Before
Static mocks and a spec to interpret. Every option redrawn and re-estimated, so teams tested one safe idea and hoped in production.
Now
Working prototypes made of production components. An option costs a prompt and a branch, so teams compare several and let real behaviour decide.
One process, end to end.
Most organisations run a design process and a development process that meet awkwardly in the middle. Antiphono runs one continuous pipeline, so you can see where your team, tools and governance slot in.
- 01 Design →
- 02 Development →
- 03 Testing →
- 04 Knowledge →
At a glance.
Brief or problem
Research
Prototype directions
Present, iterate, sign off
Branch, build, instrument
Pull request & review
Merge to dev → sandbox
Promote to staging
Merge to main → live
Internal walkthrough
Sandbox review
QA, a11y & user testing
Behaviour in real traffic
Written as the work happens
knowledge/ in the repo
Loaded by every session
Interrogated in plain language
Decide what to build. Make it real enough to judge.
A brief describes a problem. The team researches it, then builds clickable options from the company's real components.
Product features, marketing pages and simple assets each take an appropriate route — all arriving at the same sign-off.
A signed-off, interactive prototype — not a mock that still needs interpreting.
One source of truth.
Authored once by design, synced and checked by agents, versioned in its own repo, and inherited by every session that follows.
Figma design system
Components, tokens, type and brand language are authored in one place by the design system owner. This is the only file edited by hand.
Sync & API check
The sync agent converts Figma changes into code. The API check agent validates them against the codebase: naming, prop contracts, breaking changes, accessibility rules.
Live design system
A maintained, versioned component and token library sitting in your codebase. A live changelog shows every team what changed and when.
Every new session
Each project starts a session that loads the live system, so prototypes and production code are brand-consistent by default.
Inherited, not policed
Every session starts knowing the brand, so drift never gets a chance to start.
Nothing is redrawn
Components already exist in code, so a prototype is assembly rather than illustration.
Readable changelog
Every team can see what changed and when — nothing lands unannounced.
How it gets made.
Brief or problem statement
A problem to solve, not a solution to build.
Research the problem
Existing behaviour, prior findings. Hours rather than weeks — the judgement stays human.
Coded prototype
User-facing product work — working, clickable directions, usually several in parallel.
Claude design
Marketing pages and campaign assets that need real layout thinking.
Templated assets
Social, email and simple collateral produced at volume.
Direct in Figma
Complex or one-off visual design, and new design system components.
Present & iterate
The team walks the work itself. Review becomes a working session rather than a hand-back.
Sign off
One decision gate before engineering effort is committed.
Get it live without holding your breath.
Work starts in a folder on someone's machine and mirrors up to your shared repository.
It moves through reviewed environments: a private preview, an internal link, a rehearsal, then live.
Reviewed, versioned and reversible. Nothing promotes itself.
Local to live.
Open the project folder
A session per build project. CLAUDE.md supplies your environment URLs, naming and coding conventions.
Branch off dev
A new sub-folder for new work; a branch inside the existing folder for a variation.
Build & instrument
Assembled from live design system components, with tracking wired in as it is written.
Pull request
Claude writes the plain-language change summary; a second pair of eyes approves.
Merge to dev
The shared integration branch — deploys itself.
Promote to staging
Release candidate, checked in production-like conditions.
Merge to main
A separate, deliberate gate — the only route to live.
Local preview
Only you see it. Nothing shared, nothing at risk.
Sandbox URL
Shareable link for internal review, deployed on merge.
Staging / UAT
Per region where you operate — e.g. EU and US.
Production
Region deploys, parallel /v2 pages, admin-portal switching.
GitHub, Azure DevOps, GitLab or Bitbucket. Branch names and approval rules follow whatever your organisation already audits.
Azure Pipelines, GitHub Actions, Vercel or Netlify. Staging is optional for small changes, essential for structural ones.
An admin portal, CMS configuration or feature flags decides which version is served.
Review before dev, a separate gate before live, and versions never overwritten.
Identical on every machine, and in the repo.
A convention Claude keeps to every time, so a new feature is filed the same way whoever starts it — and the repo stays navigable for non-technical team members.
Claude creates these folders itself and keeps to the convention every time.
| Name | Pattern | Description |
|---|---|---|
| New feature branch | feature/<feature-name> | Branched from dev. Folder and branch names always match. |
| Variation of existing work | variation/<feature-name>-v2 | Ships as a parallel /v2 page. |
| Fix or refinement | fix/<short-description> | Small, single-purpose branches. |
| Release to live | release/<yyyy-mm-dd> | What was promoted to main, and when. |
| Knowledge record | yyyy-mm-dd-<slug>.md | Sorts chronologically next to its evidence. |
| Design system release | v<major.minor.patch> | Product repos consume a version. |
Folder and branch names are kebab-case, declared in CLAUDE.md.
CLAUDE.md as the contract
Environment URLs, naming conventions and guardrails live in the repo, picked up automatically by every session.
One session per related area
Keep closely related work in a single session to preserve context and reduce cost.
Measurement is part of the build
Tracking events are written and verified in the prototype, then carried through the build.
Design system released, not edited
Component changes flow Figma → agents → versioned release with a changelog.
Never overwrite, always version
New directions ship alongside the original on their own URL.
Interchangeable by design
Repo host, CI/CD, analytics and testing tools are all replaceable.
Check it four times. Only the last one involves customers.
Three internal stages decide what gets deployed and prove the release is safe.
Then a version goes live to real people, and the numbers settle the argument.
Because versions run side by side, testing live becomes a measurement, not a risk.
Three gates, then real people.
Three internal stages decide what deploys and prove the release is safe. Only stage four involves customers.
Pre-production — three internal stages to a releaseLocal preview
Internal walkthrough
Decide which direction is worth building at all, before any engineering effort is committed.
Team reactions, comprehension problems, and the reasons a direction was dropped.
Weak directions are cut here; the reasoning is written down so it is not re-argued later.
Dev / sandbox
Internal review
Confirm the built feature does what was signed off. Internal only — no external participants.
Review notes and change requests, plus a check that tracking events fire correctly.
Fixes are re-prompted in the same session and redeployed the same day.
Staging / UAT
Quality assurance
Prove the release is safe: nothing else broke, and it is formally accepted.
Regression, accessibility findings, device coverage, and stakeholder sign-off.
Blocking issues go back to development; a clean pass authorises the merge to main.
Production
Live testing with real users
Find out whether the change actually alters what people do, using customers with genuine intent.
Behavioural and conversion data per version: A/B comparisons, session replay, funnel drop-off.
Settles whether the version stays, is switched back, or becomes the new default.
Live testing only produces evidence if the measurement already exists. Tracking is implemented and verified back at the prototype stage and carried through the build — nothing is retro-fitted once the question has been asked.
| Outcome | What happens |
|---|---|
| It worked | The version becomes the default in the admin portal, and the pattern is promoted into the design system. |
| It didn't | The portal repoints to the previous version. No deploy, no incident, no lost work. |
| It's close | A refinement is re-prompted and ships as a further version alongside, so the comparison continues. |
| Either way | The outcome is appended to the decision that predicted it. |
Most teams cannot explain their own product a year later.
Research, the reasoning behind each decision and the result it produced are written down as they happen.
By the session doing the work, in the same submission as the change — not written up at the end.
A record you can ask questions of: why this way, what was the evidence, did it work?
Every stage feeds it.
What the design stage produces
Problem statements, research findings, options considered and why they were rejected, sign-off rationale.
What the build produces
Auto-written PR summaries, design system releases and changelogs, what shipped where and when.
What testing produces
Internal review notes, QA and accessibility results, live behavioural and conversion data.
Written as the work happens
The session doing the work writes the record while the reasoning is still intact.
knowledge/ in the project repo
Plain text, versioned with the feature it describes.
Loaded by every session
Every new session reads it on start-up, alongside the design system.
Interrogated in plain language
Why is it built this way? Answered with citations to the actual records.
The evidence base grows
A question asked in year two is answered from the record of year one, in minutes.
The design system hardens
Patterns proven in live testing become components everyone inherits.
The conventions sharpen
Rules learned the hard way are written once and applied automatically.
Nobody owns "documentation"
The record is a by-product of doing the work, not a task at the end.
Four things change.
Days to a testable build
No rebuild between approval and a real URL.
Options become cheap
A variation is a prompt and a branch.
Behaviour, not opinion
Every release can answer whether it worked.
Fast stops fighting careful
Speed no longer costs control.
A small, senior team.
Antiphono is built around a small, senior team. Each person brings a distinct specialism; clients draw on them as their project requires.
Senior Designer
Supports delivery across lower complexity design tasks and rollout work — adapting, implementing and maintaining design across products and platforms.
AI Tech Researcher
Specialises in applied AI tools, emerging technology, and integrating machine intelligence into design and product workflows.
Let's start your next project.
The best way to see this work is on one real feature. We set up the design system, the pipeline and the measurement, then run a single feature end to end with your team.
Design system audit; repo and pipeline set up to your governance.
One feature designed, prototyped, reviewed and deployed to your sandbox.
Live with measurement in place, and your team running the process.
Get in touch. Let's find out what we can make together.
Email hello@antiphono.studio