Geri Reid

AI is accidentally making documentation more accessible

Sun, 15 Feb 2026 00:00:00 GMT

AI is accidentally making documentation more accessible

I was joking with a colleague that the most highly prized skill of a product designer might soon be writing a well-structured Markdown file. If you work in a large product org, you're watching agentic AI creep into every aspect of the product design process. Short of throwing my computer into the sea and taking up subsistence farming in the Outer Hebrides, there's not much I can do to avoid it.

So I'm trying to find positives.

We've been testing how machine-readable our design system documentation is. Turns out, AI agents and humans benefit from exactly the same qualities: structure, consistency, plain language, explicit boundaries, no ambiguity.

In accessibility, we already optimise for readers who might struggle to infer missing information. People with cognitive disabilities, autistic people, people with dyslexia, and people reading in a second language. Everyone benefits when headings describe content, definitions come before explanations, and rules are clear. AI retrieval systems need the same things.

Huh.

A shared format for humans and machines

Big tech orgs are busy building spec-driven development workflows, agent skills, RAG pipelines, and MCP servers. All of it depends on documentation in a format that machines can parse reliably.

Markdown.

I'm conflicted about AI, but I freakin' love Markdown ❤️. It's just text. No proprietary overhead. No software dependency. Works with Git. Survives tool churn. And if the underlying instructions are in a format both humans and machines can read, you're not locked into whatever flashy AI tool launches next week.

Like all the good stuff on the internet, Markdown was created by an engineer to solve a practical problem and shared freely. It became ubiquitous through community adoption rather than formal standardisation or corporate backing.

Anil Dash just wrote an excellent piece on Markdown's origin story and how AI seems to be giving the format its renaissance moment.

In this dumpster-fire of an industry that feels increasingly chaotic, there's something a bit comforting about clinging to this small pocket of vendor-neutral stability whilst we melt the ice caps to give users shinier buttons.

Documentation is written to be retrieved, not read

When we write documentation, we often assume someone will read it top to bottom. Even when we skim, we start at the top, absorb context, build a mental model. And we infer stuff, like if you're reading design system docs, you probably already know what a design system is.

AI agents don't work like this. They retrieve the most relevant chunk based on semantic similarity and produce a response from that slice. If the definition is three paragraphs in and the agent retrieves paragraph one, it fills in the gaps.

That's where hallucination creeps in. You're absolutely right! Not because the model is careless, but because much of our documentation is structured for narrative flow, not retrieval. It was always fragile, humans were just good at compensating.

Writing for AI agents accidentally makes documentation more accessible. A screen reader user navigating by headings needs the same explicitness an AI agent needs. A new team member needs definitions that don't assume prior knowledge. A developer working in a second language needs sentences that say exactly what they mean. Explicitness helps anyone who can't rely on context to fill gaps.

Look at well-documented APIs. The ones that specify exactly what parameters do, what they return, what breaks. They're used more, trusted more, cause fewer support tickets. Explicitness scales.

Start with a structure

Consistent structure gives AI systems predictable anchors for retrieval. It gives humans faster scan paths and clearer mental models. It helps when:

each page is structured consistently
headings describe content
sections are self-contained
content makes sense in any order

That structure probably exists already in your design system documentation - you just need to make sure it's consistent.

Reduce ambiguity

Aim for declarative over descriptive writing. It helps when you:

lead with definitions and the most critical information
use RFC keywords MUST and SHOULD deliberately
avoid hedging language (might, could, tends to)
avoid metaphors
never assume prior knowledge

To some human readers, this sort of writing can feel a little abrupt. Less friendly. But for readers who need certainty, it's a relief. For AI, it's essential.

AI didn’t change the rules, it exposed them

Predictable structure, clear definitions, plain language? Your accessibility team has been asking for this for years.

The way we access documentation is changing, but the qualities that make it good are not. AI has not invented new rules for writing, it has made the cost of ignoring the old ones obvious.

As organisations go all-in on AI, I'm quietly hoping the need for machine-readable docs improves the experience for human readers along the way. If the robots are coming for our jobs, the least they can do is leave us with documentation that doesn't suck.

If you have opinions, hit me on Bluesky

Can AI write accessibility specs?

Sun, 16 Nov 2025 00:00:00 GMT

Can AI write accessibility specs?

TLDR: I built a little RAG AI prompt that pulls together accessibility best practices for whatever component I'm advising teams on.

Then I had an existential crisis about using AI.

☞ Generate accessibility guidance

Test it out and let me know if it's helpful, or if you just... hate me.

Here's my job:

Slack pings: "Hey, quick question about accessibility for this modal..."

Figma comment: "What's the keyboard interaction for this accordion?"

Zoom call: "ARIA labels for this carousel?"

There's usually some docs or a WCAG criterion that springs to mind, or if it's complex, I'll disappear down a research rabbit hole.

Last month, my brain went wandering into a dangerous place: what if I just... let AI do this? 🙈

The process I go through to advise on a technical spec for a component build or implementation is pretty similar each time. I look at:

Semantic structure
ARIA
WCAG / technical guidance
Keyboard and focus order
Platform specific guidance for apps

From here, I might write a checklist or set of acceptance criteria then jump on a call to share with a designer or engineer. I thought I'd have a pop at wanging all this into a prompt to see what happened.

1: Set up an API request

This was surprisingly straightforward, given I'm a designer and I'm not super technical. I wrote a JS function that calls the OpenAI API with my prompt. Netlify runs the function and stores the API key in environment variables.

To appease my conscience, I went with the GPT-4o-mini model - which supposedly means lower electricity consumption and a smaller carbon footprint. At least that's what the guidance says. I mean, why would Sam Altman lie to us?

2: Write a prompt that doesn't suck

My initial prompts produced unreliable results. Eventually, I got ChatGPT to help me improve my prompt, thus demonstrating how the web is SLOWLY EATING ITSELF.

Before I specified what a component was, the AI just made stupid shit up, hallucinating components based on their titles. Here are some of my favourite fabrications:

My favourite hallucinated components

The danger here is that everything is formatted neatly so it looks authoritative even if it's a load of old NumberWang.

I also discovered you can set the model’s temperature to low. The model’s temperature controls how random its word choices are. Setting it to zero makes the output more precise and it's less likely to invent details. It doesn’t stop hallucinations entirely, but it makes the model far less prone to creative or speculative answers.

3: Improve with RAG

After poking the prompt for a bit, the results were mostly correct but the advice was pretty generic. Like WCAG criteria that could apply to anything, and links to general guidelines instead of specific component docs.

Enter Retrieval Augmented Generation (RAG). Instead of letting a model make educated guesses based on the murky depths of the internets, you give it verified information to base a response on.

I altered my script like this:

Retrieve: My Netlify function looks up the component in a directory of local JSON files containing links to WCAG, ARIA Authoring Practices, MDN docs, Apple's HIG, Material, and design systems sites which I know offer sound advice. Basically, the same sources I'd check myself. I found these performed best with no more than 4-5 links per component. Any more, and it timed out or results got confused.
Augment: The function builds a prompt that includes these verified sources, so the model knows exactly what it can reference.
Generate: OpenAI API generates the guidance with a low temperature setting for factual accuracy.

Where I landed

This is useful for quick reference. But is the juice worth the squeeze?

Even with RAG and OpenAI API's temperature at the lowest setting, it still hallucinates. Hallucinations are paired with the overconfidence of a crypto influencer explaining NFTs to your Nan.

Some of the code it prints in the semantic HTML section is startlingly wrong. But given the material LLMs are fed with is flawed, can we ever rely on them to be 100% correct? The WebAIM Million still shows that 94% of the internet's top million homepages have WCAG fails, so I feel like we're asking the impossible.

If I can't guarantee it won't hallucinate, then what's the point? I might as well just have these sources bookmarked because I have to visit them to verify accuracy anyway. When someone's ability to access critical information hinges on detail in the technical build, there's no substitute for thoughtful human oversight.

Cue my existential AI crisis

Here's the sticker: I actually enjoy researching and writing component accessibility guidance. That's how I learn stuff.

Beyond accuracy, I'm grappling with how to use AI responsibly as an accessibility practitioner. The ethical and environmental costs are serious. Powerful AI systems rest on the invisible work of underpaid labour. Then there's the underlying sense of dread that when the AI bubble bursts, lots of my friends will probably lose their jobs.

