Issue Two · Service index

Six chapters that become one working system

Xds Experience Design Systems Inc. offers a fixed set of experience design system services. Each chapter below is a complete engagement with its own method and its own artefacts, and each one can be commissioned alone or run as part of a longer programme.

Usability Audit Sprints

Find what breaks the task before you redesign it

A usability audit sprint is a short, evidence-heavy review of the tasks that matter most. We begin with a task inventory drawn from analytics, support records and interviews with the people who answer customer questions. From that inventory we select a representative set of journeys and walk each one on a controlled device set, capturing hesitation points, mislabels, dead ends and recovery behaviour.

The sprint lasts two to three weeks. Week one is evidence gathering; week two is analysis and severity sorting; the final days are spent writing the report and presenting it to the team that will act on it. Every issue is written in plain language with a reproduction step, a screenshot, a severity note and a suggested remedy that respects the existing component library. The report is sorted by task impact rather than by screen count, so the first page always answers the question of where to spend the next sprint of engineering time.

Deliverables include the issue log, a prioritised fix chart, a recording archive and a short executive note. We also include a review session three weeks after delivery so that the team can ask questions once the report has been read properly.

Figure 01. Usability audit sprints are commissioned most often when a product has grown new features faster than its navigation model.

Design Token Libraries

A shared vocabulary for colour, type, space and motion

A design token library is the smallest reliable unit of consistency across a product family. We inventory every value currently in use, group duplicates, and propose a semantic naming scheme that reflects intent rather than appearance. A colour called surface-raised is easier to govern than a colour called light blue two, because the first name survives a brand refresh and the second does not.

We build the library in three layers: primitive values, semantic aliases and component-level references. The primitive layer holds raw scale values. The semantic layer maps those values to meaning. The component layer is where engineering consumes them. This structure keeps a change contained. A decision about the warning colour is made once, recorded in the change log and inherited everywhere the semantic alias is used.

Deliverables include a versioned token package in the format your build already accepts, a naming rulebook, a migration guide for existing stylesheets and a short training session for designers and engineers. Deprecations are announced in the change log and supported for two release cycles so that no team is forced to migrate on the same afternoon.

Service Blueprint Workshops

Draw the promise beside the machinery that keeps it

A service blueprint workshop brings the customer view and the operational view onto a single sheet. Over two days we map the front stage, the backstage steps, the supporting systems and the moments where a handover between teams can fail. Participants typically include product, support, operations and one senior sponsor with authority to name owners.

We work on paper first. Lanes are ruled, notes are placed, and disagreements are made visible while they are still cheap to resolve. After the workshop we transcribe the blueprint into a digital document with an owner for every lane, a register of open questions and a decision log. The document becomes the shared reference for planning, hiring and support staffing.

A thirty-day review closes the engagement. We revisit the blueprint with the same group, mark which gaps have been closed, which are accepted as deliberate constraints and which need a second workshop. Most organisations leave the room with three or four concrete operational changes that can be made without a budget cycle.

Systems work is judged months later, by the team that inherits it. We write every artefact with that team in mind, and we leave the reasoning beside the result so the next decision does not have to start from silence.

A blueprint is only honest if it shows the queue, not just the promise.

Workshop working note

Accessibility Reviews

Test with assistive technology, then write for the people who fix it

Our accessibility review combines automated scanning with manual keyboard and screen reader passes. Automated tools catch a useful minority of problems quickly; the manual passes catch the ones that actually stop a person from completing a task. We record the exact sequence of keys and the spoken output so that a developer can reproduce the issue without guesswork.

Findings are grouped by component rather than by page. When a button pattern fails in one place it almost certainly fails in twenty, and a component-level report turns twenty tickets into one fix. Each finding states the current behaviour, the expected behaviour, the relevant success criterion and a suggested remedy that fits the existing library.

Deliverables include the findings register, a contrast table with measured ratios, a keyboard path map for the primary journeys and a revision window in which we re-test the fixes at no additional cost. We also provide a short briefing for the team so that the same issues are less likely to return in the next feature.

Figure 02. Contrast is recorded numerically for every text and background pair, never estimated by eye on a designer display.

Journey Map Sessions

Reconstruct the whole story, then choose the next experiment

A journey map session gathers the people who know the customer best and asks them to rebuild the experience from first awareness to settled use. We collect quotes, screenshots, timings and emotional notes, and place them on one large sheet so the whole group sees the same narrative. The map is a working argument about where friction lives, not a poster for the lobby.

Each session runs for half a day and produces a map, a list of moments of truth and a short set of experiments for the coming quarter. We identify the stage where customers ask for help, the stage where they quietly leave, and the stage where the organisation believes it is performing well but the evidence says otherwise.

Deliverables include the large-format map, a digital version that can absorb new research, a moments-of-truth register and a trained internal owner who can update the map without us. The service pairs naturally with a service blueprint workshop, because the customer view and the operational view are stronger when drawn together.

Design System Handovers

Leave the system in a state the next team can extend

A handover is the moment a design system becomes part of daily work rather than a studio project. We prepare a documentation set that covers every component decision, a contribution model that explains how new components are proposed and reviewed, and an office hours schedule for the first adoption cycle. Nothing is left implicit.

The handover includes a governance note, a versioning policy, a review checklist and a recorded walkthrough. We train one nominated owner on each side, design and engineering, so that the system has two people who can answer questions after the studio steps back. Six months later a new joiner should be able to add a screen without guessing at conventions.

We stay available for the first adoption cycle and then withdraw by design. A system that only works while the consultancy is in the room is not yet a system. The handover is the chapter that proves the rest of the work has landed.

The process, written as a sequence

Five movements across a quarter

Step 01

Scope and evidence plan

We meet once, agree the questions that need answering and write a short scope. The scope names the chapters, the evidence we will gather and the artefacts we will deliver. No design time is spent before this document is signed by both sides.

Step 02

Gather and observe

Audit sessions, journey mapping or blueprint workshops run here, depending on the chapters commissioned. Evidence is logged as it is found, in a shared register that the client can read at any time.

Step 03

Define the system

Tokens, component states and naming conventions are proposed and reviewed against the evidence. Open questions are recorded rather than hidden, and each decision receives a short written rationale.

Step 04

Build and test

Components are built in the client environment where possible, then reviewed with the accessibility checklist. Findings are folded back before the documentation is written, so the handover describes what exists rather than what was intended.

Step 05

Hand over and support

Documentation, training and a recorded walkthrough go to the named owners. We remain available for the first adoption cycle, with a short review at thirty days and a closing note at ninety days.

Bringing more than one chapter into a programme

Programme note

Many clients begin with one chapter and extend into a programme once the first artefacts are in use. The most common pairing is a usability audit sprint followed by a design token library, because the audit identifies the fixes and the tokens provide the vocabulary for making them consistently. Accessibility review usually follows the first build, and the handover closes the run.

A programme is scoped in quarters. Each quarter has a stated objective, a list of chapters, a set of artefacts and a named internal owner. We report against the objective at the end of each quarter, and we are willing to say when a chapter is no longer needed. That honesty is part of the service.

Questions about scope, schedule or fit can be sent to support@xdsexperience.hair or raised by phone at +14068737219. The studio is at 163 3rd St A W, Owen Sound - N4K 3J6, Canada (CA).

Tell us which chapter your team is stuck on. We will reply with a scope, not a slide deck.

Start the conversation →