Mastercard · MDES Manager
Engagement: Senior contract, November 2025 to present Product: MDES Manager, Mastercard's self-service interface to the Mastercard Digital Enablement Service Users: Issuers, processors, payment service providers and internal Mastercard operations teams
MDES is the tokenisation layer behind Apple Pay, Google Pay and card-on-file digital wallets across the Mastercard network. MDES Manager is how customer institutions configure and operate it. My remit covers the platform's entire customer-facing content estate: the user guide, the product interface, and the delivery material that sits between them.
The Situation I Inherited
A 379-page user guide in DITA XML that had grown by accretion across years of product change. Interface copy written by whoever shipped the feature. A support queue absorbing questions the documentation should have answered, and a set of delivery guides that did not exist yet.
The platform was not the problem. The platform is mature. The problem was that the material describing it had been maintained page by page and never governed as a system.
Scope
- User guide overhaul. Full structural and editorial rework of the 379-page guide, consolidated to roughly 200 pages in DITA XML without cutting coverage. The reduction came from removing duplication, collapsing near-identical procedures into reusable topics, and killing sections that documented removed behaviour.
- Product UX content. Revision across more than 100 product screens, with 12 reusable content patterns established so future features land consistently instead of restarting the argument each time.
- Delivery guides. 14 customer-facing guides built from an analysis of 949 support tickets, structured for both human readers and retrieval by an LLM.
- AI assistant R&D. A proof of concept for a conversational assistant on the platform, benchmarked against Klarna's assistant, Bank of America's Erica and Morgan Stanley's internal knowledge base deployment.
Decisions That Shaped It
Consolidate rather than rewrite. A clean-sheet rewrite of 379 pages would have taken longer and lost accumulated accuracy. Restructuring against the DITA topic model preserved what was correct and exposed what was duplicated.
Let the support data set the priority. 949 tickets is a better guide to what customers cannot work out than any internal opinion, mine included. The delivery guides exist because the tickets said they were needed, in the order the tickets ranked them.
Write for retrieval as well as reading. Financial institutions are putting internal assistants over vendor documentation. Content chunked with self-contained topics and explicit headings works for both a human scanning it and a retrieval system indexing it, so I structured it that way from the start rather than retrofitting later.
Patterns before pages on the UX side. Fixing 100 screens one at a time produces 100 opinions. Twelve agreed patterns produce a system, and the next hundred screens cost far less.
Stakeholders
Product owners across MDES feature areas, engineering, UX design, accessibility, brand and legal review, and the support organisation whose ticket data drove the priorities. The constraints came from Mastercard's brand writing standards, W3C COGA accessibility guidance, and the DITA XML toolchain that produces the published output.
The real work. The writing is the visible part. The engagement runs on getting product owners across separate feature areas to agree on shared terminology, holding a structure while the product keeps shipping underneath it, and keeping review cycles moving without stalling releases.
Outcomes
- A 379-page guide reduced to roughly 200 pages, restructured in DITA XML and maintainable topic by topic
- 12 content patterns adopted across the product interface, applied to more than 100 screens
- 14 delivery guides covering the highest-volume support themes
- A benchmarked AI assistant concept assessed against comparable deployments in financial services
Why This Matters for Delivery Roles
This is a programme delivery engagement inside a payments platform, with content as the deliverable. Scope negotiated against a live product, priorities set from operational data, multiple stakeholder groups with competing terminology, a structured toolchain with real constraints, and a fixed publication pipeline. Substitute the artefact and the job is the same one I have been doing since the CTO roles.
→ Starknet for the blockchain infrastructure contract → Delivery Track Record for the leadership history → Contact to discuss a role