Mostly, it feels dirty feeding expert-authored content into OpenAI's training machine, even if it's publicly available. Like I'm doing a disservice to the incredible people who created it. I added a sources section to the end of the prompt for transparency on where advice came from. And I didn't reference any personal blogs or sites because it felt wrong without permission.

While writing this, I watched Mike Monteiro's talk How to draw an orange. It's probably the best thing I've watched on the ethics of AI. Mike points out that Google's giant 'help me write' button is not really helping you to write. It's telling you that you're too dumb to write yourself and that your writing isn't good enough. AI can draw you a perfect orange, but you've learned nothing. That slaps hard.

I have huge respect for anyone who swerves the AI hype wagon entirely. My brain swings from quietly excited to guilt-spiraling. My inner Geri, the one who rescues spiders from baths and feels bad for unused emojis, is horrified that I'm publicly admitting to even this level of moral compromise.

If you have opinions, hit me on Bluesky

Add an Accessibility Nutrition Label

Wed, 01 Oct 2025 00:00:00 GMT

Add an Accessibility Nutrition Label

Apple has dropped Accessibility Nutrition labels on the App Store, offering users transparency about which accessibility features apps support. I completed an audit for one of these labels. Here's what I learned.

Accessibility nutrition? Wut?

It's exactly what it sounds like, minus the calories. A label that shows up on your app's product page telling people which accessibility features it supports.

If someone needs VoiceOver to navigate, Larger Text to read, or prefers Dark Mode, they will be able to determine if your app works for them before downloading.

The labels start as voluntary, but will eventually become mandatory for new apps and updates. Translation: get ahead of this.

How the label appears on the App Store, showing supported accessibility features:

This is a helpful initiative that should push teams to consider the needs of their disabled and older users. My only gripe? They called it a Nutrition Label. Google "Apple Nutrition Label" and you'll get a wall of apple nutrition facts. Plain language matters. I also think it would be helpful to show users the features an app doesn't support.

How to audit your app

1. Watch Apple's explainer video

This video steps you through the audit process using a made-up app. The whole process is self-assessed and relies on the auditor to be honest about results.

The key takeaway: you can't claim support unless you fully support a feature. Like, if only part of your app responds to Larger Text settings, you can't claim to support Larger Text. I sincerely hope companies don't overstate their support, because the point of these labels is helping users with access needs.

Don't be that company.

2. Map out your core user journeys

Step into your user's shoes. What are the main tasks they undertake on your app? Identify these core user journeys. For the e-commerce app I audited, I focused on these critical flows:

Launch experience
Account creation/login
Browse the catalogue
Search
Add items to the cart
Checkout
Post-purchase confirmation and help

3. Break each journey into steps

Take checkout for example. To check out an order in your app, users might need to:

Navigate the checkout interface
Add/edit personal details
Add/edit delivery addresses
Add/edit order notes
Select delivery options
Apply discount codes
Choose payment method
Review order summary
Complete payment

4. Test each step with accessibility features enabled

Apple's developer docs outlines a list of accessibility features you need to test your journeys against. Check the evaluation criteria to establish if you pass. The audit needs to be done by someone with experience of accessibility testing who is familiar with assistive settings and most importantly with user needs.

Here are the accessibility features you need to test. You can enable these on your device in Settings > Accessibility:

You also need to check for:

I struggled to find the right tool to record this exercise. Apple's docs suggest you create a matrix. I started in a spreadsheet, but I wanted to paste in screen shots and videos to flag issues as I progressed. I ended up setting up a table in a Miro board that allowed a selection of pass, fail, pass with issues and N/A like this:

This allowed me to check off criteria as I tested and paste in screens that had areas for improvement.

What this process taught me

If you haven’t done an end-to-end accessibility assessment of your app, this provides an excellent opportunity. Components and features are regularly developed in isolation and this systematic approach exposes gaps.

I regularly test with VoiceOver, but I'd never put Voice Control through a complete user journey. This assessment uncovered a couple of Voice Control bugs you would never notice in isolation. From an empathy perspective, there were a few areas that worked functionally and weren't technical fails, but could be improved. The app I assessed doesn’t feature video or audio so I omitted these assessments.

Adding the label to the App Store

This part is straightforward. Log into your developer account, find the accessibility section, check off what you support, and add a link to your accessibility statement. There is a guide that steps you through the process of adding a label.

Don't have an accessibility statement? Write one. They are now required by law in some European markets. Read my guide on how to write an accessibility statement if you need a template.

Tips for your own audit

Test on real devices, not simulators. The experience is noticeably different, especially for VoiceOver and Voice Control.
Don't rush it. Give yourself proper time to experience each journey as a user would.
Document everything visually. Screenshots and screen recordings were invaluable when explaining issues to the team later and writing tickets.
Test edge cases too. What happens when someone uses Larger Text AND VoiceOver together? Does your dark mode have sufficient contrast?

This audit process goes beyond adding a label to your App Store page: it's a comprehensive review that could uncover accessibility issues that you weren't aware of. You'll likely discover features that work in isolation but break down during real user journeys. These insights don't just help you check compliance boxes. They guide you toward building experiences that genuinely work for everyone, making your app better for all users in the process.

Have thoughts? Wave at me on BlueSky 👋

Turns out I'm not ready to write a book

Mon, 01 Sep 2025 00:00:00 GMT

Turns out I'm not ready to write a book

TLDR: I'm starting a monthly blog about accessibility.

If you'd like to read my writing, you can quietly subscribe to my RSS feed.

Why the sudden writing habit?

I got offered a book deal. Don't congratulate me yet.

Since I was a kid, books have always been my escape. When Covid hit and suddenly everyone was stuck inside, I wasn't fazed. If I have a book, I can learn stuff and travel to other realms.

A publisher showed interest in my proposal for a book about accessibility. I'd been wanting to write a book for years and I was beyond excited.

I reached out to some people in my network for advice. Caroline Jarrett generously offered me some time to improve my book outline. If you haven't met Caroline, she's very wise and straight-talking. I had long admired the structure of her book Surveys that Work and was aspiring to produce something as considered.

She stopped me as I began to launch into my book pitch.

"So, why do you want to write a book?"

Long awkward pause. I mumbled something about enjoying writing.

"What have you written recently?"

Shit.

I write every day for work, but it's not exactly writing. It's guidance and technical specs and documentation, mostly delivered via bullet-points.

I realised I was in love with the idea of writing a book, but I wasn't in the habit of writing. This was a problem. Could I really go from not writing to bashing out 1000 words, 5 days a week? A book contract comes with deadlines. Was this like me volunteering to cook Christmas dinner when I struggle to accurately pour hot water on instant noodles? Perhaps I should start a little smaller.

Why systems beat goals

Habits take repetition to build. James Clear wrote a whole book about this called Atomic Habits. His main point: building systems beats having goals every time.

"You do not rise to the level of your goals. You fall to the level of your systems."

I'm a systems nerd. I understand the importance of solid foundations. My lofty aspirations of writing a book suddenly seemed ridiculous without the systems in place to support it.

I know first-hand how habits take time. Despite being possibly the world's least athletic person I've somehow managed to run three times a week for the past 18 years. When I started, I was so out of shape that it took 3 months before I could even make it to the local park. The idea I could one day run a marathon was unfathomable. Yet I was expecting myself to perform the literary equivalent. Sometimes I can be really dumb.

At the end of our call Caroline suggested:

"Why don't you start a blog and spend a year getting into a regular habit of writing?"

It's annoying when someone cleverer than you points out something really obvious.

The following week the book contract arrived and I disappeared into a vortex of overthinking and annoying anyone unlucky enough to hang out with me. I got some legal advice which scared me. I started to question my motivations. Why was I doing this? Ultimately, I wanted to write a book because I enjoy writing. But I'm not in a position to take a year out, so writing a book would be alongside my day job. Would hauling my arse out of bed at 5:30am this winter be enjoyable?

After my freak out, I sent a wholehearted thank you to the publisher and declined the offer. I'll probably regret this decision for the rest of my life. It's still the thought waking me up at 3am like some angsty protagonist in a Netflix teen drama. But sometimes you have to listen to your gut, and to the people that the universe puts in your path.

Building the habit

I've never written blog posts with any regular cadence, so I've set myself the challenge of writing one post a month for a year to build my writing habit. I've worked as a UX designer, design systems lead, and accessibility specialist over 25 years, so I figured I might have some thoughts worth sharing. Hell - if I run out of ideas, I have the outline of a 50,000-word book to plunder!

Disturbingly, the initial ideas jangling around in my brain are all AI related, like:

Could AI write my accessibility documentation without hallucinating a load of weird slop? If I have to fact check it all, is it any quicker than researching it from scratch?
What's Retrieval-Augmented Generation? Could it help tighten up LLM output? Can I build my own tool to query stuff? Could I replace myself with a prompt and spend the next 4 years in a hammock in Bali?
Help! Everyone in design systems is talking about MCP servers and I don't really know what this means.

Like many of you, I am currently going through an existential crisis over AI. I've actively started editing out my own em dashes—in case people accuse me of cheating.

The delightful thing about having my own blog is that I can write about whatever interests me. My site doesn't track anyone, so it's deliciously free from metrics and bullshit. I'm just writing for enjoyment and to learn stuff. How liberating is that? Who knows, maybe at the end of the year I'll feel confident enough to write a book.

Here's my RSS feed again if you want to join me on my year of building a writing habit.

If you don't use a newsreader app to browse blog posts, you should. It's simple to set up and beats the hell out of doomscrolling on social media. Read this guide by Matt Webb.

Designing for dyscalculia and low numeracy

Tue, 18 Feb 2025 00:00:00 GMT

Making numbers more accessible

I recently had a dyscalculia assessment. I clearly suck at maths but it was kind of a relief to get a formal diagnosis.

Dyscalculia is a persistent difficulty in understanding numbers. Along with your ability to do maths, it affects time, estimation, quantity and direction.

You develop workarounds. You buy a digital watch and read the numbers off because you can't tell the time. When eating out in groups, you either pick up the whole bill (ouch) or throw your card on the table and sneak off to the bathroom (awkward). You become accustomed to your family laughing at your comedically sized internet purchases.

According to the British Dyslexia Association, about 6% of people have dyscalculia. It’s often linked to other forms of neurodivergence, like dyslexia or autism.

I recently recorded a podcast with Laura Parker, a dedicated advocate for designing to help folks with dyscalculia, low numeracy and maths anxiety. If you haven’t already, check out her website accessiblenumbers.com or the fab poster she contributed to Gov.uk.

Speaking to Laura is always a joy. She’s the only other person I know with dyscalculia, and her experience with numbers is spookily similar to mine. Our conversation reminded me how little guidance there is for designing with dyscalculia in mind. It’s a gap we need to fill, and as someone with lived experience, I need to shout about it more.

How to design for people with dyscalculia

Forgive my mistakes

Entering numbers is tricky, and errors are almost inevitable. People with dyscalculia might put numbers in the wrong field, enter incorrect dates or times, or pay the wrong amount. Build systems that allow for error correction, like validation, that lets us input numbers in the format that works for us.

Better still, use tech to reduce manual input altogether. Let me scan numbers with my phone camera instead of typing them.

I don't trust myself to make large financial transactions. I regularly transpose numbers so I get someone else to check for me. Help is appreciated but having to ask for help leaves me feeling frustrated 😔

Give me space

Spacing matters. If you’re showing numbers — like appointment times or prices — leave space around them so they’re easier to process. Whenever possible, round numbers to whole values to reduce clutter.

Crowded tables, like travel departure boards, can be overwhelming. I’ve been known to photograph the board and send it to a friend to figure out which gate I need to be at!

Fill it in for me

Working memory is another challenge for many of us with dyscalculia. If you have information, like my account number or the amount I owe, fill it in for me.

Avoid patterns that make me remember details, like a verification code from a previous screen. Spoilers: I won’t remember.

Don’t rush me!

Time pressure is the enemy. Many dyscalculics struggle to tell time or estimate how long a task will take. If you must include time limits for security reasons, make the process clear and straightforward to avoid extra stress.

Patterns like “You have 3 soul-crushing minutes to complete this transaction” or “20 other people are viewing our shitty hotel room RIGHT NOW” are anxiety-inducing. I’m much more likely to make a mistake under time pressure and hate your company.

Offer numbers in context

Numbers without context are just...numbers. If you’re presenting data in grids or tables, consider offering a text-based alternative. A sentence that explains the numbers can make all the difference.

The Plain Numbers initiative showed how adding context to utility bills dramatically improved customers’ comprehension.

Involve your team

Low numeracy affects nearly 17 million people in the UK. Chances are, someone on your design or engineering team has first-hand experience. Involve them in the design process for insights you might not expect.

Low numeracy is exclusionary. Fair by Design has highlighted how the "poverty premium" makes life more expensive for people who struggle with numbers. They often pay more for essentials like energy or insurance because they can’t navigate the fine print or spot a better deal.

Getting a dyscalculia diagnosis

If you’re interested in getting assessed for dyscalculia in the UK, there’s information on the Dyscalculia Network site. Adult assessors are in demand, so be prepared to wait for an appointment and results.

Dyscalculia assessments are not currently funded on the NHS which is sucky. If you’re fortunate to have private healthcare, this might cover some costs if your plan offers a neurodiversity pathway. Otherwise assessments are self-funded. After the assessment, you’ll receive a detailed report which can be used for support in education or at work.

For me, getting assessed was for my own personal journey. It hasn’t changed how I feel about maths (still terrified!) but it has given me a better understanding of myself. The stigma around low numeracy means people often assume you’re lazy or stupid. No amount of pressure will allow me to infer data from a chart or understand the scoring system in tennis or darts (I mean, darts is basically just maths hell as a sport!).

There's a lot of societal shame around dyscalculia, low numeracy and maths anxiety. If you struggle with numbers, speaking out about it helps raise awareness and change attitudes. We can all design and build better ❤️

Dyscalculia resources:

WCAG for designers

Tue, 19 Mar 2024 00:00:00 GMT

WCAG for designers

The Web Content Accessibility Guidelines (WCAG) are the technical standard for accessibility compliance.

WCAG is complicated! As a designer-turned-accessibility lead, I know firsthand how overwhelming it can feel. To help, I’ve simplified the WCAG criteria most relevant to design into plain, human-friendly language.

Regardless of technical compliance, remember that accessibility is about people. WCAG compliance provides a baseline, but meeting the technical standard doesn’t automatically mean your product is usable. Humans are messy and complicated — just like their needs.

Got 30 seconds? Start here

WCAG has three levels of conformance:

A: The minimum level
AA: The 'technically accessible' level most organisations aim for
AAA: A high standard of technical compliance. Many of the criteria that help people with cognitive disabilities sit within AAA so it's worth striving for

Everything in WCAG hangs off four guiding principles. Is your digital product:

Perceivable?
Operable?
Understandable?
Robust?

Your content should work for users no matter how they access it. Think:

A screen reader announcing your content audibly
Someone zoomed in to 200%
A user on a noisy train or standing outside in bright sunlight

If you consider these principles when you design, you’re already making a huge difference. Got a little more time? Jump in here…

Colour

Use of Colour (A)

Don’t rely on colour alone to communicate meaning or to distinguish visual elements. People see colours differently, are colour blind or have difficulty telling different colours apart.

How can I use colour thoughtfully?

Provide an additional indicator to colour – a visible border, label, underline or icon.
If charts and graphics rely on colour, add distinctive, non-colour differences like hatching patterns or directly applied labels.
Learn about colour blindness
Install this colour blindness simulator to check your designs.

WCAG guidelines 1.4.1

Contrast minimum (AA)

Giving text a strong contrast colour against the background makes it easier for people to read and interact with.

The contrast ratio should be at least:

4.5:1 for text smaller than 24px, or 19px bold
3:1 for text larger than 24px, or 19px bold

How can I test colour contrast?

Use a contrast checker like this one from The Paciello Group
Or use an online colour contrast checker
If you design UI, the Stark plugin is well worth the investment

WCAG guidelines 1.4.3

Non-Text contrast (AA)

All components and graphics must have a contrast ratio of at least 3:1 against adjacent colours, unless they are purely decorative.

This applies to icons, charts, infographics and controls — including hover or active states.

How can I test non-text contrast?

Use a contrast checker and look for 'non-text contrast'

WCAG guidelines 1.4.11

Related criteria

Focus visible (AA)

It must be easy to tell which element has keyboard focus. This helps sighted keyboard users orient themselves within the page and confidently interact with it.

How can I ensure visible focus?

Provide a strong visible focus indicator on links, buttons, form fields
Make the focus state different from the hover state
Ensure the focus indicator has 3:1 contrast against the background
If in doubt, use the browser default

WCAG guidelines 2.4.7

Copy

As a designer, you often write placeholder copy without thoughtful consideration. Button text, link text, headings — these small bits of microcopy often make it to development. Thoughtful copy has a big impact.

Images of text (AA)

Text that is essential to the journey must not be part of an image. It can't be resized and becomes blurry when magnified.

What if there's no alternative?

If you must use it, provide thoughtful alt text for the image. Developers shouldn’t be expected to write this — it’s your job.

WCAG guidelines 1.4.5

Headings and labels (AA)

Headings must describe the topic of the section. Labels must clearly indicate their related form field’s purpose.

What makes a good heading or label?

Clear copy helps people with reading difficulties and screen reader users
Use proper heading levels and avoid ALL CAPS
Label form fields clearly and avoid ambiguity

WCAG guidelines 2.4.6

Layout

Meaningful Sequence (A)

Order content logically to match how users read or navigate your design.

Why is this important?

The user must access content in the correct order
This affects screen reader users and users with CSS disabled
Plan the semantic structure early to save dev time

WCAG guidelines 1.3.2

Related criteria

Orientation (AA)

Your design must not require a specific screen orientation — unless essential (like a VR or TV app).

WCAG guidelines 1.3.4

Resize text (AA)

Users must be able to resize text up to 200%.

This helps people with low vision. Ensure your layout still works at large text sizes. Avoid fixed-width containers that prevent copy from reflowing.

WCAG guidelines 1.4.4

Consistent navigation (AA)

Navigation that appears across pages should be consistent.

How?

Menus and breadcrumbs should work and look the same everywhere

WCAG guidelines 3.2.3

Sensory characteristics (A)

Instructions must not rely on visual cues alone.

What to avoid

Instructions like “click the red button” or “see the right-hand column”

WCAG guidelines 1.3.3

Consistent identification (AA)

Features used in multiple places must be identified consistently.

Tips

Label buttons the same way every time
Label form fields consistently
Use consistent icons

WCAG guidelines 3.2.4

Foundations for the BPP design system

Sun, 17 Mar 2024 00:00:00 GMT

Foundations for the BPP design system

I spent 6 months at education group BPP, laying the foundations for their new design system and supporting on web accessibility.

So, who are BPP?

BPP are one of the UK's largest providers of professional qualifications across law, accountancy and business. They're going through a huge digital transformation project across product and tech.

If you want to check out the design system I helped build:

Components are exposed in Storybook
The system is documented on the Scholar zeroheight site

## My contribution

I was engaged as a Web Accessibility Designer. It's great to see big companies putting accessibility at the forefront, right from the system's foundations. Along with clean code and clear documentation, accessibility was one of the team's core principles. It's a real joy to join a team who prioritises accessibility.

Here's what I contributed to the design system...

☞ Choosing a name

I'm starting to question whether an in-house design system actually needs a name. I've worked in teams where the design system identity has sort of alienated the system from the core brand it's serving. Maybe that's just been down to the culture, or choosing the wrong name.

The team at BPP felt like the name "BPP Design System" was a bit of a mouthful and I had to agree. They wanted a name that was distinct, straightforward and represented their heritage brand. We workshopped, riffing off words around teaching, learning, progression and BPP’s lion mascot. We landed on:

Scholar: Designing success

Scholar can mean student, specialist or learned person so as an education brand it covered off the different levels of end consumer nicely.

Everyone knows you're not a real design system until you've got stickers so with our name sorted, we went ahead and ordered some shiny ones. I've only got a bachelor's degree in design so being a Scholar made me feel fancy 💅🏻

☞ An accessible colour palette

The existing BPP digital palette was limited and there were instances where achieving accessible colour contrast was not possible because there just weren't enough colours to use. I interviewed designers who had concerns about using colours consistently without any usage guidelines.

I suggested that we introduce colour ramps and met with the Brand team to see if they would be onboard. Coincidentally, they were working on a brand colour refresh so we joined forces and workshopped a new palette.

I used Leonardo to create colour ramps. You can set a lightness scale and define contrast stops which allows you to set rules for colour. I eventually settled on OKLCH which gave the most perceptually uniform colours.

If you're also a colour nerd with a spare weekend to burn on colour spaces, this article on Smashing makes for a nice starter.

☞ Tokens

The existing component library worked off hardcoded values like hex codes for colours and pixels for spacing. This was working fine in Product but the designs we saw from the team rebuilding bpp.com required both a light and dark colour theme. It was clear the setup needed tokens to give the layer of abstraction required for theming.

I mapped out a token architecture, introducing just a single level above ramps:

Token categories included:

Base tokens: for default UI like text, icons, backgrounds, borders
Interactive tokens: for interactive elements like buttons and links
Status tokens: for status components like notifications and chips
Brand tokens: to differentiate between brands

Category	Usage	Intent	State	Variant
colour	base	positive	default	emphasis
	interactive	negative	hover	default
	status	informative	active	subtle
	brand	neutral	visited	inverse
		ink	focus	input
		interface	selected	000-060
			disabled

After extensive testing and applying tokens in Figma, we tweaked groupings, aligned code and rolled this out. We then extended our tokens across type and spacing as well.

☞ Building and documenting a whole lot of components

A few months in, the engineering team decided to re-platform Scholar. I worked with engineers to rebuild components in the new repo, getting specs together for behaviours, states, focus order and ARIA attributes. We prioritised the components needed by the bpp.com team and created a zeroheight site to document everything.

☞ Accessibility upgrades

I helped on several accessibility initiatives, including:

Writing an accessibility statement and getting legal approval
Presenting the colour upgrade at Townhall
Starting an accessibility working group
Teaching the team how to test with screen readers
Connecting with Diversity & Inclusion

It was fun to work on the foundational setup of a system. Tooling has come on so much since I last attempted this. Figma variables and Tokens Studio did the heavy lifting on tokens and Leonardo made creating colour themes fast. It was a real pleasure to work with such a talented team and I'm keen to see the design system components and updated brand style rolled out.

Leaving NewsKit

Mon, 12 Jun 2023 00:00:00 GMT

Leaving NewsKit Design System

I was lead designer on the NewsKit design system. Here’s the awesome stuff the team and I worked on.

So, what’s NewsKit?

NewsKit is a design system that feeds media and broadcast brands across News Corp. In the UK that’s brands like The Times, The Sunday Times and The Sun. In the US, NewsKit provides the foundations for Dow Jones on sites like the Wall Street Journal.

The system’s design and code is open source if you want to check it out:

Components are on GitHub and exposed in Storybook
Design libraries and theme are on the Figma Community
The system is documented on the NewsKit website which is dogfooded from NewsKit components

Our assets received a lot of shares from the design community, it was great to be able to contribute to ongoing good practices.

My contribution

I can’t take any credit for NewsKit’s early success — its strong brand and foundations are down to the talented design and engineering team. Here’s what I've contributed during my year on the system:

☞ Planning and roadmapping

As design lead I pitched in on roadmapping and prioritising deliverables. We met regularly with title teams to identify component needs which fed into the PI planning cycle.

I worked with the Head of Design Systems and Engineering Lead to triage issues and prioritise work. We used GitHub Issues and ran weekly tech analysis sessions with the team.

We held twice-weekly design reviews, shared WIP, and made decisions collaboratively. We also ran workshops to define and prioritise team goals.

☞ Accessibility foundations

News UK had no overarching accessibility policy, so I helped launch an initiative to create one.

I pitched to the News UK Investment Board with the Head of Diversity & Inclusion for funding to hire an accessibility specialist. We brought on a consultant who helped us draft an Accessibility Policy and accessibility statement. I chaired our new accessibility working group.

I was recognised internally as the accessibility lead and created an accessibility hub on the NewsKit site. I spoke at internal and external events, including a Supernova accessibility panel and Q&A, and gave a talk at WDC about WCAG 3.0.

☞ Writing technical docs

Over the year I wrote and edited a lot of technical documentation — a part of the job I really enjoy!

I worked with engineers to add new components like pagination and composable card. We start with research and a spec covering behaviour, states, ARIA tags and API. Then we refine, test, and finalise both the code and Figma design assets.

The NewsKit site already had good docs, but the tone was inconsistent. We brought in a tech writer, and I worked with them to polish the copy. The themable illustrations are thanks to our brilliant junior designer!

☞ Storybook upgrade

NewsKit uses Storybook to expose components to engineers. The original stories lacked visual consistency.

I worked with our Senior UX Designer to improve branding, simplify IA, and spec consistent stories. We collaborated with engineers to roll this out.

☞ Advocacy, community engagement and mentoring

To raise NewsKit’s profile, I spoke at events like Converge and on podcasts like Design Ops Island Discs. Our team hosted the YLD Design Systems London meetup at London Bridge.

I ran the NewsKit Twitter account with our engineer Luke Finch, growing our audience with bad puns 😄

As a lead, I mentored designers across the business. Helping others speak, write, and contribute to OSS is one of the best parts of the job.

☞ We won an award!

I worked with our Head of Design Systems on a pitch for a RITA (Real Innovation Technology Award). NewsKit won in the "Delivering Excellent Customer Experience" category — a well-earned win for our dedicated team!

How to write an accessibility statement

Tue, 28 Mar 2023 00:00:00 GMT

How to write an accessibility statement

Here's a guide on how to write an accessibility statement.

I've published accessibility statements for various organisations, including Just Eat, News UK, BPP and Checkout.com. They have proved an excellent source of feedback from disabled customers. Often the issues that customers report are not technical fails so they wouldn't get logged by audits or unit tests. Instead, they are usability problems when accessing a site using assistive technology and this first hand feedback is invaluable to helping you improve.

What is an accessibility statement? Why is it important?

An accessibility statement shows your users that you care about accessibility and demonstrates your commitment to improve your experience for everyone. In the UK private sector, it’s not yet a legal requirement but it is for some public bodies that implement the EU Web Accessibility Directive. If you’re unsure, W3C has a filterable list of accessibility laws and policies by country.

Regardless of laws, writing a statement is a smart move. It shows you are considering people’s access needs. It’s also becoming something companies increasingly look for as part of the due diligence process they undertake when engaging your services.

What to include

There are no formal rules on what a statement should contain. Think about your users, the information and the format that would benefit them. The Worldwide Web Consortium has a useful section on how to write a statement which is a great place to start. W3C suggests that a minimal statement should include:

Your commitment to accessibility for disabled people
What the statement covers
The accessibility standard applied, e.g. WCAG 2.2
Contact information if a user encounters problems
When the statement was prepared

A complete accessibility statement might also include:

Any known limitations that might frustrate your users
What your company is doing to improve
Any technical prerequisites, like which web browsers you support
Environments in which the content has been tested to work

In addition, this talk by the Government Digital Service also recommends including:

How the user can obtain alternative formats
A roadmap of planned improvements
A link to an accessibility audit report

This sounds like a lot of work but you can start small and build on it over time. The important thing is to get something out there that shows you care about accessibility.

How do I know what is not accessible?

An accessibility audit is a good place to start. You don’t have to test every screen — a sample of the core pages and functionality is sufficient to highlight the majority of fails. If you have someone in your team with knowledge of WCAG, the technical skills and the time, you can do an audit yourself.

The alternative is finding a third party consultant or agency to undertake an audit for you. I have used the Digital Accessibility Centre, AbilityNet, and Deque for past audits. They produce excellent reports and guidance for engineers on how to implement fixes.

Good examples

The W3C has a template for a minimal and complete statement and a tool to generate a statement if you fill in the blanks. If your goal is to write a statement in plain English that doesn't read like legal T&Cs, check out these best practice examples:

If you're not sure what to start with, you can use these examples as a template.

Publishing

Before putting an accessibility statement live, you'll need feedback from your D&I team, design, product, engineering and legal. If you’re new to a company, this can be a great way to engage with all these specialisms and make contacts. At one company I formed an Accessibility Guild off the back of this initiative as it helped to get folks collaborating.

Publish your accessibility statement somewhere easy for users to find — usually in the footer. HTML is the most accessible format so avoid using a PDF or a download.

Finally, keep the statement alive and remember to update it when you get audit results, fix fails, and make improvements.

Here's some statements I've written – you are welcome to copy the format:

Just Eat in 11 languages including English, Spanish, Italian, German and Dutch
BPP
NewsKit
Checkout.com
And of course, this site

I've enjoyed learning how to write a statement. If you’re planning to add an accessibility statement to your site, I hope these links help.

If you're writing a statement for an organisation, seek advice from legal counsel before publishing.

Designing an Accessible Future

Wed, 05 Oct 2022 00:00:00 GMT

Designing an Accessible Future

Writeup of my talk at WDC, applying the principles of WCAG 3.0 to some current visions of the future.

📺 Watch the talk on YouTube

Advice here is current at the time of writing but the WCAG 3.0 draft is evolving. Check the latest version.

If you prefer to read, here's the text 👇

As an industry, we measure accessibility using WCAG – the Web Content Accessibility Guidelines. There’s a huge update on the horizon: WCAG 3.0, which is proposing a radical change to the way we test and measure accessibility.

I used this talk to dig into the draft to explore what the future of accessibility might look like, and how we can get ahead of it now.

They’re saying it’ll be at least five years before WCAG 3.0 rolls out – so what will the internet look like by then?

So… what’s wrong with WCAG 2.x?

The Silver Community Group identified key issues with WCAG 2.x:

☞ Usability

It reads like a legal document. It’s daunting for beginners and hard to sell to stakeholders.

☞ Conformance model

It’s binary: pass or fail. But humans don’t always fit into neat boxes.

☞ Maintenance

WCAG 2.0 was published in 2008 — the year the first iPhone launched.

Read the problem statements.

What’s new in WCAG 3.0?

Easier to read and understand
Covers a broader range of disabilities
Designed to evolve with technology
Focuses on real-world accessibility, not just box-ticking

Key changes

Guidelines

Example guidelines include functional categories, critical errors, and rating scales.

How-to guide

How-to docs explain why something matters and how to implement and test it using methods.

Critical errors

Defined per guideline. For example, missing alt text that prevents task completion is a critical error. You can’t pass if you have any critical errors.

Testing

Two types proposed:

Atomic tests: automated checks.
Holistic tests: usability testing with assistive tech.

Conformance levels

Instead of A/AA/AAA, it’s Bronze, Silver, Gold.
To score Silver or Gold, you’ll need holistic testing.

Terms comparison

WCAG 2.x	WCAG 3.0
Non-interference	Critical errors
Success Criteria	Outcomes
Techniques	Methods
Understanding	How to
Level A, AA, AAA	Bronze, Silver, Gold

Putting it all together

Adapted from the WCAG 3.0 explainer

Other notable changes

User-generated content

First mention of social media, uploads, etc.

Clear Words

Plain language for people with cognitive disabilities.

Improved colour contrast

WCAG 3.0 introduces APCA, a perceptual contrast measure.

Sometimes the option that passes is harder to read!

Key takeaways:

New scale: 0–100
Accounts for type size/weight
Context-aware (foreground/background)

📖 Dan Hollick’s APCA explainer

Thinking ahead: Web3

What will the web look like in five years?

“Who’s heard of Web3?”
All hands go up.
“Who understands it?”
All hands go down.

Web3 is full of promise — open, inclusive, decentralised. But in reality? It’s complex, opaque, full of jargon and acronyms:

So many unfamiliar terms.

🔗 What is Web3? – Harvard Business Review

Even Web3’s creators admit it’s inaccessible. In this Wired interview, Gavin Wood suggests people should “bother educating themselves.”

I did — it took me 20 hours.

Web3 has a serious accessibility problem

“Clear Words” would score Web3 a 0.

There are financial, cognitive, and technical barriers. The crypto space is dominated by white men. According to Forbes, every crypto billionaire in 2021 was male; most went to elite universities.

The NFT market wasn’t much better — 55% of revenue went to just 16 artists.

We have a chance to course-correct. Let’s build something better.

Humanity Centred Design

Donald Norman is moving from Human Centred to Humanity Centred Design in his upcoming book, Design for a Better World.

Principles:

Solve root problems
Think ecosystem-wide
Take the long view
Test with the community
Design with—not for—people

Accessibility and inclusion fits right into this.

Is an accessible future one without screens?

Voice and gesture interfaces can bypass barriers.

Without screens, there's no colour contrast to worry about — everything becomes UX, content and journey.

Get a headstart on WCAG 3.0

Watch the draft evolve

Follow updates from Deque

Prioritise critical errors

See WCAG explainer

Test with disabled users

To score Silver or Gold, you’ll need holistic testing

Use awareness days

Global Accessibility Awareness Day is a great moment to rally teams

Learn from disabled people

Follow their blogs and social channels. Search YouTube for screen reader demos.

Most importantly… prioritise accessibility

Automated testing gets you 59% there. Don’t aim for perfect — aim for progress.

As people building the internet, you have power. Whether our future is decentralised or dystopian, every improvement counts.

Quote from Sheri Byrne-Haber – photo by Josh Tumath

You are the internet makers. That comes with responsibility. Make it accessible.

Links from this talk

☞ Official W3C

☞ WCAG 3 Blogs

☞ Web3

Reading list

☞ Colour

☞ Humanity Centred Design

☞ Voice and screenless UI

📖 Slides from the talk Feel free to reuse ❤️

Scaling accessibility with a design system

Tue, 07 Sep 2021 00:00:00 GMT

Scaling accessibility with a design system

This is a post about my experience of learning how to design accessible web components, then scale their impact through a design system.

What problem does this solve?

Rather than everyone individually fixing the same accessibility problems, a design system enables an organisation to propagate accessible components at scale. Fixes are multiplied outwards saving time and money for product teams using the system.

Audience

I spent 3.5 years building a design system for Lloyds Banking Group. The design system supports 4 brands: Lloyds, Halifax, Bank of Scotland and MBNA. Any change made to a component like a button, form field or notification is pushed out to all brands.

The design system 'source of truth' is React components, with corresponding Sketch design libraries. Components are served from a website which brings together UX, copy, and guidance for use. The system is currently used by over 30 product teams within the Lloyds Group; our main consumers are designers, developers and POs.

Accessibility is important because 1 in 5 of the UK population report a disability. There are also many temporary and situational scenarios that affect people's access to online services. Lloyds conforms to the standards set by the Web Content Accessibility Guidelines and undertakes accessibility reviews to ensure products are accessible to and usable by all customers.

Accessible products are better for everyone. Along with users of assistive technology, there are many situational and temporary scenarios that affect the way people use the web.
Graphic adapted from Microsoft's Inclusive Toolkit.

Legal and regulatory obligations aside, it's been great to work for a company that has a genuine commitment to making inclusive products. Lloyds has an active Accessibility Guild, tools, testing, and clinics that designers are encouraged to take part in.

Research

Getting to grips with WCAG

WCAG stands for Web Content Accessibility Guidelines and is the benchmark for accessibility standards across digital products. If you’ve ever attempted to grapple with WCAG, it is initially an overwhelmingly complex set of guidelines.

I realised the only way to engage with WCAG properly was to set aside a whole day and read the guidelines end-to-end. I then read through again, noting all the criteria related to design. The guidelines are ordered by four principles of accessibility. When designing for the web, your content must be:

Perceivable, Operable, Understandable and Robust

Each WCAG guideline has a number of success criteria and also a conformance level: A, AA or AAA. Lloyds aims for AA. AAA is much harder to reach, especially with legacy systems and branding.

Specialist help

When I started my role I volunteered to become an Accessibility Champion – a program run by Lloyds Vulnerable Customers team. Through this I was introduced to the Digital Accessibility Centre, a not-for-profit that employs a team with a range of disabilities. They specialise in testing digital products using assistive technology.

Watching DAC’s Low Vision and Screen Magnification Analyst test our web components made me rethink the way I design. I realised how difficult it was for someone with low vision to interact with low contrast elements. Observing real users of assistive tech is eye-opening in a way that simulations never are.

Industry meetups

To understand accessibility outside my org, I joined meetups. Accessibility London is a great one. Talks are insightful and streamed with captions.

I met folks like Zeinab Ali from How Do I, who interviewed me for their blog.

Accessibility audit

I audited our design components against WCAG 2.1 AA criteria. Accessibility for Everyone by Laura Kalbag helped me prioritise. As a designer, these were my focus areas:

Contrast minimum: WCAG 1.4.3 (AA)

Contrast ratio should be:

4.5:1 for text smaller than 24px or 19px bold
3:1 for text larger than 24px or 19px bold

I used Colour Contrast Analyser and Stark to check values.

Use of Colour: WCAG 1.4.1 (A)

Don’t rely on colour alone. We added icons to error states, alerts and notifications.

Non-Text Contrast: WCAG 1.4.11 (AA)

We changed input field colours and adjusted alerts to meet contrast standards.

Meaningful sequence: WCAG 1.3.2 (A)

Structure matters — screen readers and CSS-disabled views depend on it. We reviewed how headings and content blocks were used across journeys.

Text Spacing: WCAG 1.4.12 (AA)

Users must be able to increase:

Line height to 1.5× font size
Paragraph spacing to 2× font size

We updated Sketch text styles and worked with devs to reflect this in code. Smart components using auto layout help here.

Testing

When the React components were ready, we brought in AbilityNet for accessibility testing. Their review found:

✅ 0 high priority issues
⚠️ 22 medium and 3 low issues — all resolved

We can now say our components conform to WCAG 2.1 AA.

Feedback and support

This process taught me so much. Constellation (our design system) has proven its value in scaling accessible components across brands.

But — accessible components don’t equal accessible journeys. Semantics and copy matter too. Nathan Curtis says it well.

We run a weekly support clinic for teams. Fixes to shared components benefit everyone using the system — and their users.

Resources I’ve learned from

Web Content Accessibility Guidelines (WCAG)
Understanding WCAG 2.0
Accessibility for Everyone by Laura Kalbag
Digital Accessibility Centre
AbilityNet
GDS Design System
“Accessible” Design Systems Don’t Guarantee Accessible Products
Website Accessibility Checklist by Bruce Lawson
Color accessibility: tools and resources by Stéphanie Walter
There is no “Myths of Color Contrast Accessibility” by Geoffrey Crofte
Designing accessible color systems by Daryl Koopersmith and Wilson Miner

5 things I learned building Constellation

Sat, 19 Jun 2021 00:00:00 GMT

5 things I’ve learned building Constellation

I'm leaving Lloyds Banking Group after three and a half years building the Constellation Design System. It’s been an incredible journey, and I’ve learned so much along the way. Here's a few of the key learnings I want to share.

1. Community is everything ❤️

A design system can’t go the distance without the support of the community. The most enjoyable part of building the Constellation Design System has been meeting people, even for an introvert like me!

The team have run a weekly drop-in clinic for the past 3 years. I wrote a post about it here. It’s an open invite for designers, engineers and product people to swing by and share their problems. Prior to Covid we ran it in person, but it’s actually been more successful over video call as folks from around the country can phone in.

We troubleshoot bugs, fix code, solve UX problems, discuss contributions and review work from agencies. I figure I’ve spent around 350+ hours in this clinic. It’s been an epic immersion in brand, UX patterns and problem solving. Common themes emerge. If you want to get to know your users and their pain points I would highly recommend an initiative like this.

As our reach grew, we spent a lot of time reactively answering queries over email and chat. We clung fast to our scrappy roots but ultimately this sort of service doesn’t scale. We had a keen graduate who designed us a Jira service desk and we slowly coaxed our users to start logging tickets rather than contacting us directly. This helped time-box requests and increased productivity. It’s also a transparent way to show tasks are being assigned and progressed.

Ermahgerd, writing positive things about Jira. Am I finally . . . a grown-up?

2. Contribution requires a dedicated herdsperson 🙋

Back in 2019, Nathan Curtis introduced the idea of a contribution shepherd. I fell in love with this idea, my subconscious conjuring a be-robed herdsperson, moving complex components across the rich mountain pastures of Andalusia.

To become systems-approved and ready for release, a component needs the work of many specialisms; research, interaction design, conversation design, visual design, accessibility and engineering. We considered three routes:

Only accept complete components
Accept incomplete components and finish them in the systems team
Accept incomplete components and shepherd the community to complete them

We opted for the third approach, keen to act as curators. If the system only accepts complete components, everyone misses out on valuable insight, thinking and ideas that may not have made it through to a finished component. If teams can contribute just part of the process, other teams can pick up where they left off.

We published our contribution strategy, straightforward acceptance criteria and a process to follow. But what we lacked was a dedicated shepherd to oversee the process. Contributions were often lost when team members prioritised sprint work or moved on. The product lab who contributed the component would disband. We’d awkwardly eye the contribution in the backlog like an abandoned puppy.

Without a dedicated shepherd, contribution is tough. I’d love to hear if anyone has successfully achieved this, sans shepherd.

3. Document everything ✍️

Even if guidance or thinking never makes it to the official design system website, keep a record of it. We used a Confluence space with the same taxonomy as the design system where we collated research, wireframes, links, discussions and notes. In a systems team you’re regularly asked why you’ve made a decision and having the research or documentation to share helps build confidence in the service.

4. Make the design system mandatory! 🚨

If the design system isn’t mandatory then it is tough to get everyone onboard. During my time at Lloyds I’ve seen product teams and agencies rebuild the design system from scratch a few times over. I totally appreciate labs have their own deadlines and priorities. Teams are hindered by different tech stacks and legacy jank. Our system is not accessible externally, a massive blocker. And there is always a shiny new way of doing things.

For the systems team, the duplication of effort and slow creep of inconsistency is disheartening. If the funding and effort can be put into building one system, it will benefit everyone. Rebrands and change becomes straightforward and more cost-effective. This will ultimately ensure a more consistent, accessible experience.

5. Content is king 👑

Before I worked on Constellation, I thought I wrote pretty decent web copy. Turns out, my writing is actually pretty average. Congrats for even getting to this paragraph, my dude. Our brilliant conversation designer would take my words, remove 50% of them and turn them into something structured and meaningful.

Design and code might be the system’s focus but don’t forget about the words. A good content designer will bring consistency, standardise language use in components and structure your systems guidance. They’ll help your brand voice sound distinctive and recognisable across everything from onboarding to error messages.

Many of the accessibility and usability issues we saw in our drop-in were attributed to copy and content structure, rather than design or code.

Feels like the end of an era!

I’m sad to be leaving Lloyds Banking Group today but so proud of what our small team has achieved over the past three and a half years. 💪

Lloyds is a great place to work. It's full of thoughtful product people who genuinely care and champion the needs of both colleagues and customers.

Building a design system at a bank is a tough gig, amidst compliance, process and legacy tech. It's easy to be critical and compare your system to others but given the constraints and limited budget, I think we made a pretty decent job of Constellation 1.0. I just wish we could open source and share all our documentation and research goodness.

On a personal level, this role has taught me it’s okay to fail. Not an easy task for someone who over-analyses EVERYTHING. I’ve lost sleep over big releases and deprecated components.

As a design systems team you probably won’t get it right the first time. Or the second time. Or the third. Be accountable. Own it, learn from it and improve. I guess this goes for everything in life, not just design systems.

Halifax digital rebrand

Sun, 14 Feb 2021 00:00:00 GMT

Halifax digital rebrand

I worked on the digital rebrand of Halifax. The main brand identity was created by agency Rufus Leonard. As the UI lead in the design systems team, I helped take the visual identity and make it work for digital. Here's what my awesome team made happen.

We started with the brand principles

When designing for a brand, I always start with the principles and brand strategy. Halifax is about people and making banking more human. It's aimed at hard-working, down-to-earth folks who value brands that are on their level. My team was keen to reflect this in the UI – make it straightforward, no-nonsense and easy to interact with but not at the expense of brand personality.

An accessible colour palette

As a bank, it's important that our interfaces are inclusive and accessible to all of Halifax's 27 million customers. We comply with WCAG 2.1 guidelines to an AA standard. This means selecting colours that have sufficient colour contrast between the background and each other.

Primary palette

I worked alongside Rufus to tweak the palette to ensure it worked, not just in the big brand stuff but in the granular details; form components, focus states, buttons. We tested usage across different products from internet banking to the mobile app. Good colour contrast helps not just our customers with low vision but folks using the website or app outside in bright sunlight or while juggling another task.

It was also important to find a harmonious scale of colours that complemented each other and to specify proportions for use. I dug into a lot of colour theory and appreciated some of the super detailed guidelines shared by the community. As a small team of designers we really laboured over this… everyone got sick of me banging on about WCAG colour contrast ratios :)

Functional colours

We created a set of functional colours with our colour blind customers in mind. Red/green is the most common form of colour vision deficiency and it can be hard to distinguish between alert and success messages. I experimented with a lot of different greens and reds. Again, finding a harmonious scale was important by tweaking the hue and brightness plus ensuring the colours for states both contrasted with and complemented the core palette.

Though a colour blindness simulator:

UI colours

A design system needs additional UI colours to enable the creation of complex components; greys and background colours for light/shade and depth. If you don't spec these out and test them, designers will understandably add their own, resulting in gradual inconsistency. Rather than pure greys I used blue-greys which helped the scheme hang together. Text is also dark blue rather than grey.

Wut? That doesn't seem like many colours (⊙.⊙)

We made a deliberate decision to limit the colour palette and not allow any variation. Our other brands have tints and tones of primary and secondary colours. In the hands of a design craftsperson these can really shine, but our design system is used by a lot of specialisms. We wanted a robust system that could be widely used and allow non-designers to feel confident in their choices. I'm pleased we did this — across the board it's resulted in a much cleaner and consistent brand presence. The key was doing a lot of testing up-front and making sure all instances were covered.

Icons and illustrations

Rufus Leonard supplied us with a brand style but it was down to my team to produce digital icons and illustrations. We got together an icon and illustration library, along with guidance for use. Line icons are notoriously difficult to scale and it took some experimentation to come up with a scaling system that worked.

Accessible form components

I designed the set of form components for the design system. I tested these hard before finalising the spec. The Halifax brand is all about people and making banking more human. I was keen for this to come across in the design of all the little details – big radio buttons, fat focus states.

Digital guidelines

To help get designers on-board with the new identity, I worked alongside our content designer to create a set of digital guidelines. The main brand guidelines cover everything from billboards to letterhead and they can be time-consuming to grapple with. This is a smaller edit, just for the creation of digital products. It contains a short overview of brand strategy, principles and tone of voice then detailed guidelines on icons, illustrations, photography, graphics, etc. These were well received by the community and we've since been asked to create the same for our other brands.

Onboarding

Our design systems team runs a drop-in clinic each week where we invite designers, developers and product people to share what they're working on.

We've used this clinic as a way to review designs in the new Halifax branding. When designs are looking good we help teams take them to a weekly design call where they are reviewed and signed off by Brand and Design. It's been great to have this visibility across products and ensured journeys are true to the new brand. Most importantly, it's highlighted pain points and areas that aren't working for teams, that we can help to improve.

Rollout

With such a large and complex digital estate, the rebrand has been slow to roll out. The public site was reskinned and I worked with the mobile team to align while they refreshed the iOS and Android apps. Our design system feeds mainly application journeys and these are slowly being updated and coming in-line. The rebrand has highlighted the value of a design system and it's been significantly quicker to rebrand the journeys that were already using the system.

Personally, it's a joy to see products being built using the components we designed looking fresh, usable and accessible.

Building Constellation

Wed, 12 Feb 2020 00:00:00 GMT

Building Constellation

I spent three and a half years building a multi-brand, multi-platform design system for Lloyds Banking Group.

Lloyds is the UK's largest retail banking group with over 30 million customers. It was an interesting journey; taking a product from small beginnings through to an established design system with an engaged community. Like any system, we changed and evolved based on user needs.

The Constellation Design system website

It wasn't always plain sailing but smooth seas don’t make good sailors! I’m proud of my small team’s achievements. The design system is not open-sourced so here is a case study to share the journey.

What problem does it solve?

The aim of Constellation is to bring consistency across a visually fragmented digital estate. Historically, there have been different interpretations of the brand guidelines across value streams and product areas. Each team individually designing and coding their own interpretation of core components (headers, form fields, buttons) has led to significant variation.

Visual consistency is proven to help customer engagement. Inconsistent branding ultimately erodes customer loyalty and brand trust. Consistency is not limited to visual assets but extends to copy and shared conventions.

We replaced 26 button variations in Halifax brand with one primary and second button

Getting started

When I joined the team, we had the catchy name of ‘Unified Design System’ or UDF. Being associated with an acronym best known for a Northern Irish paramilitary group didn’t do much for the inclusive and welcoming nature of the team 🤗 so we decided to rebrand. We mooted lots of names, many horse related. We put it out to our end users who voted on "Constellation" — recognisable patterns that help people navigate.

Our junior designer created us a super logo. It wasn’t until we had stickers printed that we finally felt like a PROPER design system.

What to include?

Before I joined, the team had decided to focus on form components. This was the quickest way to add value as application journeys feature heavily across the banks’ products and platforms.

One of the most difficult early decisions was naming components and deciding on a structure. We ran a card sort with designers, developers and product owners. We based our structure and naming conventions on these findings.

Constellation covers four brands: Lloyds, Halifax, Bank of Scotland and MBNA. The complexity of a multi-brand system brings challenges — but also amplifies the impact of improvements.

Naming the thing is much more difficult than making the thing! Nathan Curtis's articles were a valuable resource.

Website

Our components are built with React and code is our system’s source of truth. We built a pattern library site to expose the React components. Over time, the site grew to include:

Editable props showing states and variations
Links to Sketch libraries and example layouts
UX best practice
Plain English and brand writing guidance
Accessibility standards

We iterated based on user feedback — replacing an elegant but confusing toggle with simple buttons. Simpler was better.

Sketch libraries

We started with static kits per brand. These quickly went out of date as people saved them locally.

We adopted RSS updates for Sketch libraries hosted on GitHub, using an AppleScript-based tool we nicknamed the “Deploy-o-tron.” We used semantic versioning to track changes.

Taking away Sketch kits caused pain — but sometimes disruption is needed for long-term gain.

Sketch brand swapper

We enforced naming consistency to support Sketch Symbol Swapper. This let us apply layouts across brands with one click.

We're considering a white-label library for unbranded prototyping in the future.

Versioning design files

Our early “shout across the office” method didn’t scale. We evaluated various tools and adopted Abstract, a versioning tool for designers. Since then, no more overwritten files or lost work.

Advocacy

We struggled with visibility early on. We ran demos, attended hackathons, and launched a weekly drop-in clinic. Initially quiet, it’s now a valued collaboration session.

We also hosted a quarterly design systems meetup and shared invites via the Design Systems Slack #city-london channel.

Bumps in the journey

🤯 Imposter syndrome

Other systems always look better. But we were building for 30 million customers. We learned to celebrate small wins.

🛠 Move slow and fix things

We made early UI changes without consensus. Lesson learned: involve your users early and often.

🧑‍🚀 Contribution and feedback

We use Jira for bugs and GitHub for code. Our goal is to curate partial contributions and help other teams build on them.

♿ Accessibility

Some inherited components didn’t meet WCAG 2.1 AA. AbilityNet and Digital Accessibility Centre helped us raise the bar.

🧱 Incompatible tech stacks

Some teams couldn’t consume our components due to older React versions. We chose to stay up-to-date and help others plan accordingly.

🔌 Third-party plugin woes

We relied on Anima's AutoLayout in Sketch. A Sketch update broke everything. We patched it fast, but learned to test betas before release.

Resources I’ve learned from

Nathan Curtis’s Medium
Form Design Patterns by Adam Silver and his blog
Design Systems Newsletter by Stu Robson
Accessibility for Everyone by Laura Kalbag

Design systems we admire:
Gov.uk, Backpack, Bulb, FutureLearn, Material Design, Uniform, Barnardo’s, Luna, Canvas, Aviva Standards, Carbon, MorningStar, Polaris

Next steps?

From small beginnings to saving £7 million in design and build costs — not bad for a team full of imposters 🙂

First rule of Design Club

Wed, 08 Jan 2020 00:00:00 GMT

First rule of Design Club

I ran a series of design thinking workshops at a London secondary school. Here's a post on my experience of working through the design process with teenagers.

What problem does it solve?

Learning a basic design process of research, discovery, ideation and iteration allows kids to think through problems and design useful and usable solutions. As a mother to two teenagers I've found design thinking to be lacking in the school curriculum. The future needs people-centred designers and thinkers! I wanted to volunteer some time to pass on this simple skill.

Starting a Design Club

I discovered Design Club, a social enterprise on a mission to inspire the next generation of designers. The initiative was just kicking off and had run a few pilot sessions. The founders were very welcoming and had produced some fantastic resources for volunteering in schools.

I had run a primary school Code Club for 4 years and had some experience volunteering in schools so this initiative seemed like a good fit. I eagerly signed-up.

I spent my Christmas down-time contacting secondary schools near Old St, London offering a free, weekly after-school Design Club. I arranged to visit a school in Islington who were super keen to run a club and we agreed a start date. I then got to work running through the suggested curriculum and decided how to structure the sessions. The school offered the club to students in Year 7-8, so kids aged between 12–14. I had 12 students initially sign up.

Define a challenge

I ran an initial kick-off session to give an overview of the design process and what we would be making over the coming weeks. We did some fun, creative warmups then defined our challenge. We would be designing an app that solves a problem for a person. For the first project we agreed we would all work on the same challenge but students could work in groups or individually.

We had an initial think about how an app might help people and why saving money might be important to them.

Who's are we designing for?

We then chose a person to design for and created a user profile to measure our design decisions against. We thought about what our person's financial situation might be like and their attitude towards money.

Empathise with your person

It's important to get to know the people you're designing for so you understand their needs.

I ran a session on people who live in different places and have different needs. We looked at Facebook users in India accessing the app on old smartphones with 2G connections. I talked about my visits to the Digital Accessibility Centre and showed how Blind, low vision and mobility-impaired people use assistive technology to access apps. This was a really successful session — the students seemed super engaged and keen to get outside their comfort zone.

We then mapped out 'a day in the life' of our person to see what someone does in a normal day, what their habits and frustrations are, and where we might be able to design something that fits their routine. We also built an Empathy Map where we picked a situation related to our person saving money and thought about what they are seeing, saying, feeling, hearing and thinking. This helped us generate ideas.

Gather inspiration

Now we had defined our challenge and our user, we did some research into existing apps and looked at how they solved problems. This was also useful from an information architecture perspective as we started to think about how apps are structured.

We talked about the importance of branding and making our app visually appeal to our person. It was time to get creative! We made mood boards around the theme of our app — and a lot of mess in the classroom. The students decided on an app name and tagline and used their moodboards as inspiration for a logo.

Brainstorm feature ideas

The students began to note down ideas that might help their person to save money. They presented their ideas to the class and I asked everyone to write each presenter at least one post-it with a further suggestion. This was a successful collaborative session and the students came away with lots more ideas.

Their ideas for saving money included:

Swapping with people locally
Learning to cook your own meals, rather than ordering expensive takeaways
Comparing the best deals in shops
Sourcing local ingredients
Finding good makeup deals and beauty product recommendations
Getting credits or cashback for gaming

The students then prioritised up to 3 main ideas to use for their app.

Prototype

I ran the next session on information architecture. We looked at elements that are common to apps: hamburger menus, navigation, icons, buttons, log-in screens, etc. I showed some photographs from our walls at Lloyds showing how users click through screens and explained the importance of making a plan or wireframe before beginning any detailed design work.

With wireframes ready, the students then began to draw out their screens. We photographed each screen and uploaded them to Marvel. Marvel allows you to make a clickable prototype of your app from your hand-drawn screens. It proved a great way of creating a 'real' app without a tool imposing technical or coding constraints.

Test

The students' prototypes were ready for testing and feedback. We split into teams and ran mini tests on each others' work, asking open and closed questions. This was a really noisy, fun session.

Children this age seem very influenced by social media likes, numbers and scores. It's worth bearing this in mind when designing tests — scoring each other's apps out of 10 resulted in some upset designers. It's certainly one for me to iterate on for future!

Reflect

After testing, the students reflected on the project, looked at the feedback they had received and thought about how they could improve their app. The first time I ran the session the students did this independently, but it then occurred to me to run it like a sprint retrospective.

The following project I ran the reflect session like a retro and some interesting collective thinking came out. This helped me shape the following term and get the group working together as a team towards the same shared goals.

As a designer I take it for granted everyone can think through a basic design process. It's a simple skill that's worth sharing. Huge thanks to Design Club for setting up this brilliant initiative to bring design thinking to kids who might not otherwise get this experience. If you're interested in becoming a volunteer mentor, check them out.