Articles - Amy Hupe

Sorry seems to be the most overused word

2026-01-10T00:00:00Z

I’ve noticed a trend recently amongst marketing copywriters and I am – and I cannot stress this enough – NOT into it.

It goes like this: a brand posts a lengthy statement as an image on social media with an attention-grabbing title along the lines of “We’re sorry”, “An apology” or “Official apology statement”. The text underneath goes onto deliver a disingenuous apology for changing customers’ lives for the better. “We’re sorry”, they smarm, “for causing unforeseen levels of joy in your life”.

Sorry for being so delightful.

Sorry for being so good at our jobs.

The first one I saw, though I’m sure not the first time it was done, was from Bloom and Wild - a letterbox floristry service.

When I saw the post, titled “Official apology statement”, I began to read with intrigue. My experience of Bloom and Wild is that they are a thoughtful, human-centred brand. I wondered what they could have done wrong.

“In recent months”, the statement reads, “our gifts have caused unforeseen levels of delight”.

I screenshotted the post, shared it in a designers’ WhatsApp community I’m part of, and we collectively rolled our eyes at this flagrant act of deception. A dirty tactic, we all agreed.

Shortly after, I spotted a second post using the same trick. This one came, concerningly, from the Department for Education’s social media team.

The DfE’s statement apologises for “alarming amounts of unexpected free time” as a result of their best start free breakfast clubs and “an outrageous increase in household savings” following 30 hours of government-funded childcare.

After this, the posts started coming thick and fast, with everyone from ADP List, By Rotation, and even a sex toy manufacturer who was sorry that they made my boyfriend climax. (As an aside, said climax purported to have come from a lemon-shaped device with a very small hole in it - something I’m still trying to get my head around, anatomically speaking).

Frankly, I’ve had enough.

I’ve had enough of having my attention hijacked in bad faith.

I’ve had enough of this cheap misuse of the word sorry.

I’ve had enough of being shamelessly manipulated by organisations, many of whom do in fact have a lot to apologise for (inaccessible apps, poor user experience, grubby marketing tactics, to name a few).

An apology, when delivered genuinely, is an important moment in the brand-customer relationship. Companies inevitably mess up, and I’m left wondering what happens the next time one of the culprits I’ve mentioned here does so. Will a real apology be taken seriously, or even noticed, in a sea of false sorries designed to sell more products and services?

And mostly, I’ve had enough of the utter lack of originality from people whose job is supposed to be creative. Copycat cheap tricks and shameless bandwagon-hopping gives the whole discipline a bad name.

Shame on you. Do better.

Silver bullets

2024-07-10T00:00:00Z

Never in my life have I been so violently confronted by my brokenness than in the first year of separating from my husband in early 2023.

My body and mind, both of which had historically existed as a kind of backdrop to my life thus far, suddenly took centre stage as grotesque, malfunctioning vessels of pain.

I began looking for answers.

I scrolled through hours of TikTok, desperately browsing the remedies proffered by the algorithms, who somehow knew my marriage was over long before I’d packed up my things and moved out into that godforsaken airbnb with the leaky windows and the jar of pre-rolls I stocked it with to stop me from becoming an alcoholic.

It started with manifestation.

At a time where the chasm between where my life was and where I wanted it to be lay yawning and endless in front of me, in came the law of attraction.

All you had to do to manifest the life you wanted, I learned, was to completely change the way you thought and felt about the world. It really was that simple.

Fake it till you make it. Delulu is the solulu.

And so I said affirmations: “I am happy, I am loved, I am enough”. I said them 33 times in a row, 3 times a day, and I waited patiently for my life to change. I waited and I waited and I waited.

When nothing changed, a heavily-filtered 20-year-old by the name of Psychic Brianne diagnosed the stagnancy as a symptom of my low vibrational frequency. The fact that my life was falling apart was, she explained, neither here nor there. My circumstances were irrelevant, and nothing but a sorry excuse for languishing, and I needed to dial down my pessimism and tune into a frequency of abundance.

I put myself in nature.

To feel depressed sitting on a log by a lake, I discovered, was considered spiritually superior to feeling depressed on a sofa covered in Dorito dust.

Now it’s true that depression feels the same wherever you’re sat. Nevertheless, I suspected that the transformation I sought was not to be found rattling around with the stale pizza crusts in the box on my living room floor, listening to the couple next door arguing for the 5th time that week about whose turn it was to take the chihuahua outside to defecate.

When the present failed to deliver the enlightenment I needed, I decided instead to look to the future.

I booked readings with psychics and tarot readers.

I nodded eagerly at the bullseyes (yes I am grieving, how did you know that?!) and overlooked the inaccuracies (no, my father hasn’t passed over - at least not as of 10 minutes ago when he texted me asking for my Netflix login).

I took the crystals they gave me and put them in my pocket along with their prophecies: surprise but welcome pregnancies, reconciliation, and the sudden and unforeseen financial windfall that was due in October but so far remains lost in the post.

In the autumn, as I found myself still childless, alone and staring down the barrel of my overdraft, I discovered the sacred wisdom of gut health. Did you know that 95% of your serotonin is produced in your gut and not, as we’ve been tricked into believing, in your brain?

I hired a nutritional therapist.

I purged myself of alcohol, gluten, sugar, refined carbohydrates, additives and tuna (mercury, you see), and gorged instead on fermented things: kombucha, kefir and kimchi.

I sent weekly reports on my mood and my menstrual cycle and the condition of my hair and nails - these formerly unrelated things that, it transpired, held the key to my happiness all along. It worked extremely well until it didn’t. Somewhere around the 71st date and cacao energy ball I realised I was still quite depressed.

I threw myself into work.

I delivered inspirational conference talks about existential crisis and burnout, and everyone applauded my candour and strength. I woke up on the morning of one such talk in Manchester to discover I couldn’t breathe properly and went with my friend to the hospital where we watched make-up tutorials on her phone in between chest X-rays, blood tests and ECGs.

“You’re stressed” the doctor told me. “No shit” I laughed. He didn’t laugh back, but he gave me a packet of valium and god bless his soul for that.

I went to my therapist.

I told her I hated my life and I hated my home and I needed something to change. We talked about childhood wounds and she put me into a deep state of relaxation and asked me what I needed, and I said I needed to travel.

I went to Paris.

I drank wine in cafes on the shore of the Seine and gazed into windows of antiques shops and walked around art museums trying to feel something profound. I got a spontaneous tattoo from an artist called Sam who smoked a joint while he hand-poked a moon into my upper right arm. I’m now having it laser removed.

I ate a pastry and had a panic attack on the Rue des Petits Carreaux that felt artfully melancholy and chic in a way that a panic attack at home could never compete with. I took one of my valium and came home the next day.

In amongst all of this I saw friends and I dated and I cried and I broke things and broke hearts and broke and broke and broke.

I exercised and I drank too much and I stopped drinking and then started drinking in moderation.

I smoked weed and ate gummies and thought about taking mushrooms or ayahuasca and then remembered I’m terrified of hallucinogens.

I partied with people I didn’t like and failed to return the calls of people I did.

I meditated and did yoga and I re-read The Power of Now and I tried to be present and failed.

I thought about how small my problems were compared with all of the enormous problems in the world today and I felt guilty and remained depressed.

And at the end of all of it, I’m still no closer to the answer.

Socrates said that a wise man knows that he knows nothing, and I’m afraid he might have been right.

Not knowing is an inescapable part of the human experience. Your lack of answers will loom over your life like a spectre you cannot exorcise, and it will grow larger with every passing year you’re lucky enough to be here.

Our only job, it seems, is to go boldly into the wild unknown. Embrace the futility and find some meaning in amongst it. The mess, it seems, is where the living happens.

I don’t have a silver bullet and I’m going to be okay with that.

I really am.

Any day now.

Loss

2023-12-03T00:00:00Z

The law of conservation of energy says that, within a closed system, energy cannot be created or destroyed: only converted from one form of energy to another.

In 2023 - a year filled with personal loss - I’ve come to find some comfort in this fact.

If a relationship between 2 people is a closed system, then the law of conservation says that the energy that existed between them endures, even when the nature of their relationship changes.

Even when their lives move apart.

Even when they don’t speak anymore.

I think about the imprints that those I’ve loved have left on me: The memories now attached to that song; the phrases that now form part of my vocabulary; the random facts I now store in my mind about drugs, rats, and submarines.

Loss itself leaves imprints. It weaves its tendrils into your days and changes the way you move through the world. It loads you up with tripwires: heart-twisting reminders of what you once had.

When I was 18, my grandmother died. I was at university at the time and I came home to say goodbye. When I returned the following week I had a persistent thought:

“I don’t want you to be gone”.

I marvelled at the futility of that thought. I knew that thinking it wouldn’t bring her back, and so I waited and I waited and I waited for my brain to catch on and stop serving it up to me.

But it didn’t. It never has.

Nobody in my life died this year. But relationships changed and people left and I left and now what’s left is a lot of space.

In that space are conversations. One-way statements and unanswered questions:

“I miss you.”

“I’m so sorry.”

“Are you okay?”

And in the silence that follows I find myself thinking about the law of conservation of energy. Because what’s more comforting, in the face of loss, than the promise of endurance?

When grief threatens to overtake me I remind myself of this, because it helps to just know: To know that knowing someone changed me; That knowing me changed them.

Like two atoms that collided and altered their respective paths forever, the energetic exchange that occurs between two people changes the course of their lives thereafter.

Loss is never really the end, only a transmutation. A conversion of one thing to another.

And so, in this space of love and loss, I hold on to one bittersweet truth:

Whatever happens now, I will stay with you.

And you with me.

Always.

Where are we going?

2023-11-20T00:00:00Z

“Where are we going?” I ask you.

You don’t answer me.

I see the muscle in your cheek move as you clench your jaw, thinking, but your hands stay on the wheel and your eyes stay on the road. Silence.

You’re not OK and neither am I. No one in this car is OK.

“Maybe we should pull over and get some rest” I say, and I already know you won’t. You’ll keep driving and I will sit quietly in my growing unease as the road signs and the people and the buildings thin out, giving way to wilderness, darkness, horrors.

I wish I could take the wheel. Strap you into the passenger seat and drive us to sanctuary, play safe songs on the radio and listen to your breath growing deeper as you fall asleep.

You are two feet away from me but I can’t get to you and I wish I could.

Are you waiting for me in there or did you leave already? I wish I knew.

I wish I could switch off all the bad, yours and mine, replace it with blue skies and happy. I wish people could wish each other OK again. I wish they didn’t have to.

“Can you hear me?” I ask, and finally you look at me.

You look at me and look at me and look at me. Time stops. My heart hammers. Blood roars in my ears.

You hit the brakes; turn the car around.

“Where are we going?” I ask you.

You've broken your streak

2023-11-15T00:00:00Z

I am a perfectionist.

Contrary to popular belief, perfectionism is not just about striving, against all odds, to achieve perfection. What it often is - and certainly the way it manifests for me - is an overwhelming urge to disengage from anything I don’t believe I’m going to excel at.

I am also burnt out. Perfection feels unattainable to me at the moment, and this combination of burnout and perfectionism means I’m disengaging a lot right now.

Take this blog post. I’m writing this as part of an annual challenge called National Blog Posting Month (NaBloPoMo for short). Each year, I set myself the target of writing a blog post every week throughout the month of November. I’ve missed 3 days so far this year, and this fact is so demotivating to me that I almost gave up completely.

I can see this playing out in the various other endeavours I have going on right now, too: from the missed workout in my personal training program causing me to write off the whole week, to the Duolingo prompts I’m ignoring after breaking my daily French practice streak.

But giving in to perfectionism means missing out on the rich middle ground. Having already failed at writing a blog post every day this month, I’m faced with a choice. I can give up and write nothing for the rest of the month. Or I can dust myself off and write another 12. That’s 12 posts I wouldn’t have written otherwise. In any other circumstances I would consider that a really productive writing month.

The fact is that I am not capable of perfection right now. I can allow that to grind me to a halt, or I can grant myself compassion and build back up, allowing “good enough” to be good enough for the moment.

And that’s what I’m going to do. I’m going to step away from all or nothing, and choose to do something.

Notes from FFConf 2023

2023-11-10T00:00:00Z

Today I attended ffconf in Brighton for the second year running.

Here’s a rundown of the talks, and my reflections from the day.

Imposter syndrome, overworking and working environments by Amber Shand

We kicked the day off with a talk on dealing with imposter syndrome by Frontend Engineer, Amber Shand.

Amber discussed her own struggles with imposter syndrome when she moved into software engineering a few years ago. Despite impressive achievements, she found herself unable to internalise her own success, and couldn’t shake the feeling that she’d simply got lucky, or tricked her employer into hiring her.

I especially related to Amber’s tendencies towards harmful perfectionism and over-reliance on external validation to give her a sense of self-worth, and how this can lead to burnout.

However, for Amber, this is exacerbated by her own experience as a Black women working in the white-dominated tech industry. Growing up, she was told she’d have to work twice as hard as her white counterparts to get ahead.

Since one of the main characteristics of burnout is a decreased sense of accomplishment, I particularly liked Amber’s small wins tracker template - a free tool that helps people to record and acknowledge their achievements.

Amber’s talk finished with a call for self-compassion: a recognition that most of us are doing our best, and are deserving of recognition, rest and recovery. Amen to that!

The Expanding Dark Forest and Generative AI by Maggie Appleton

I really enjoyed hearing Maggie speak on this subject at Smashing Conf in Freiburg in September, so I was excited to see her on the lineup for today.

The dark forest theory of the web builds on the dark forest theory of the universe, which says that the universe is like a dark forest at night: it seems quiet and lifeless. And that’s because if you draw attention to yourself, you attract predators. Therefore, says dark forest theory, those of us who remain in the universe either just haven’t died yet, or have learned to shut up. We don’t yet know which group the human race sits in.

Maggie pointed out parallels with our behaviour on the web: the risk of attack when sharing content on social media means many of us move our content to semi-private spaces like newsletters or private discussion spaces to express our views safely.

She talked how the rapid increase in capabilities of generative AI agents to cheaply and convincingly churn out massive quantities of content in different formats on the web means we are about to “drown in a sea of questionable and mediocre information”.

Why does this matter?

First, AI generated content has a different connection to reality from humans. As humans, we read, compare and communicate information with a foundational experience of physical reality. Generative AI, by comparison, can learn from the information we provide it, but has no experience of physical reality to compare that with.

Generated content also doesn’t have any human relationship potential. If a piece of content written by a human resonates with its reader, the reader and author can discuss that content and engage and connect over it. AI does not have the capacity to create such relationships, although may be able to emulate those very convincingly.

This leaves us with a big question: how do we as humans prove our humanity on a web which will soon be filled with non-human agents?

And what happens when generative data becomes its own source? How quickly will the majority of information we see on the internet lose its connection to our physical reality.

Despite a thread of humour through Maggie’s talk, the ominousness of the implications of this impending reality was clear.

Returning to dark forest theory, Maggie predicted that one way we’ll cope with this is to retreat further into the cosy web. We’ll see more content put behind paywalls, being blocked from scraping or from API access, with less and less content living on the open web. This creates its own problems for people who research and write for a living.

Maggie’s talk concluded by posing a question: which possible futures would you like to make happen? Will we use this technology responsibly or for harm? Time will tell.

We need to talk about the front web by Angela Ricci

Angela spoke passionately about the importance of using traditional frontend technologies (HTML and CSS) if we want to preserve the open standards, the separation of content and style, and the semantics that ensure the web remains democratic and sustainable.

She discussed how our increasing focus on the developer experience over the user experience threatens these foundations.

The introduction of JavaScript frameworks like React have widened the gap between those building the web and those using it. Risks to the performance and accessibility of our applications are accepted in pursuit of a seemingly faster and simpler way to code.

Angela’s call to action was to return our attention to teaching and upholding traditional frontend development, to make sure we’re delivering great user experiences.

She explained the importance of preserving frontend development as a specialism in its own right, and ensuring we don’t lose it in the face of full stack. She also advocated for close collaboration between designers and developers to make sure we’re keeping a constant eye on our user experience.

I couldn’t agree more.

Future Proof CSS by Ire Aderinokun

Ire‘s talk explored the role of CSS and JavaScript in delivering accessible user experiences.

We often talk about HTML as being accessible by default but, she explained, we can easily undo this with incorrect use of CSS and JavaScript.

HTML provides semantic meaning to information. CSS is designed to add styling to that information. JavaScript is designed to provide additive functionality that can’t be achieved with HTML and CSS combined.

Like Angela, Ire advocates technologies in the way they were designed to be used. She went on to share a set of practical and specific dos and don’ts for achieving this when writing CSS and JavaScript.

As a non-developer, a lot of the detail here went beyond my understanding. However, the principles she shared matched those that I try to apply in my work design systems and content: simplicity, inclusivity and accessibility.

I find it really heartening to see developers like Ire and Angela so skilfully advocating these principles, in practical terms, to their communities of practice.

Ada Lovelace and the Very First Computer Program by Steve Goodwin

Developer Steve Goodwin delivered a lively post-lunch history lesson which was a welcome wake up after eating myself into a carb coma.

He introduced us to her text for the first ever computer program, how it was intended to work, and why it didn’t (there was a bug!) then recreated it in JavaScript.

Steven left us with this thought: given all Ada Lovelace achieved (from conceiving of variables and loops to foreseeing technologies like ChatGPT) would people be questioning her status as the first ever programmer proper if she were a man?

Embracing Neurodiversity in Tech: Building Empathy, Unveiling Strengths by Jonathan Fielding

Jonathan opened his talk with an overview of his personal journey and route to his diagnosis of autism.

He went on to share symptoms of 5 common neurodivergent conditions: ADHD, Autism, Dyscalculia, Dyslexia and Dyspraxia.

Jonathan talked us through the common stereotypes attached to each condition compared with the reality, and the strengths they can bring if properly supported at work.

He shared some principles for helping to create more empathetic working environments that helps a neurodiverse workforce to thrive, including:

making it safe to disclose neurodiversity
adapting hiring processes to support different preferences and requirements
using clear, concise communication
using person or identity-first language based on how someone refers to themselves

Jonathan has shared a helpful list of practical resources mentioned in his talk on his website.

Exploring the Potential of the Web Speech API in Karaoke

This is the second time I’ve seen this talk from Ana Rodrigues, the first being at this year’s State of the Browser. It was as joyful today as it was the first time.

A self-professed karaoke enthusiast, Ana has harnessed the web speech API to create a gamified karaoke tool that uses speech recognition to track your accuracy in singing a song’s lyrics.

Delivering a pitch perfect rendition of Twinkle Twinkle Little Star to showcase the tool, she perfectly demonstrated the possibility of incorporating fun and joy into our learning.

Entertainment as Code

Salma Alam-Naylor closed the day with her talk, Entertainment as code.

Leading on from Ana, this talk also concentrated on the intersection between fun and learning.

Salma, a livestreamer, frontend engineer and developer educator, promotes the idea that working in the open can help us humanise technology, and make it more accessible to learn.

It also helps to foster collaboration. Salma explained:

“Building stuff for your stream live on stream with viewers, for viewers is the best way to test functionality, get the QA going, crowd-source ideas, and make people feel part of that process, part of the product, and part of the stream.”

Yes, yes, yes!

That’s a wrap

A huge thank you to all of the speakers and to Remy and Julie and everyone else involved in organising ffconf.

It’s a wonderful conference with a clear emphasis on community, diversity and inclusivity. The result is an eclectic line up and an array of talks that validate, inspire and energise.

If you’ve never been, I can’t recommend it enough.

It's almost time for your trip

2023-11-08T00:00:00Z

“Pack your bags!” the email told me.

I looked at the boxes around me with a lump in my throat. Boxes of my clothes, books, the cafetiere we bought together (I didn’t take much but I couldn’t do without fresh coffee in the morning). I looked at our wedding photos on the bookshelf: I wouldn’t be packing those.

My cat walked in and wound herself around my legs, purring. “Do you know I’m leaving?” I thought. I bent down and scratched her neck and she bowed her head accordingly. “How quickly will you forget me?”

There were a lot of things I needed in that last week at home, as I prepared to move out of our marital home into an AirBnB round the corner, so we could trial separation: a hug; some reassurance; to know if I’d ever be coming back.

What I didn’t need, was a series of auto-generated emails from AirBnB designed, clearly, for someone going on holiday.

“Pack your bags!”

“Amy, it’s almost time for your trip!”

“Welcome to Hertfordshire!”

Each one of those exclamation marks was a gut punch, a grammatical knife in the heart, an absurd misjudgement of my situation that might have been funny if it hadn’t been so awful.

In Design for Real Life, Sara Wachter-Boettcher and Eric Meyer talk about stress cases: the moments that put our content and design choices to the test of real life.

“Real life is complicated […]. We might experience harassment or abuse, lose a loved one, become chronically ill, get into an accident, have a financial emergency, or simply be vulnerable for not fitting into society’s expectations.”

I have never felt this so acutely as in January, when I separated from my husband, my partner of 12 years. AirBnB was the tip of the iceberg.

I found myself bombarded with relentless adverts for ovulation kits from companies assuming we were trying to have a baby, opening emails from Mr and Mrs Smith advertising the best romantic getaways, and tortured by this-time-last-year memories from the photos app on my iPhone, featuring picture after picture of James smiling at me over dinner; cuddling reluctant cats; our wedding day.

My world was turning upside down and the algorithms hadn’t caught up, leaving me in a Twilight Zone of content that felt cruel, callous and mocking.

I tweeted about AirBnB’s emails and received an array of responses, ranging from “I’m so sorry you had to experience that” to “get a grip, snowflake”.

I thought about all the unpleasant reasons people might use AirBnB: funerals; visiting sick relatives; displacement from war, or climate change, or a house fire. I thought about how much salt had been rubbed into how many wounds, and wondered whether AirBnB thinks about this too.

Life is not one dimensional, and the experiences we design should reflect this.

It’s not a hard problem to solve.

Had AirBnB asked me about the nature of my trip, and designed for their many users who are not travelling for pleasure, I could have been spared that additional pain.

But they didn’t, they haven’t, and so I wasn’t.

And so here’s my plea for more thoughtful content:

Content that accommodates the complexity of life.

Content that goes out of its way to avoid harm.

Content that is, above all, kind.

Systems of Harm: 3 principles for creating socially responsible design systems

2023-11-07T00:00:00Z

_This post is based on a talk I gave at this year's Smashing Conf in Freiburg, I'll add a link to the talk once it's available.

When we talk about the benefits of design systems, we tend to repeat 3 promises.

efficiency: a design system will reduce waste in your design and development processes, and help you go faster
consistency: a design system will help you standardise your digital experiences
scale: a design system will help you scale your design decisions across your product landscape

But here’s the thing we rarely ever say: None of this is inherently valuable.

Now you might be wondering why I, a design systems consultant, am saying this. But the important bit is this word inherent. It doesn’t mean these things can’t be massively beneficial, but it’s worth being clear that:

efficiency is only valuable, if it helps us move faster towards meaningful outcomes for the people using our products and services
consistency is only valuable if we standardise things to a good level of quality. There’s nothing good about consistently crap
scaling things is only valuable if they’re actually worth reproducing

And although this might sound obvious, I say it because I’ve noticed a shift in the conversation around design systems lately that concerns me.

If we agree that there’s no inherent value in the added capability promised by design systems - efficiency, consistency, and the ability to scale - then the value must lie in what we do with it.

But this introduces a problem. Because if we can use our design systems to speed up meaningful work, standardise things to a high quality, and scale the things we actually want to reproduce - then the reverse is also true.

It means that we can also use our design systems to speed up problematic work, standardise things to a poor quality, and scale things we don’t want to reproduce.

In other words, not only is this work not inherently valuable, it’s also not inherently harmless.

Design systems are scaling machines

To understand how design systems present a risk, let’s look at how they work, at the most basic level.

We create design systems by curating and distributing a collection of components, patterns and content. And as product teams start using the system to build websites and applications, things start to get scaled across our digital landscapes and even beyond, as they start to influence offline channels. But it’s important to say again that the mechanisms our design systems use to scale have no inherent value unless they’re things we actually want to scale.

And what if they’re not?

What happens if those components are inaccessible?

What of those patterns we’ve created are discriminatory?

And what if the content we’ve documented and disseminated is exclusionary?

What happens, in these situations, is we create a system of harm.

We industrialise discrimination and set up a production line which allows us to ship exclusion to the people using our products: quickly, consistently, and at scale.

So a few months ago I decided to make a podcast about this.

Systems of harm: the podcast

I wanted to explore the ways in which design systems can perpetuate harm, and how we can mitigate that. The podcast is called Systems of harm, and if you’ll indulge me in a shameless plug - it’s available now on all the usual podcasting platforms.

Throughout the series, I spoke to 6 amazing guests, who I’ll introduce you to as we go through this post. I deliberately sought out people who knew about design systems, but who also had personal experience of marginalisation and discrimination.

And what I really wanted to understand by talking to all of them was, if design systems can become these vectors for harm, then what can we do to mitigate that?

Through those conversations, I identified 3 principles. They are:

To start with the teams who make design systems
To centre stress cases
To embrace complexity

1. Start with the teams who make design systems

Starting with the teams who make design systems.

Of all of the micro and macro decisions we make when instating design systems, the makeup of the team we hire to set up and maintain them seems to be the area that gets least attention.

We seem to assume that if individuals have the right practical skills and experience then we should unquestioningly hire them.

But that means that we’re often not thinking consciously about the perspectives and the biases that we feed into our design systems.

Let’s consider bias.

Every one of us makes thousands of big and small decisions every day.

Even as I’m writing now I’m making decisions about how to punctuate this post, when to take a sip of my tea, how to sit comfortably, and so on.

If I thought consciously about every one of those decisions I wouldn’t be able to function.

So to cope with that, our brains make unconscious decisions on autopilot, based on what they’ve learned from our past experiences.

And these unconscious decisions are our cognitive bias.

In the first episode of Systems of Harm I spoke to David Dylan Thomas, who if you don’t know him, has literally written a book on this subject of cognitive bias.

David explains that we are not going to be able to switch off this autopilot, and nor should we try to because we would just become completely inefficient.

He says that what we have to do instead is ask ourselves which of these biases that we have are harmful, and what are we going to do to counteract them and mitigate against the harm they might cause?

And one way we can do this is by counterbalancing them with other perspectives.

But this is challenging right now because, if you hadn’t noticed, the tech industry has a diversity problem.

Our society and therefore our organisations - even the more inclusive ones - are rife with inequality.

It’s why we have a persistent gender pay gap. It’s why diversity within our industry continues to be seriously lacking.

It’s why in my one design system team, as a woman, I was outnumbered 4 times over by white men called Matt. Now it’s really important to say that diversity isn’t inclusivity.

Diversity is just variety, and aiming to recruit a diverse team without thinking about inclusivity is a recipe for disaster.

But if we don’t have or can’t sustain a diverse team, it’s a good indicator that it’s not inclusive.

And this becomes a self-perpetuating problem because it informs our biases about what tech teams should look like.

David talked about this when I spoke to him. He said, when I say “web developer” you picture a skinny white guy. It’s not because you think people who aren’t skinny white guys can’t be developers, it’s just pattern recognition. But when it’s unconscious, it becomes dangerous to hiring practices.

When the teams who create and maintain our design systems are biased towards a narrow set of experiences, that bias propagates throughout all the layers of the people who interact with it.

It impacts contributors, people who use the design systems to make products and services, the people who work in our wider organisation, and the people who use the products and services our design systems are used to create.

The knowledge and experiences that we feed into our design systems travel down through these layers and start reinforcing those biases out in the world.

Now you might be thinking “can’t we just do user research with a representative group of people?”.

But without having diverse teams building our products, issues will slip through the cracks,

You can’t simply retrofit inclusion into your product. A lack of inclusion is not a bug that can be fixed in QA.

User research can help us to spot some issues, but by then we’ve already fed the system with so much of our own biases that it’s going to be unrealistic to make fundamental changes to what we’ve designed.

It’s really important that we address bias at the source by making sure that the team who’s building the design system can do so with different kinds of knowledge.

And I like to think of a concept here that I heard about from Kim Crayton, an Anti-racist Economist who does a lot of anti-racism work and education.

She talks about 2 types of knowledge:

Explicit knowledge - the kind of knowledge that’s easy to articulate, codify and store, and can easily be transferred to another person
Tacit knowledge - knowledge developed through a person’s lived experience, and is difficult to transfer to another person by writing it down and verbalising it

It’s this second kind of knowledge that allows us to really propagate our own experiences of biases through our design systems - and this is what determines the inclusivity of our products.

A strong example of this is from my guest in episode 4 of Systems of Harm, a design systems designer and now manager, Fred Warburton.

A few years ago, Fred was diagnosed at a young age with a degenerative eye condition called retinitis pigmentosa, and he was told he was losing his sight.

I worked with Fred at Babylon Health, and in that time I watched him lead one of the most incredible pieces of organisation-wide accessibility advocacy and education work I’ve ever seen.

In his episode, Fred and I talked about the impact of having a disabled person leading this work.

He said “My situation made it more tangible for people. Because it’s far more difficult to relate to some of this accessibility advocacy stuff if you don’t have an inclusive workforce that includes disabled people.”

I had a similar conversation with Imran Afzal in episode 5, principal designer on the design system team at co-op digital.

Imran and I talked about design systems and racism, and the impact of having all-white teams designing products and services.

He told me about a study in 2020 that found that 5 out of 6 leading speech recognition systems were better at recognising white people than people of any other ethnic background.

I’m going to assume that no one working on that software set out to exclude anyone, but this is just what happens when a team that isn’t diverse builds systems.

And this doesn’t just impact the people who end up using our products. It also affects people in the team itself.

What really struck me from talking to Imran is the amount of mental capacity he has to dedicate to thinking about what it means for him to be the only person of colour in an otherwise all-white design systems team.

He said that at some point he came to this realisation that he was the only person of colour in his team - in many teams he’s worked in - and that the effect of this builds up over time. He feels like he has to work harder than his white colleagues to prove himself and to win people over.

Imagine if he was free to just put that energy into his work?

If we’re not building our design system in an inclusive environment that supports participation from a diverse set of perspectives - we can’t design inclusive experiences.

And if we haven’t experienced exclusion, it’s very hard to mitigate it because we’re much less likely to spot it until it’s too late.

I am not a diversity, equity and inclusion expert and I’m not going to pretend to be, but I can see the impact.

I can see the correlation between the attention paid to inclusion in teams and organisations and the inclusivity of the experiences they create.

2. Centre stress cases

The term ‘stress cases’ was coined by Eric Meyer and Sara Wachter-Boettcher in their book Design for Real Life, which I really recommend if you haven’t read it.

The book says: “Real life is complicated […]. We might experience harassment or abuse, lose a loved one, become chronically ill, get into an accident, have a financial emergency, or simply be vulnerable for not fitting into society’s expectations.”

Historically, our industry has called these edge cases because they only affect a small number of users.

In the book, Sara and Eric propose redefining these situations not as edge cases, but as stress cases: the moments that put our design and content choices to the test of real life.

Instead of treating stressful situations as fringe concerns, we should move them to the centre and start with the most vulnerable people, and then work our way outwards.

Let’s look at a specific example of this. It comes from one of the book’s co-author, Eric.

A few years ago Facebook launched a feature called ‘your year in review’.

It showed the user the most important moment of their year - defined as whichever photo they’d got the most engagement on.

The photos were accompanied by colourful graphics and tonally celebratory content.

This feature was designed with a single context in mind: The person whose most liked photo was of a happy memory. But unfortunately, the feature made headlines for all the wrong reasons.

Facebook received multiple complaints from users who experienced the feature as something much more painful, and much more complex.

One of these people was Eric.

Eric’s daughter had died earlier that year, and he’d shared the news on the social media platform.

For pretty obvious reasons, the post had received a lot of comments and engagement, and therefore it shot straight into the top moment of his year in review.

Eric said, heartbreakingly, “yes - my year looked like that, true enough. My year looked like the now-absent face of my little girl.”

While I’m sure that lots of people probably enjoyed the feature, we should ask ourselves whether that enjoyment is worth the pain of those who experienced it like this. (It’s not.) This is why centering stress cases is important.

Another example of why this matters comes from my guests on episode 3 of Systems of Harm, Laura Parker.

Laura is a UX writing and content design consultant, and she struggles with a condition called Dyscalculia.

Dyscalculia is a learning difference that affects an estimated one in twenty adults in the UK. It’s characterised by a persistent difficulty with understanding numbers.

Laura talked about how it affects her everyday life.

We can help people with low numeracy and dyscalculia by providing alternative formats to information presented as numbers, tables and graphs.

Laura and a team of other designers working in government have led a huge piece of research and have published a blog post about their work on the GOV.UK design notes blog](https://designnotes.blog.gov.uk/2022/11/28/designing-for-people-with-dyscalculia-and-low-numeracy/).

Laura explained that while we often think of numbers as neutral, almost clinical things, they’re actually far from it.

She explained to me that for her, numbers are emotional.

She told me to think about the importance of statistics when it comes to things like COVID-19, climate change and inflation. These are things that affect all of us in a big way, and it can be really alienating if you struggle with numbers and you can’t interpret what you’re being told.

Design systems have an opportunity here to guide the way teams format numbers, and convey numerical data using things like tables and graphs.

These considerations are relatively easy to incorporate thoughtfully into our design systems, but we normally don’t, because we often don’t think about people who struggle with numbers as part of our audience - we think of them as edge cases. And it’s time to change that.

We have to start thinking first about those who our design choices are most likely to harm. It takes more time and effort to do this, but if we want to build inclusive design systems, we have to start thinking about those who are excluded, who are at the margins, and the unintended outcomes of our decisions.

3. Embrace complexity

This is a really interesting concept for me because I have very much sold my services over the years on the basis of being really good at making things simple.

In fact, if you look at the homepage of this website, you’ll notice that I reference my efforts to champion simplicity and inclusion.

This wording gives me a particular cognitive dissonance now because making the podcast has left me with a big question: Are simplicity and inclusion, in fact, incompatible?

As design system makers, we offer teams a simple way to create user experiences, by giving them reusable building blocks and guidelines to follow when they’re developing them.

But user experience is always an intersection of the products we create, and that product user’s identity, and their circumstances.

And the thing about identity and circumstances is that they are always inherently complicated.

Let’s look at an example of a common form field that many design systems offer guidance on: the gender field.

What we see over and over again are these same buckets:

Male (male first, naturally)
Female
Other

And it’s that ‘other’ that I find so problematic here.

A quick count through Wikipedia’s page on gender currently reveals 101 genders. Medicine net lists 72. Another site I looked at listed 112. The exact number isn’t what’s important here.

What is important is that this does not allow any of the users who do not identify as a male or female to identify themselves correctly in our services.

And besides the fact that we actually normally don’t really need to ask this question at all, and besides the fact that asking it like this means we’re collecting data in a way that reinforces a gender binary, there is a human impact to this.

Luke Murphy, my podcast guest from episode 2, is a design advocate at Zeroheight, and is trans non-binary.

They told me that when they encounter a gender field with only male and female options, they feel “unseen”. Not a nice feeling, but a common one.

It’s very easy to think of these decisions as relatively small and inconsequential, but when you consider how many times a trans or non-binary user might encounter this pattern every day, you can quickly imagine the cumulative harm this does to a person.

And this is just one of the ways that these arbitrary choices our design systems define can scale to cause harm.

Let’s think about another one: How we ask users for their name.

Name fields are something most design systems include, but when I think about how lack of diversity in our industry as a whole really shows up in our work - this is one of the first things I think about.

Just to illustrate the scale of our bias when it comes to names, Patrick McKenzie put together a list of 40 false beliefs about names.

When these false assumptions inform our design systems, and our patterns for asking people for names, we start to exclude people.

Sheryl Cababa, my guest in the final episode of Systems of Harm, had a personal example of this.

Sheryl is an author, a lecturer and chief design officer at substantial. She’s written a book called Closing the Loop, which teaches systems thinking for designers.

She told me that her children have a double-barrelled surname, but that the two parts of their name are separated by a space, not a hyphen. And she said that there has never been a single healthcare system or service that can handle that.

Every time Sheryl or her husband engage with a service that’s stored their children’s names, they have to try inputting various permutations of the name to land on the way that the system has stored it.

And Sheryl’s experience is in no way unusual.

There are hundreds and hundreds and hundreds of examples of this happening all over the internet. People are told, over and over again, that their name is not valid because it doesn’t confirm to a set of unaccommodating validation rules.

When I was collecting these examples from Twitter - I noticed a repeating comment people used over and over and over when they shared these screenshots:

This is the story of my life.

When this happens to people again and again and again, we’re giving them a clear message: this is not for you.

We become authors in that story of exclusion.

I’ve only touched on two examples here: gender and names, but the reality is that our design systems cover much more.

And when we don’t design for the full human spectrum of identities and characteristics and circumstances and experiences that our design system needs to serve, we don’t just exclude people, we erase them.

We have to be willing to engage with the full complexity of the human experience in order to build design systems that can effectively start to counter systemic harm.

We have a duty to build inclusive design systems

Thinking about how our design systems perpetuate harm is not a distraction from the work, it is the work.

Building an inclusive design system will make things harder and slow you down. There are no silver bullets here because part of building an inclusive system is reducing our speed to understand our impact.

Nothing I’ve shared today is a quick fix, but it’s a direction of travel.

It’s important that we balance the conversation around design systems and spend at least as much time talking about human impact as we do about the mechanics of our design systems.

We can choose to create inclusive design systems that put people at their heart. Even if it slows us down, we must do it anyway.

My process when starting a new job

2023-11-03T00:00:00Z

As an independent consultant, I find myself in the position of “new girl” more than most. As a result, I’ve learned a few things about how to hit the ground running.

Managing information overload

A universal feature of starting any new job is a tidal wave of information to absorb: names to learn; obscure project names to remember; tools to get familiar with; the list goes on.

Even those of us blessed with exceptional memories are going to find it challenging to hold this amount of new data in our heads, without other important things being pushed out.

To manage this, I like to keep a rolling notes document for myself, organised into the following headings:

Questions

Here’s where I list out any questions I have along the way.

My questions usually start off quite high level. Things like:

What is the company’s 5 year strategy?
How many people work here?
What are the aims of this project?

Over time, questions get more specific:

Who manages email content?
What is your design system contribution review process?
Who designed this flow in Figma?

I record the answer to each question in a different colour and in bold underneath the question in case I need to revisit them at a later date. Answered questions move to the bottom of the list, and new questions get added at the top.

I usually keep this document private (for reasons explained below), but sometimes I’ll share the questions and answers with whoever I’m reporting to, to check I’ve got accurate information.

Observations

This is where I keep notes of anything important that I’m noticing.

This often includes things about ways of working, apparent priorities, people’s preferred communication methods, and any discrepancies I notice in the information I’ve been given.

The last point is important to cover, because it can easily become a source of stress. By recording it as an observation, I’ve got it on my radar, but I’m approaching it as a neutral observation, rather than a clear problem.

Opportunities

Sometimes clients will give me a very specific list of things to do, but more often than not it’s up to me to determine how I can best fulfill the objectives of our engagement.

I use the opportunities section of my notes to record ideas, as they come to me, about what actions I think would be helpful for me to take and why.

I’ll try to share these ideas with my client early on, to check if it matches up with their expectations.

Glossary

Even clients with the clearest communication practices tend to use:

acronyms
arbitrary product names
software I haven’t encountered before

I use this section to note down any terms I don’t understand, and add their definitions as I discover them. This provides a useful reference for me in those early weeks, before I know things by heart.

People to meet

In this section I create a table with columns for:

name
role
project(s)
date and time booked
notes

I tend to start this off by asking whoever I’m reporting to to give me a list of people they think I should meet with, and then through those conversations the list usually gets longer.

Meeting notes

Here’s where I record fairly detailed notes from the introductory discussions I have. I review these notes regularly, looking for themes and adding points to my questions, observations and opportunities sections as needed.

Finding small wins

I’m a firm believer that the early days at a new company are best spent listening, learning and absorbing information. This ensures that any decisions I make or work I do are grounded in context, and means I’ll be able to move quicker and more confidently when I’m ready to start delivering.

With that said, seeking ways to deliver small amounts of value in those early weeks goes a long way to building a relationship with my client and generating goodwill.

I tend to pick on things that are:

ring fenced and don’t involve changing or critiquing someone else’s work (unless explicitly asked)
quick to deliver and don’t take too much focus away from my initial learning

Examples of small, early contributions I’ve made in the past are:

setting up a weekly crit for the client team to get support with content design
creating a style guide where there wasn’t one to document grammatical and phrasing conventions
running a lunch and learn session on inclusive design systems, based on a conference talk I’d done previously

Managing stress

Starting a new job is exciting, but usually generates a fair amount of stress.

The sheer amount of new information to process, coupled with the unrealistic expectations I often have of myself to start delivering value right away, means it’s easy to feel overwhelmed.

Stepping up my self-care during this phase - getting enough sleep, exercising, drinking lots of water, blocking out time for lunch and for focus time - tends to keep me level enough to manage it.

One of the most important lessons I’ve learned is not to sit on things. When I first started contracting, I had a harmfully perfectionist notion that I should have all the answers, and be able to do whatever a client asked me - but that’s neither realistic or sustainable.

A job description and a statement of work are, to some degree, just theoretical wishlists. It’s only once I’m actually working with them that I can assess the dependencies of what I’ve been asked to do, and whether or not it’s achievable given the reality of the situation. Good clients, and indeed employers, will understand this and work with me to negotiate any adjustments we might need to make.

If something is unclear to me or if I think I’m being asked to do more than I have capacity for, I will raise it early and often with my client.

Not only does this help to build trust because they know I’m being honest and transparent, it ensures I’m holding the client accountable for making sure I have what I need to do the job they’ve hired me to do.

Regular communication

The final and perhaps most important part of my new-job process is overcommunication.

Some organisations are very proactive with their onboarding, but for people embedded in a company, the needs of new starters can often fall by the wayside in the face of other priorities.

For this reason, I communicate what I’m doing as widely and frequently as I possibly can.

I address blockers early and often, and I make sure that everyone knows what I’m working on to avoid any misunderstandings or nasty surprises.

What have I missed?

This is just works for me, and I’m refining this process as I go along.

If you’ve got any tips for new starters that I haven’t covered here, I’d love to hear them.

You can get in touch with me on:

Burnout diaries

2023-11-02T00:00:00Z

I am burnt out.

It’s 5:30pm and I’m just sitting down to write today’s NaBloPoMo post, and the only thing I can think to write about is that I am exhausted.

I stopped working full-time in April and I’m just beginning again now. A foreplanned 2-month break turned into 6, and could easily stretch to the end of the year if not for my declining bank balance and a nagging sense that I ought to keep the lights on in my broken brain by putting it to good use.

I am burnt out. A series of personal and global crises have as good as ground me to a halt, and the many conversations that followed my recent talk: “It all means nothing in the end” have confirmed to me that I’m far from the only one.

I drift through my days like a sad ghost, alternating between caffeine-induced pep and a few too many lie-downs for a 34 year old woman.

Burnout is a funny thing I haven’t danced with before. I have the sensation of sitting in a dark room, knowing that the old me is on the other side of the door, but not knowing when she’ll come back again.

I sit down to write and the words won’t come out.

I try to read and the information won’t go beyond my eyeballs.

Sending an email requires a level of effort akin to pushing a ten tonne boulder up a hill.

A stack of unpaid parking tickets sits in the corner, reminding me of the times that I was so fog-headed I forgot to pay the fee, and of the fact that my brain is now too pea-soupy to read the letters and understand the numbers and pay the fines.

I crave human connection and so I surround myself with people, only to find myself exhausted in their company. I missed the closing keynotes at the last two conferences I went to so I could go back to my hotel room and nap.

Time off stopped helping a while ago. In the absence of work, my days filled up with overthinking: an agitated, restless energy that left me too wired to sleep and too tired to do much else.

When I sat down to work today I caught a flicker of the old me: focused, organised, productive. “I really miss you”, I thought. “I really need you to come back now”, I told her, and then she was gone again.

She will come back.

I am burnt out, but I’m fighting like hell to get back to myself.

And one day soon, I’ll be home.

National Blog Posting Month 2023: Day 1

2023-11-01T00:00:00Z

For the third year running, I’m taking part in National Blog Posting Month (NaBloPoMo for short).

I’ll be publishing a new blog post every weekday throughout November.

What is NaBloPoMo?

According to this post by Michelle Weber, NaBloPoMo was started by an American blogger called Eden Kennedy, in response to National Novel Writing Month (NaNoWriMo).

Participants write a blog post every day throughout November, to break away from perfectionist ideals that might otherwise prevent them from sharing their work.

Since “Perfectionist ideals” is my middle name, so the scheme has always served as a good way for me to push through my writer’s block and put some new ideas out into the world.

Where this year’s NaBloPoMo finds me

Having not learned from the last 2 years’ efforts, I have once again failed to get ahead with my writing, or even compile a list of topic ideas.

I’d actually go as far as to say that this year will be my most disorganised yet, but that’s OK.

I’ve gone through a series of big life changes this year, and so I’m interested to see how that shows up in my writing and - at the risk of sounding completely cheesy - to meet this new version of myself in the pages that ensue.

What I’ll be writing about

Previous NaBloPoMo efforts have included a mixture of personal and work-related posts, and this year will be no exception.

Work wise, I’ll be sharing thoughts on design systems, content design, and perhaps a bit about my experience of working as a contractor - particularly in 2023 where I’ve experienced the longest client drought of my consulting career so far.

Let’s begin.

Are you taking part in NaBloPoMo? I’d love to read your posts if you are.

Or, if there’s something you’d like me to write about, let me know—I need all the inspiration I can get.

Get in touch on:

Burn baby burnout

2023-09-29T00:00:00Z

This blog post is based on a talk I did at Converge Manchester 2023 - I will add a link to the talk when it's ready. In the meantime, you may want to check out Lauren Loprete's fantastic talk on design systems and burnout from Clarity, which is part of what inspired this one.

A few weeks ago at Smashing Conf, I saw a designer called Christine Vallaure give a talk about responsive design. In the talk, she introduced a German concept that I’d never heard before: “Sysiphusarbeit” - meaning “the work of Sysiphus”.

Now if you’re not familiar with the story of Sysiphus, I’ll explain. In Greek mythology, Sysiphus was a king who was punished in the afterlife for his deceitfulness. His eternal punishment was to roll a large boulder up a hill, only to have it roll back down every time he reached the top. This task was repetitive and futile, a never-ending and ultimately meaningless effort.

And let me tell you, when I heard Christine explain this, my head snapped up so fast I almost got whiplash. Sysiphusarbeit, I realised, as I sat there in that conference hall surrounded by 300 Germans, was the best description I’d ever heard of a career in design systems.

Now, I’ll admit that I am currently giving this talk to you from the depths of burnout. It’s been a pretty trying year for reasons I won’t go into here, but it’s not the first time I’ve had these thoughts about design systems work.

In the past, I’ve likened those of us working on design systems to salmon: swimming upstream against a powerful current of opposing forces that seem determined to drag us back towards our start point.

I know I’m not the only one who feels this way. When I talk to friends and colleagues working on design systems, I hear one reflection over and over again: This shit is exhausting.

And recently I’ve started to reflect on why this is. What is it about design systems work in particular that leaves so many of us feeling burnt out? Is it the context we’re working in? Is it the nature of the work? Or is it something inherent in those of us who find ourselves innately drawn to roles that demand systems thinking?

And more importantly, is there anything we can do about it? Because the bottom line is, as much as I feel exhausted by it, I actually like this work. Even though it frustrates me and exhausts me, there’s a reason I keep doing it beyond being a glutton for punishment. I just wish it was easier. And I think that’s probably true for a lot of us.

So in this post, I’m going to share some reflections about design systems and burnout, and some ideas about what might make things better.

What is burnout?

I want to start off with a definition of burnout to make sure we’re all on the same page.

The technical term was first coined by a psychologist called Herbert Freudenberger in 1975. It was characterised by 3 components:

Emotional exhaustion - the fatigue that comes from caring too much, for too long
Depersonalization - the depletion of empathy, caring and compassion
Decreased sense of accomplishment - an unconquerable sense of futility: feeling that nothing you do makes any difference

And when it comes to design systems, I think it’s the third component that most commonly leads us to burnout.

Why do design systems cause burnout?

Broadly speaking, I think there are 5 reasons design systems can contribute to a decreased sense of accomplishment, leading to burnout.

They are that:

We value outputs over outcomes
Design systems are seen as static products, not living services
Design system value is hard to quantify
We hear more about our failures than our successes
Our lens is too wide

So let’s look at each of those in more detail, starting with the first.

1. We overvalue outputs over outcomes

As we’ve started to converge on a definition of design system, we’ve started to treat them like a checklist of things to deliver.

I see an overemphasis on artefacts and deliverables: things you can point at, at the expense of what they really are: large scale organisational change programmes.

One common way I see this manifesting is in a phenomenon I see in design system teams over and over. Something I like to call: the post-launch crash.

Pre-launch design systems teams are typically galvanised toward a shared and specific aim: launch the design system.

During this phase, the team has its collective eyes on a collective prize, and any and all work, discussions, disagreements, stressors and detours happen in the warm glow of a very bright light at the end of the tunnel.

However hard things are now, we think, it will all be worth it in the end.

I’ve lived through this myself.

Here’s a picture of me and the team at GDS the day we launched the GOV.UK Design System.

I’m not exaggerating when I say this was probably the best day of my career. 18 months of research, design, redesign, documenting, testing, iterating, and failing and eventually passing our funding review, all came to fruition on this day. The relief was palpable and only surpassed by the pride I felt at what we’d managed to achieve.

Twitter went off. Design and tech heroes of mine were sharing our work and praising the thing we’d created. Any exhaustion I felt in that moment was swept away in a flurry of excitement, and recognition and glory. It was, indeed, all worth it in the end.

But here’s the thing: what I know now, what’s so obvious with hindsight, is that this wasn’t the end. It was only the beginning. The beginning of something that I now know is endless, and relentless, and hard.

That light at the end of the tunnel turned out to be nothing more than the entrance to another, and for many design system teams, it’s the only one they ever get.

Giddy from the euphoric moment of going live, bolstered by a sea of congratulations and accolades, design system teams breeze confidently into post-launch land, ready to bask in the glory of their efforts, as teams begin to adopt the system and incorporate it into their day-to-day work.

But it’s at this point, as teams start to kick the proverbial tires of what we’ve done and stakeholders start to ask “what’s next?”, that we often come to realise that the people in our organisation have fundamentally misunderstood the nature of what we’re offering.

Demand surges, we are bombarded with reports of the gaps in our system, and stakeholders start to question whether our team even needs to exist anymore, now that we’ve delivered the product they were expecting.

And this links to the second reason that design systems cause burnout.

2. Design systems are seen as static products, not living services

While awareness of design systems has matured significantly over the past decade or so, a continued sticking point seems to be around organisations understanding the need for ongoing investment.

This is absolutely not helped by external agencies and consultants - and I do my very best not to be one of them - who promise to “come in and build you a design system”.

As an aside, if you are a consultant or you work for an agency who does this, please, on behalf of in-house teams across the land - stop.

It’s like promising to build a national rail service, without giving thought to who’s going to drive the trains once the tracks are in place.

Design systems are a service that come with ongoing operational costs, but the idea that design systems are single-point deliverables is a pervasive myth that won’t die.

And while I know I’m preaching to the converted here, I think there are 2 aspects to this that contribute to burnout.

The first is that product teams using the design system will often place unrealistic demands on a design system team to provide everything that they need from day one.

As design system makers and maintainers, we know that our systems will grow and evolve over time. The gap between what teams need and what we’re able to offer will shrink as the system matures - that rather than solving every need from day one, our task is to reduce duplication of effort as time goes on.

But to people who’ve never worked on a design system, this isn’t always as obvious as it is to us. Rather than viewing the design system as a living entity with ever increasing returns, they focus on the gaps. This leaves us facing a firehose of demand that can make us feel as though nothing we’re doing is ever enough. I’m going to talk about that more in a few minutes.

The second problem this misconception causes is that it can create a threat to our funding. Stakeholders who misunderstand the evolutionary nature of design systems can assume that once we’ve shipped version 1, we’re no longer needed.

Budget holders who don’t understand the need for us to provide ongoing support, to add to and update the system, and to run processes like contribution are quick to assume they can reallocate our time to work they consider pressing.

No matter how many times we explain how things really work, this misunderstanding seems persistent, and it leaves us in the position of constantly having to defend ourselves, and prove our worth.

The constant need to explain why what we’re doing is valuable is exhausting, and really feeds into that feeling of futility - that nothing we do is ever enough.

It’s also really challenging.

3. Design system value is hard to quantify

Even in organisations with the most supportive leadership, it’s not enough to just say “trust us, we are delivering value”. Eventually, someone is going to say: Prove it.

And despite a wealth of literature, conference talks, panel discussions and relentless discussion on how to effectively measure the impact of design systems, most of us still find this inherently hard to do.

I think there’s a few reasons for this.

For starters, while it’s much easier to gather qualitative feedback on the value of our design systems - like glowing testimonials and anecdotal benefits from people who like the design system - it’s often not really what the business wants from us.

Because, what that stakeholder really means when they say “prove it”, is “Prove it with numbers”. “If it’s money you want, then give me something I can attach a clear cost to.”

When it comes to gathering quantitative data, there are 2 areas we can look at, and both are problematic.

The first is to look at our impact on the products the design system is used to create:

Have we helped to increase conversion?
Has our customer satisfaction score improved?
Has engagement gone up?
Are product updates happening more often now?

This presents a real challenge for design system teams, because our impact on the end-user experience is always diluted and mixed in with other factors, like:

product teams’ delivery processes
the efficacy of other systems and resources teams uses
the health of design and developer operations in the organisation

Pin-pointing - to any degree of accuracy - a design system’s impact on quantitative product metrics is an unwinnable game, but is often one we’re asked to play anyway.

Our second option is to look at metadata about the design system itself. Things like:

the number of teams adopting the design system
number of components used
% of products built using the design system

While these things are definitely easier to measure, they are only meaningful if our stakeholders fundamentally believe in the value of the system already. Nobody wants the whole company to be using something they don’t see the point in.

This is not an easy problem to solve. To my knowledge, no one has found a universal formula for persuading stakeholders to keep the money coming in.

The best we can do is understand what our organisation cares about, and build up a picture that taps into that. But it’s not much fun is it?

Making the case for continued funding is difficult, tiresome, and probably not why most of us got into this work - but it’s inescapable.

I think this is worth acknowledging because it all contributes again to this decreased sense of accomplishment.

This can make it feel like we’re speaking a different language to our stakeholders and users. We might know that what we’re doing is helping. We might know that we’re working as hard as we can. But if we can’t tell that story in the way people want to hear it, we’re told it isn’t good enough.

4. We hear more about our failures than our success

I often hear people describing design systems work as thankless, and I definitely understand where that comes from.

As design system maintainers, we are providing a service to the organisation. And, as with any service, people are way more likely to tell us when we’re getting it wrong, than when we’re getting it right.

This is completely normal, but it somehow feels more personal when the customers you’re serving are also your colleagues. I think that subconsciously we expect that fellow designers and developers would take the time out to give us good feedback. The fact that they know, on some level, what it’s like to do our jobs, makes their silence on our successes feel inhumane.

But here’s where I’m going to say something a bit strange.

You know how they say “No news is good news”? If we apply this to design systems, we can assume that no feedback means everything is working as expected and our users are satisfied?

Well I also think, in the case of design systems, that bad news is also good news.

Since the vast majority of design systems are not mandated, that means we’re reliant on teams in the organisation choosing to use them, over alternatives like creating their own product-level solutions, or in the worst-cases, setting up their own design systems.

So when teams take the time to tell us that:

“This header component only has space for 4 nav items but we have 5”
“Your focus state doesn’t work properly in Safari”
“I tried to contribute a pattern but no one has come back to me”
“We use a different theme on this part of the site and your tokens don’t support it”

I see it as a sign that they’re engaged and, on some level, invested in its success. Or at least, rationally, I do that.

But however our logical brains might process this as a positive indication, we are not robots. We are human beings, doing our best, and this doesn’t feel nice, and it creates an unfortunate paradox.

As engagement, buy-in and usage of the system increases, so too does the amount of criticism - constructive or otherwise - we receive. That means that the more impactful our design system is, the more we’re going to hear about its shortcomings.

Our success is going to make us feel like we’re failing, by design.

As well as being kind of demoralising, it also makes it really hard to prioritise. When goodwill and trust is our currency for encouraging adoption, it makes it really hard to put these issues on ice.

And this leads me into the fifth and final reason that I think design systems cause burnout.

5. We care too much about too much

As systems thinkers, we are hard-wired to keep our eye on the big picture, and all of the problems it contains.

This creates a couple of issues that can significantly erode our sense of progress.

Firstly, we understand that our design systems are made up of lots of interconnected parts, and that even seemingly small decisions we make could have consequences for its overall health.

We know that design systems are multipliers. A single design choice that we make can quickly get scaled across multiple products, affecting hundreds, thousands, or even millions of product users.

And if we get it wrong, then rolling back on that choice creates widespread disruption to adopting teams.

In my experience, this tends to make us cautious and fairly risk-averse, meaning we often want to take our time to build confidence in our decisions before making updates.

And that’s not a bad thing. To a degree, design systems teams need to move at a slower speed than product teams, because of the scope and scale of their work.

But it can go too far. I’ve worked in teams where we’ve as good as ground to a halt for fear of making a misstep. When we see every move as having the potential to cause far-reaching disaster, we stop making progress.

Secondly, being aware of all the problems means being aware of all the problems you’re not solving.

The breadth of the work we’re doing means there’s pretty much an endless supply of issues to fix and improvements to make.

And I do think that as systems thinkers we are especially empathetic, and especially sensitive to the pain of saying no, even though we know it’s necessary.

Even if we know we cannot be everything to everyone, I think that we’re kind of hard-wired to want to.

In fact, I’d say it’s the very qualities that make us good at our jobs - our empathy, our problem-solving skills, and our ability to hold the whole picture in mind - that make us so vulnerable to burnout.

And in the same vein, I think that the reasons we’re drawn to this work in the first place - the desire to help people, to have an impact, to make a difference - that can end up driving us out of it.

It makes me think of this meme created by Adam JK:

So. On that cheery note, let’s talk about what to do…

Can we put the fire out?

So is there anything to be done, or should we all just quit right now?

Well, you could quit.

I want to validate that it’s OK to walk away from this work, for a time or forever. Design systems, contrary to how we sometimes feel about them, are not life. You existed before you worked on design systems and you will continue to exist after them.

With all of that said, for many of us, the benefits of this work will still outweigh its drawbacks.

So, if we do decide to stay, how can we better protect ourselves about burnout?

At the start of this post I said that I thought the key to design systems burnout lay in that third component defined by Freudenberger, that it was rooted in this decreased sense of accomplishment?

Given that, I think this is also where the solutions lie.

To protect against burnout, we have to cultivate a sense of accomplishment

To really counter the risk of burnout, we have to cultivate a sense of accomplishment.

So how do we do that?

I have a few suggestions. 4, to be exact.

1. Tell a better story

The first is that we have to start telling better, more accurate stories about design systems and what they offer.

This is especially important at the pitching stage, when we’re waxing lyrical about how much money our systems will save the business when we’re no longer throwing the company’s money down the drain rebuilding buttons.

We need to make it super clear that design systems won’t eradicate duplication of effort, but that they will gradually reduce duplicated effort over time so long as the business continues to invest in them.

We need to over-communicate about the realities of this work with our users and our stakeholders, to take pressure of that launch moment and to convey that design systems are a continuous practice, not a set of artefacts to deliver.

This might be a harder sell than an over-simplified sales pitch that says design systems will save 25% of a company’s design and development costs, but it will put us in a much better position to show off the value we do deliver.

2. Radically descope

We have to accept that we cannot be everything to everyone, and setting overly-ambitious goals is only going to contribute to a feeling of failure.

How much we have capacity to concentrate on at any one time depends heavily on the size of our team and the maturity of our design system, but when goal-setting, it’s a good idea to think about:

which users we most need to support
which products we most need to serve
which platforms we most need to accommodate
what we can’t commit to

And if I’ve learned one thing in the past 7 years working in this space, it’s that it’s always less than you think.

Setting achievable goals means you actually get to feel a sense of achievement, rather than thinking about all the things you didn’t manage to do.

3. Celebrate success often

We can all help to cultivate a culture of appreciation within our teams by acknowledging each other’s wins and calling out good work.

It’s an oldie but a goodie, but making sure there’s always space in team retros to talk about what went well is so important. And when you’re in a retro, contribute to this.

It’s so easy to go into the room with a list of things you want to improve, but it’s equally important to acknowledge what you’re getting right.

And I’m a big fan of the rule, whenever you ship something: cake. Here’s an example of a showstopper I made for the GOV.UK Design System when we shipped a set of accessibility changes on our 1 year launch anniversary.

This might seem frivolous, but it really does pay to take the time to mark your successes, and to look in the rear view mirror from time to time and say “yeah, we did a good job”.

And don’t just keep it to yourself. Spam Slack with your design system updates. Do a weekly round-up of everything you’ve done that week. Bask in the dopamine hits as people react with emojis and a torrent of cut and pasted “well done”s.

It may all sound like I’m being a little flippant here, but celebrating success reminds us to have fun in our work, and I’ve found that its effect is cumulative. The more you get into the habit of reminding yourself that you’re doing a good job, the more you’ll start to realise that you are.

4. Reconnect to your purpose

Design systems have taken on a life of their own. Once a means to an end, they have become the end itself. Organisations no longer talk in general terms about wanting to improve efficiency or make their products more consistent, they simply say “we need a design system”.

But design systems are not one thing and - no matter how many consultants like me might try to sell you an out-of-the-box approach - there’s no template solution.

Approaching design systems in a formulaic way leaves us with a checklist of artefacts to deliver, and means we lose sight of our purpose.

But to really feel that sense of accomplishment that’s so important for counteracting burnout, we need to reconnect to our specific why, both on a personal level and a team level.

Individually, why did you start working in this space in the first place? What itches did it let you scratch? Personally, I care about creating more inclusive experiences and helping people to connect with each other, and design systems are my current best way of doing that. When I feel burnt out, reminding myself of the decisions I’ve made and the work I’ve done to this end, along the way, helps me to realise that I am making a difference.

And what motivates you and your colleagues as a collective? What gets you all fired up? What kind of work gives you meaning? What unites you as a team and gives you shared meaning?

And this is key.

I believe that design systems work is really effective when it comes to helping us to feel part of something bigger than ourselves. The reach we have weighs heavy sometimes, but it also helps us to see the things that connect us.

Know you’re not alone

Burnout is a hard place to be, and if you’re working on design systems, then the unfortunate truth is that the career path you’ve chosen and the type of person you are means you’re probably at a greater risk of burning out than the average.

But one thing you are not, is alone in that.

We are in this together, and I know that when I’m struggling with burnout, a huge part of what pulls me back out of it is the community around me.

As systems thinkers, I believe that we are intrinsically smart, capable, empathetic and compassionate people, and our community is one of the strongest tools in our arsenal.

We are collectively a force to be reckoned with.

You’ve got this, and we’ve got you.

Documenting design systems: Reflections from this month's design systems open space

2023-01-19T00:00:00Z

Every month I run a free Zoom session called Design Systems Open Space.

It’s for people who work on design systems to come together, meet each other, and talk about anything we’re grappling with.

Each month we focus on a different topic - and January’s open space covered my all-time favourite design systems subject: documentation.

Here are my reflections from the session.

Design systems documentation is a team sport

The very first question that came up was one of ownership: whose responsibility is it to write documentation?

With content designers and tech writers still a rare breed in design systems teams, many lack a dedicated person to take this on. But is that a bad thing?

Whilst I absolutely advocate having a content specialist working on your docs, good documentation is never the work of one person. Designers, engineers, researchers and product managers have valuable and varied perspectives to guide the information we provide to our users.

So the task is not simply to hire a dedicated documentation person, but rather to empower multi-disciplinary team members and contributors to document their own work effectively and collaboratively. In my experience, this is best achieved through the provision of standard templates and formats, skills training, peer review, and testing.

One attendee spoke about their efforts to create standard, reusable formats to support people writing documentation. Whilst this had helped to some extent, they admitted that the templates could sometimes be overly constraining. And, in my view, this is where we need to get meta.

If we’re providing reusable templates for documentation, it’s helpful to consider them as design patterns. There will be cases for contextual adaptation, so we need to document our documentation in such a way that makes clear this is OK - that the template is a guide, not a law.

Maintainability is important to consider - and often overlooked

More than one attendee shared experiences of investing significant time and energy into documentation that ended up unread, outdated and - in one instance - never published.

This had left the authors feeling understandably frustrated and guilty. And it’s a common scenario.

When creating documentation - and indeed any aspect of a design system - it’s important to be realistic about what you and your team can maintain. Tempting as it is to go straight in with comprehensive solutions seen in other, mature design systems, it’s much better to start with minimum viable documentation and build on it over time, as team size and capacity increases.

Good documentation meets people where they are

I was pleased when the discussion veered onto my current documentation obsession du jour: managing documentation across multiple tools.

While the majority of us still take a fairly unimaginative approach to the placement of our documentation - with the bulk of it still living in a dedicated docs site - there is an emerging shift towards documentation that meets people where they are.

For designers, for example, this might mean surfacing guidance alongside components in a tool like Figma, and developers might be best served in something like Storybook or GitHub.

The big challenge we have today is how to achieve this in a way that’s maintainable. Publishing documentation to multiple places, with no system for managing it centrally, creates a significant overhead that most design system teams simply do not have the capacity to sustain.

I’ve written about this problem previously:

To my knowledge, answers to this problem remain incomplete and thin on the ground, so I was excited when one participant shared that they’d been working on a custom tool that might be able to support this. I’ll be keeping a close eye on their progress.

Measuring the performance of our documentation

Another oft-overlooked aspect of design systems documentation is how to measure its performance over time. Whilst many of us strive to track generic system metrics like component usage, contribution, and user satisfaction - only a minority seem to actively monitor the efficacy of documentation.

One attendee recommended looking to support requests as a source of insight into how far our documentation is meeting people’s needs. It reminded me of a system we established during my time on the GOV.UK Design System team, where we’d tag our docs-related support tickets by issue type (for example: couldn’t find; doesn’t exist; didn’t understand), and topic (for example: component; contribution; installation).

We’d track the quantity of different query types and keywords, and review each month to find areas for improvement.

This helped us prioritise improvements to our documentation based on user needs, and use “reduced support requests” as a metric to help us measure the efficacy of any changes we made.

Design systems documentation is absolutely critical - and hard to get right

I was heartened that no one questioned the need for good documentation during the discussion (I’m sad to say that it does happen).

But this topic, more than any other that we’ve discussed in the open space sessions, seems to present real challenges.

One participant remarked “Documentation gives me the most imposter syndrome of any of these topics.”

And this, I think, is because good documentation is hard to get right. It’s easy to look at unread documentation and assume that our design system’s users have a generic aversion to reading - that they just want to grab components and go, ungratefully eschewing all of our carefully-crafted guidance.

More often than not, it’s because our documentation is failing to give them what they need. When we provide people with too much or too little information, fail to address their particular context or skillset, or our documentation is poorly named and signposted, they’ll naturally circumvent our guidance in favour of approaching us directly.

In short, they’ll take the path of least resistance.

Learn how to write design systems documentation that works

If you’ll forgive me a little plug, this is where I think I can help. I’ve spent the past 7 years helping teams create and refine design systems documentation that people can find, understand and use.

I understand the challenges people face when writing documentation, and I truly believe that learning to do it well is the most transformative step we can take to improve our design systems.

So in a few weeks’ time I’m running 2 half-day training sessions on writing design systems documentation:

There are just a few spots left now, and I’d love to have you along if you can make it.

If you have any questions, you can get in touch on Twitter, Mastodon, or email me on amy.l.hupe@gmail.com.

Show me the money: Reflections on this month's open space on getting investment for design systems

2022-12-16T00:00:00Z

For those of you who’ve been fortunate enough to miss my incessant social media posting on the matter, I run a monthly Zoom session called Design Systems Open Space.

It’s aimed at people working on design systems, and provides a chance to get together, meet others in the space, and share our lessons and struggles.

Each session focuses on a different topic - voted for by attendees - and this month we talked about “getting investment into design systems and keeping it”.

Here’s a write up of the discussion.

Communicate value with data

One attendee - whose role means they work with lots of design system teams - remarked on a correlation they’ve noticed between design systems defunding and a lack of performance measurement.

Design system success metrics are notoriously complex, imperfect, and indicative at best. But failing to track anything at all puts teams at a far greater risk of having their budget scaled down or withdrawn.

Attendees shared different methods and metrics for tracking performance. Quantitative data like product coverage, number of teams adopting, change in speed to production, and team satisfaction scores were among those mentioned.

But just as important, one attendee commented, is the need for storytelling: contextualising data to make it meaningful to our organisations’ leadership.

The consensus on when to start gathering data was “as soon as you can".

Setting a benchmark is important for tracking progress, and the sooner that benchmark is set, the more stark any gains will appear.

Design system goals must map to business goals

We all agreed that tying design system performance to business objectives was imperative. That’s not to say that all design system success metrics need to directly support business goals, but we’re likely to find ourselves in trouble if none of them do.

It’s all well and good tracking common system metrics like component coverage and adoption - but unless budget holders understand the business impact on system growth, this information won’t necessarily translate into investment.

Acquisitions and mergers provide fertile ground for design system investment

Several attendees talked about their experiences of working on design systems during company acquisitions and mergers.

Perhaps unsurprisingly, post-merger requirements for brand unification, technology consolidation, and content migration, seems to significantly increase the perceived strategic importance of design systems.

Acquisitions and mergers create a good climate for design system teams to communicate value to stakeholders in terms of what they consider relevant and important. Providing building blocks to support change at pace and scale is a compelling argument for a company whose digital landscape is entering a period of flux.

Whilst it’s wise and pragmatic for design system teams to capitalise on these opportunities, it’s important to articulate the ongoing value a system can provide and the dependencies on it. Not doing so can put design system teams at risk of cutbacks once the post-merger dust has settled.

What to do when design system funding gets cut

Many attendees bore the scars of design system defunding. In some cases, budgets were cut after a system was built, because budget holders didn’t understand the need for ongoing investment.

More commonly, design systems’ budgets are viewed as an easy target for cutbacks because the impact is often indirect, and takes longer to emerge than in other areas.

So what can we do when this happens?

A theme in the responses was to lean on community. Two participants shared stories about support they’d received from system advocates within their organisations: design, engineering and product leads who had spoken up and evangelised their work when funding was called into question.

I shared an example from a previous design system I’d worked on, in which our team was indefinitely moved onto another piece of work. During that time, we took a hard line about providing no support to our community and carrying out no maintenance on the design system, and we asked adopting teams to report any impact back to us.

Although this strategy was emotionally-challenging for us and frustrating for our users, it allowed us to gather clear evidence on the need for sustained investment, which was eventually restored.

Does framing design systems as products encourage investment?

Towards the end of the session, we ventured into a well-trodden debate about whether design systems should be thought of as products. Some participants felt that framing them as such would help organisations’ leaders to understand the need for sustained investment.

Personally, while I think that the product-framing is certainly an improvement upon the notion of design systems as finite projects, I don’t think it’s quite right.

My experience has been that the term “product” comes with a weight of expectation that’s not always conducive to sensible systems work. That design systems sit a layer away from “end users”, and have to take into account the needs of multiple product teams, means that they move at a necessarily slower pace than individual products.

This doesn’t always sit well with the agile delivery aspirations that many leaders see as synonymous with product thinking and operations.

In summary…

Communicating value in a way that elicits funding is an ongoing struggle for those of us working on design systems.

“Trust us” is rarely a persuasive strategy for budget holders: sooner or later we’re going to have to demonstrate return on investment. Collecting data on areas of impact can help with this - and it’s never too early to start.

Even after initial investment, design system teams remain vulnerable to cutbacks.

Advocacy from allies in our organisations can prove essential in helping us to weather periods of uncertainty, so it’s important to invest time and effort in relationships and community-building.

So you might say - if you were totally basic and unimaginitive - that when it comes down to it, design systems are ultimately about people.

NaBloPoMo 2022 wrapped

2022-11-30T00:00:00Z

National Blog Posting Month - affectionately known as NaBloPoMo - is a challenge in which participants write a blog post every day throughout November.

The idea is to help bloggers develop a consistent writing habit, and break away from perfectionist ideals that might otherwise prevent them from sharing their work.

I've just taken part for the second year running - here's a quick summary of what I wrote, and some reflections.

The blog posts

Like last year, I gave myself weekends off writing, and set myself a goal of writing every weekday.

I'm pleased to say that I hit my target, and am rounding off the month having written and published 22 new blog posts, including this one.

The winners

Based on the amount of feedback, likes, shares and (whispers) clicks each post got, the one that people liked best by some margin was So, are you thinking of having kids?. I'm happy about this, since it was probably the scariest and most vulnerable piece of writing I've ever shared.

Lessons learned

Preparation is key. I did some work to get ahead last year with a list of topic ideas and drafts, and boy oh boy does it make a difference. Coming up with a new idea and starting from scratch every day is not for the faint-hearted.
I'm still a raging perfectionist. My perfectionist brain is very all or nothing, so I knew if I missed a day I would just give up altogether. I also didn't cut myself much slack in terms of quality. I put a lot of effort into most of the posts I wrote which leaves me happy with my output, but very, very tired.
It's been good to reboot my writing practice. Once again, I really enjoyed NaBloPoMo and I’ll do it again next year. (I’m also really glad it’s over for this year!) Doing the challenge has reaffirmed for me that I can and should write more in general. I often wait until I’ve got a really solid idea, and spend ages on it, and there’s something nice about just saying “I’m going to publish something today” and going for it.
No writer is an island. Writing (nearly) every day for a whole month is quite an undertaking, and I'm not sure I could do it without the support and encouragement of others. So a huge thank you to everyone who's taken the time to feedback on and share my posts - it really has made all the difference. Also a big thank you to Steve Messer for setting up a Slack support group for some of us taking part. Having a little accountability / cheerleading group really helped.

That's a wrap

I've loved writing every day, and I'm ready for a little pause now to let some new ideas bubble up and marinate.

This challenge is, for me, a brilliant reminder of the importance of balance.

It's wonderful to prove to myself that I can write consistently, when I put my mind to it. And I'm just as grateful for the opportunity now to slow down and invest time in some posts that need a bit more consideration.

Until next year, I bid my daily writing practice adieu.

I hope you've enjoyed reading along.

A new barrier to communicating about design systems

2022-11-29T00:00:00Z

I wrote down a quote recently from Hayley Hughes’ talk at Clarity 2022.

She said “when you work on design systems, there are people that think they know what you do, but they have no clue.”

What’s struck me about this is that it highlights an important change in the design systems communications directive in the past few years.

If we go back 5 to 10 years, an important task for those of us pitching and working on design systems was to explain what a design system was, to budget-holders who had never heard of them.

Nowadays, it’s much more common that those budget-holders we’re communicating with have encountered a design system before - even if only from a distance. Design systems have made their way firmly into our corporate vernacular.

And while this is certainly a positive thing in many ways, it puts us in a riskier position when it comes to communicating our work.

Why? Because the only thing more dangerous to a design system’s funding case than a lack of understanding of what it is, is a false understanding of what it is. Particularly when that false understanding is often built on a collection of common myths that have elbowed their way, without nuance, into the psyche of our organisations’ leaders. Myths like:

“Design systems help teams go 10 times faster!”
“We don’t need a design system team, we can use that Nathan Curtis federated model and get contributors to make everything”
“Design systems will completely eradicate duplication of effort!”
“Design systems bake accessibility into components, so we no longer need to test our products - hurrah!”

All of this is to say that we are no longer starting from square one, we are starting from square -10.

We’ve gone from having to explain what a design system is, to now having to help people unlearn common misconceptions about design systems, and re-educate them.

Nevertheless, we persist.

We document our design systems - why don't we systematise our documentation?

2022-11-28T00:00:00Z

Working - as I do - at the intersection of content design and design systems, I’m often thinking about ways of improving design system documentation.

And in this quest, I come up against one question time and time again:

Why don’t we approach guidance and documentation as modular parts of our systems, the way we do with everything else?

Let me explain.

Design systems documentation as reusable modules

Let’s say that we want to add some guidance to our design system that tells people to write calls to action in sentence case, not title case.

For example: “Buy this book” not “Buy This Book”.

In our documentation website alone, this guidance may be relevant to our:

button documentation
guidance on links
content A-Z styleguide

And beyond our documentation site, we might also want to surface it in places like:

developer documentation in GitHub or Storybook
design libraries in Figma or Sketch

At the moment, we can solve this problem by repeating the guidance in all those places, which creates a maintenance burden and risks them falling out of sync.

Given that content professionals are a rarity in design system teams, and that documentation is often treated as lower priority than other system parts, it’s important that we keep our maintenance overhead as low as possible.

Alternatively, we can create the guidance in one of those places and link to it. This is more maintainable, but forces people to go to another place to get all the information they need to complete their task.

When we think about how much overlapping guidance design systems typically include, we can see that this solution doesn’t scale far without creating a clunky, disruptive reading experience for those using our systems.

Neither of these options is ideal, and it strikes me as especially nonsensical that we don’t have a better solution, since this is a perfect example of the problem a design system aims to solve.

Design systems seek to increase efficiency via common solutions that can be maintained centrally and reused in multiple places. So why don’t we apply this thinking to our documentation?

Documentation has variants, too

As well as documentation that’s relevant in multiple places, we may also want to create more than one version of a piece guidance based on the contexts in which it appears.

Building on the previous example, we may want to simply tell people to write calls to action in sentence case, without providing rationale.

But in some cases - for instance in our content styleguide - we may want to explain that sentence case is proven to be more readable most of the time, and link to research to support this.

So already, we have 2 variants:

rule
rule with rationale

Where are we today?

Right now, we don’t really have an agreed upon solution to this problem.

Part of that, I think, is that we don’t widely acknowledge that it is a problem to solve, in the first place.

It’s complicated further by the fact that the mix of tools that we use to document our design systems. It’s typical for most teams to use at least 3 of the following:

a custom built documentation site
an off-the-shelf documentation tool, like Zeroheight
Figma
Sketch
GitHub
Storybook

Any viable solution will need to accommodate documentation modules that can be shared not just in multiple contexts, but also across multiple tools with little standardisation across APIs.

A few weeks ago, my colleague Heydon and I talked to Chase McCoy, who has also described this problem in his article Design systems as knowledge graphs.

He, along with his team at Stripe, are running some experiments in this area.

I’ll be watching their efforts with interest, though I think Chase would concede that they haven’t yet unearthed any kind of silver bullet.

Update on 20 Feb: Do you want to work on this?

My colleague Heydon Pickering and I have been exploring this space for a while now, and are currently nearing the end of our contracts with Springer Nature.

From 1 April 2023, we'll be available for new client engagements, and we'd love to work on this problem with an organisation who's interested in taking an ambitious approach to its design system documentation.

Between us, Heydon and I have 15 years' experience working on documentation - with a large chunk of that focused on design systems. We've worked with clients including:

While Heydon's documentation skillset comprises frontend design and development, and accessibility, mine concentrates on design systems strategy and management, user centred design, and content design. Between us, we have a broad set of tools and experience to tackle this problem.

If that’s you, email me at amy.l.hupe@gmail.com, or contact me on Twitter or Mastodon.

So, are you thinking of having kids?

2022-11-25T00:00:00Z

I imagine a hierarchy of the painful scenarios around the issue of having children, and I consider where it’s fair to place myself, and I always conclude it’s somewhere near the bottom.

I can’t compare the pain of not knowing if you want a baby to the pain of knowing you want a baby and not being able to have one.

I can’t speak on behalf of the second group. I've been close to lots of people in it, and I ache for them, and I can’t imagine it.

I am in the first group.

I can tell you that not knowing if you want a baby, for me, is painful, confusing, and shameful, and that society makes it worse. It’s a different sort of pain, but it’s pain nonetheless.

I am 33. Like many women my age I was told the story all my life about the switch that just flips inside you when you want a baby. I was 27 when I got married and that’s the first time I really started worrying about the switch.

As I approached 30, the switch remained unflipped, and I started to panic. My sisters both had their first babies by the age of 30. 30 was supposed to be the “have it all figured out” age. Why was my switch not flipping? Was there something wrong with my switch?

When I approached the conversation with friends and family, the tale of the switch was replaced with something new. Having been conditioned all my life to expect to just wake up one day wanting a baby, I was now told “you’re never really ready”.

But I'm the wrong sort of "not ready". I'm the kind of not ready that isn't ready to let go of the need to feel more ready than this, and isn't ready to give up either.

I’ve become an expert in spotting the signs of other people's pregnancies: The sudden onset of absence from social media. The excuses for not coming to social events. The clear, ambiguous drinks when they do - something chosen to look like a gin and tonic which could just as easily be a sparkling water. The out-of-the-blue invitation to catch up, with partners in tow. The hum of silences, overflowing with the unspoken thing that’s about to be spoken. The cue you give them. “So what have you been up to?” or “Can I get you a drink?” is all they need. The briefest exchange of glances before one of them says “Well, actually…” and the announcement that follows.

And I smile and I hug them and I tell them how excited I am for them. I ask them when they found out; how they’ve been feeling. James squeezes my hand. And as soon as I can I go somewhere quiet, and I sob and I hate myself for it.

I’m 33 and I don’t know if I want children.

I don’t know if I’ll get to decide, or if time will decide for me, or if something I don’t know about already has.

Being undecided sounds like a neutral thing, but it’s not. Not for me, anyway.

For me, ambivalence is a torturous, insidious thing wrapped in layers of fear, and self-doubt, and shame, and warring parts of me that paddle frantically in opposite directions to save themselves as the lifeboat - me - slowly sinks.

I feel like I’ve failed. I’ve failed to develop that maternal instinct that’s expected of women and I’ve failed to commit to being childfree by choice.

And I’m stuck. I feel like an insect in amber, not quite sure how I crawled in here, and now suspended in indecision as the resin solidifies around me. I feel like I’ll never get out.

Most of the time the idea of having children terrifies me.

I imagine it, and what it would take, and what it might cost me, and I tell myself (as I always tell myself) that I'm just less capable, and weaker, and worse than everyone else, and that I couldn't cut it.

That's settled, then.

But then...

Just once in a while I’m hit with a vision out of the blue, of me, holding a baby to my chest, and breathing in her smell. And in those moments, just once in a while, I want it so badly that it knocks the wind out of me.

And then it’s gone again.

And I’m left wondering if she’s in the life that’s waiting for me, or the one I’ll never have.

Should design systems include problematic components and patterns?

2022-11-24T00:00:00Z

Every now and then I run into the question of whether design systems should document and distribute components and patterns that we don’t really want system users to use. These are sometimes referred to as “anti-patterns”.

A few years ago, I was involved in one such debate about whether to include a Select component in the GOV.UK Design System.

(As spoilered by the link I just included, we decided we would.)

One the one hand, selects - or dropdowns - come with a suite of well-documented usability issues. You can find out more about these in:

On the other hand, selects were and still are incredibly common on the web as a whole, and in government services in particular.

We didn’t want to encourage usage of selects, but given their prevalence, it didn't feel right to omit them completely.

I don’t think there’s a one-size-fits-all solution to this problem, but I have found some common considerations.

How much is the component or pattern being used?

If only few teams in our organisation are using a component or pattern, then including it could turn a small problem into a much bigger one.

But if the component or pattern is already being widely used and we omit it, we automatically add “inconsistent implementation” to the list of existing problems it carries.

I don’t believe there’s a quantifiable tipping point at which something becomes worth including, but this question should form part of a system team’s discussion.

How often are people looking for it in our design system?

As well as observing how often a component or pattern is being used, we should also take stock of how often we’re being asked for it.

Are people searching for it in our design systems? Are we getting requests to add it to our backlog?

This will help us to spot a potential uptick (or fall) in demand and factor that in, too.

Is there an opportunity to make it less bad?

In many cases, there are opportunities to remediate some of the problems inherent with certain components and patterns.

With a select, for example, we can at the very least offer guidance on:

writing a clear label
front-loading the copy for options, in case they get cropped
ordering options
when to pre-select an option, and when not to

Including bad practice in design systems gives us an opportunity to call it out

In an ideal world, we’d eradicate bad practice from our systems and then our products entirely.

In the real world, we don’t always share the same understanding or opinion of what constitutes bad practice.

Design systems provide an opportunity for alignment.

By surfacing problematic components and patterns in our design systems, we create a place for ourselves to explicitly state:

that they’re problematic
why they’re problematic
what to use instead

In summary

I don’t subscribe to the idea of purely “descriptive” design systems - ones that simply systematise existing UI, regardless of its usability and quality.

Design systems have a responsibility to mitigate - and certainly to not proliferate - bad practice.

However, design systems must also acknowledge the reality of the context in which they sit.

If problematic components and patterns are being widely used, then our design systems can play an important role in discouraging further uptake, raising awareness of their issues, and offering risk-mitigation advice and alternatives to consider.

As with most design system concerns, there’s no blanket solution here. But I hope these considerations will help you the next time you’re faced with this question.

Down with design systems dogma

2022-11-23T00:00:00Z

As the design systems space has matured, our understanding of what they entail and how to approach the work has naturally converged.

We now have a wealth of collective knowledge and experience that we can use to inform our practice - and that’s a very positive thing.

But convergence can cross over into rigidity. And when contextual experience informs general recommendations, we can find ourselves facing counter-productive dogmatism.

“There’s a right way to do design systems, and we’re doing it wrong”

In 2019, Jina wrote:

“The word “design” and “system” used in combination together literally just means to systemize your design... And so if for you that means a Sketch UI Library, then you do you!”

She asked us to focus less on deliverables, and more on the practice of doing the work.

But from where I’m standing, that message still hasn’t taken hold. Everyday I talk to organisations who tell me things like:

“Our designers think their Figma library is the whole design system - we need to focus on the codebase”
“Our product teams keep building from scratch instead of using core components”
“I can’t get my company to see the point in design tokens”
“The developers want to version components individually - but that’s not a system!”

And while the specific problem they’re describing changes - these statements all boil down to the same sentiment: There’s a right way to do this work, and we’re doing it wrong.

This, in my view, is burning us out.

Design systems dogmatism leads to burn out

I have this mental image sometimes of those of us working on design systems as salmon, swimming upstream, in pursuit of what we consider the ideal design system.

The current around us represents our unique context: the specific communities our systems are serving, our organisation’s needs, and the barriers and challenges we face along the way.

And in our pursuit of that one specific vision, we often find ourselves swimming against it.

When this happens, we often find ourselves focusing on the current, and the friction we’re facing.

We find ourselves making no progress, and we start to conclude that “it must be us, or the context, or the people around us”.

The nuance, complexity and variability of the contexts that we’re building our design systems in, is infinite and ever-changing.

But dogmatism in our field is forcing us to try and solve these problems in one way - and we can’t let it.

You are not a salmon

Instead of continuing to swim upstream and stopping only now and then to notice how exhausted we are, I believe that we can give ourselves permission to do something different.

So - just in case you need this reminder - remember that it’s OK to swim with the current sometimes.

It’s OK to choose context over convention: to look at that design systems vision that our industry dogmatises, and to decide to go after something else that works better for you.

Single source of whatever: reflections from this month's design systems open space

2022-11-22T00:00:00Z

Periodically and inconsistently - but roughly once a month - I run a free Zoom session called Design Systems Open Space.

It’s a chance for folks who work on design systems to gather together, meet each other, and share challenges we’re facing.

Each open space focuses on a different topic - and we used this month’s session to explore the question that just won’t die: What should be your design system’s source of truth?

Here are my reflections from the session

This was actually interesting

Despite my trepidation (read: anticipatory fatigue) I was surprised to find myself amidst a genuinely interesting and thought-provoking discussion. We explored aspects of this question that I haven’t encountered before - I learned a lot from the conversation and come away with new insights and ideas.

Single source of “it depends”

I was heartened to discover a clear point of unanimity: it’s basically impossible to define a universal single source of truth for design systems.

As one participant put it, we’re really dealing in a single source of “it depends”.

The source of truth for maintainers might be different from the source of truth for users

One of the variables impacting our source of truth is whose perspective we’re approaching the question from.

For system maintainers and contributors, we’re likely thinking about where we go to store, document and maintain the system.

For people using the system, it makes more sense to consider the place they go to reference and use the system.

These places can be different and, indeed, they often are.

Design the system to meet people where they are

Even within a team of maintainers, skillsets and tooling may mean create different access points to the design system they look after. Whilst we can probably expect developers to work on the codebase, content designers might be updating documentation via a content management system, and designers might be defining components in Figma. Whilst the system itself may have a canonical source, these access points are, for all intents and purposes, the main source of truth from the point of view of the individual maintainer.

And even if we do succeed in establishing one destination from which our systems team can maintain it, access points for our users are likely to be far more varied. The most important thing, one attendee posited, was to design around user tasks or “job stories”. Rather than forcing everyone to a single destination, consider the users task and design a system that propagates its constituent parts to meet people where they are.

Communication is critical

Given that people experience our systems differently depending on their vantage point, we agreed that clear communication was essential.

Rather than assuming that everyone is aligned on the bounds of our systems, the language we use, and the way things get defined, distributed and evolved, we must over-communicate to the point of tedium to build shared knowledge.

Is the real source of truth the friends we made along the way?

One comment that really stood out to me in this discussion was that the real source of truth is the people within our organisation: their individual and collective knowledge; the way they collaborate; and the touch points at which they come together.

When we talk about the systems source of truth we tend to concentrate that conversation on artefacts: docs or code? Figma or GitHub? But it’s the human systems in our organisations that determine what enters our system in the first place.

Does it actually matter?

Design systems do not have a single source of truth. Individuals may experience the system through one, primary destination - or they may not. But the point is that a system is a system, a collection of constituent parts that work together to form something coherent, multifaceted, and complex.

Fixating on a single source of truth forces us into linear thinking, which is antithetical to the very notion of a system.

As Geri Reid, who kindly helped me facilitate today’s session, put it in the notes she shared with me afterwards:

“This confusion over the whole source of truth thing is a problem of own making in design systems.

Design systems are about people so I feel like we’re perhaps overcomplicating something that isn’t really even a thing.

Let’s never talk about this again.”

Notes on coffee

2022-11-21T00:00:00Z

What does coffee mean to you?

For me, coffee is a reliable benchmark against which I can measure my general happiness. Sometimes it’s the icing on the cake. Sometimes it’s the best part of my day.

On really busy days, coffee is an act of defiance against the chaos that surrounds me: a moment carved out just for myself, to wrap my hands around a warm mug and take a deep breath, re-fuelling myself for whatever comes next.

Maybe that’s why people tell me I take too long to drink my coffee. My last sip is never hotter than lukewarm, and I know this offends the piping-hot people, but I won’t be rushed.

I’m not a snob when it comes to the particular mode of caffeination. I make room for all of it.

You know how, with music, even a song you don’t really like can give you goosebumps in the right moment? I feel the same about coffee.

I like fancy coffee, made for me by an East London barista in perspex-rimmed glasses, and sipped in an establishment that charges me £18 for the privilege of sitting against a peeling wall, on a wooden chair salvaged from a skip.

I appreciate a lovingly-homebrewed coffee, savoured in bed while I do a crossword on my phone - a morning ritual I began during the first lockdown and have guarded passionately ever since.

And in a different way, I find just as much gratitude for the coffee that’s made in huge quantities and poured straight from an urn into a too-small china cup: a speck of warmth to anchor onto amidst a crowd of conference attendees; 70th birthday party guests; black-clad mourners.

But when a choice is offered, I have my preferences.

I like coffee best when it’s dark and punchy, with notes of rich sweet things, like chocolate, caramel and vanilla.

Once upon a time I liked coffee one of two ways: completely black, or milky as a latte or cappuccino. Perhaps that said something about how I saw the world, back then.

These days I most often have an Americano with oat milk.

I think it’s important not to get too comfortable, so I invite other coffee into my life often. These deviations are usually inspired by the orders of those I drink it with. “Oh you’re having a cortado? Make that two, please.”

And if you think I sound like someone who doesn’t know my own mind, be reassured that I do (or that I’m getting there, at least) - it’s just that I like to peek inside yours, too, sometimes.

There is just one thing I’m resolute about:

I never have sugar in my coffee.

Dear male ego

2022-11-18T00:00:00Z

Dear male ego,

It’s not you - it’s me, after dealing with you and all the yous that came before you.

I’m writing to tell you that I’m breaking up with you.

I’ve done my best to keep you happy, but it’s never done the trick, and I can’t do it anymore.

“His heart’s in the right place”. That’s what they tell me. “He’s a good guy, he just really cares”, “He doesn’t know how he comes across”, “He doesn’t mean badly”, “He’s been through a lot”.

I believe them, and I know it’s not really about me at all.

The reason that you interrupt me, belittle me, dismiss me, circumvent me, exclude me, obstruct me, disrespect me, and do all the things you do to me is nothing to do with me at all.

And I can keep empathising and psychoanalysing and trying to understand you, but here’s the thing: I am tired. Exhausted, in fact.

Because all these things that you do to me - that have nothing to do with me - have exhausted me.

And isn’t that funny, when you think about it?

All these things that you’ve done to me, all these doubts you’ve given me, all these ways that you’ve exhausted me, you’ve done without even having me in mind.

And none of these things that I’ve done to protect you from feeling threatened, to make you feel important, to try and stop you from feeling that you needed to do those things to me, I’ve done without even having me in mind.

Because I now realise that we’ve both had you in mind, this whole time.

And today I’m swapping you out for me.

I’m breaking up with you, for my own good.

I’m breaking up with you because you do nothing but hurt me.

I’m breaking up with you because you're not letting me do my damn job.

I am breaking up with you because I am clean out of fucks to give.

So I’ll drop round a box of your things. I’ll bag up the insecurities and the self-doubt and the burnout you left me with and I’ll leave them on your doorstep, back where they belong.

And I’ll say goodbye.

I'm out.

I'm a design systems consultant and I'm fine with duplication of effort

2022-11-17T00:00:00Z

One of the most common promises we make when making an investment case for design systems is that they’ll reduce or completely eradicate duplication of effort.

“Look at all these different button instances we have! Once we have a design system, we can just create components once and use them anywhere” - goes the pitch.

The problem is that it’s not a promise design systems can, or indeed should, fulfill.

First off, it takes time to grow a design system’s coverage. The idea that a design system will answer every team’s need from the moment it comes into existence is clearly unrealistic, but somehow pervasive.

What’s more, removing duplication of effort entirely harms a design system’s usefulness.

Design systems exist to provide common solutions that are versatile enough to be applied in multiple contexts. To do that successfully, we first need to fully understand those contexts - and that means diverging before we converge.

When organisations treat duplication of effort as an intolerable and urgent problem to be rectified, it often leads to rushing - which can damage trust and slow adoption.

Ultimately, design systems are not replacing nothing. They’re replacing context-specific (if inefficiently created) solutions.

It doesn’t make sense for product teams to adopt design system components and patterns unless it matches or exceeds the quality of those that they’re already using. This can’t be achieved without taking the time to review context-specific elements before creating a centralised offering.

That's why I've come to see duplication of effort not as a sign of failure in design systems, but rather an essential part of their success. Treating it as such is what ultimately helps us remove needless waste from our workflows.

Making space for multiple truths: Reflections from FF Conf 2022

2022-11-16T00:00:00Z

Last week I headed to the coast for my first time at FF Conf - an annual web conference held in Brighton.

While some conferences have clear themes, what struck me about this one was the stark variation in the content and tone of the talks.

Joe Hart summed it up well on Twitter when he commented that it left him with a mixed energy of “Let’s go and build stuff!” and “We’re all going to die”

And it’s left me reflecting on the importance of holding space for multiple, sometimes competing truths.

Web work comes great responsibility

Florence Okoye opened the day with an important message about empowering the people we’re designing for.

She advised us to consider the relationships we want to create between us and the people we’re creating for, asking: “Is it one of solidarity? Assistance? Support? Is it reparative?”

Unless we take time to build these relationships with those communities, we can’t design inclusive, empowering experiences for them.

Lex Lofthouse pitched her talk at developers, arming them with knowledge and techniques to make intentional design choices in their work. I really like the idea of sharing responsibility for the outcomes of our work across disciplines, in contrast to the hard distinctions we often aim to draw between different roles.

Towards the end of the day, Sareh Heidari discussed a subject close to my heart: digital exclusion in healthcare. She talked about the importance of considering the needs of those who face barriers when accessing digital services, like people who:

live in areas with poor connectivity
use assistive technology
have no fixed address
are in poverty

As someone who writes for a living, Sareh’s notes on health literacy also struck a chord with me: 4 in 10 adults struggle with health content, and that jumps to 6 in 10 when that content includes statistics.

Our power to change the systems around us is limited - and that doesn’t mean we shouldn’t try

Heydon Pickering’s talk was probably the funniest conference talk I’ve ever seen, until it wasn’t. Social media’s algorithms favour divisive content that sells adverts, fuelling a culture war that distracts us as capitalism destroys the planet and everything we hold dear.

Rightfully, no magic answers were proffered. Instead, we were invited to take a stark look at the brokenness of our systems, and our relative powerlessness to change them.

Natalia Waniczek’s Working towards a greener world from behind the keyboard started out equally sobering, bolstered with terrifying statistics. I was horrified to learn that the internet is responsible for 3.7% of global greenhouse emissions - as much as the whole of the aviation industry, and the whole of Germany.

Although Natalia doesn’t subscribe to the narrative that individuals are personally responsible for climate change, she impressed upon us the importance of making small changes to the way we work, and lobbying for systems change.

I was heartened by Natalia’s closing message, that although we only have 10 years left to save the planet, that also means we still have 10 years left to save the planet.

Finding joy in our work matters

In contrast to the more solemn talks of the event, the day was scattered with a series of more hopeful, playful messages.

Sophie Koonin’s Love letter to the personal website explored how, through the commercialisation and monopolisation of the web, we’ve lost sight of the joy and creativity that once came with creating our own little corners within it.

As a once shy and awkward teen who spent many hours honing the perfect <marquee> for my own neocities extravaganza in the late 00s, I loved Sophie’s call to go forth and create more fun, weird content on the web.

Lily Madar’s talk, programming with yarn, was a perfect portion of post-lunch ASMR, drawing comparisons between crochet and computer programming with videos from a corner of the web I’m henceforth dubbing “LoomCore”.

Finally, Ruth John wrapped up the conference with a discotechnique delight constructed in the browser using a series of clever media APIs. As one of the Non-DevelopersTM in the audience, the technicalities of this one were a little beyond my understanding, but give me some chilled beats and pretty lights and I’m always happy.

Life is not binary

As I alluded to in the introduction, my prevailing takeaway from the day is this:

We have to make space for multiple, competing truths in our work.

As the people creating the digital world, we can accept the responsibility that comes with our work, and recognise the futility of our mission, and find moments of joy along the way.

Sometimes I feel such pressure to take a stance that I forget to engage with the messy middle ground - but that’s what life is. It’s a series of “and”s.

Life is not a dichotomy, it’s a paradox: a rich set of complex and conflicting ideas and experiences - and they all deserve a place.

So I’m thankful to all the speakers and to the organisers for this reminder to make room.

Building conscious design systems

2022-11-15T00:00:00Z

This post is based on my recent talk, Building conscious design systems, which I gave at WDC and GOV Design Systems Day.
Here's the WDC version if you prefer to watch it.

When we talk about the benefits of design systems, the 3 most common promises are:

efficiency: a design system will reduce waste in your design and development processes, and help you go faster
consistency: a design system will help you standardise your digital experiences
scale: a design system will help you scale your design decisions across your product landscape

But here’s the thing we rarely ever say: None of this has any inherent value.

Efficiency is only valuable if it helps us move faster towards meaningful outcomes for the people using our products and services.

Consistency is only valuable if we standardise things to a good level of quality.

And scaling things is only valuable if they’re actually worth reproducing.

And although this might sound obvious, I say it because I’ve noticed a shift in the conversation around design systems lately that concerns me.

It feels to me as though we’ve become so fixated on the mechanisms that make it possible to deliver those promises—of efficiency, consistency and scale—that we’ve lost sight of the why.

How design systems create value

People often point out that design system teams are there to enable teams creating the product experience, but they themselves are not responsible for it.

And whilst I do agree that design system teams cannot be solely responsible for the resulting user experiences and outcomes, I also don’t believe they can draw such a hard boundary.

If we agree that there’s no inherent value in the added capability promised by design systems—efficiency, consistency, and the ability to scale—then the value must lie in what we do with it.

But this introduces a problem.

Because if we can use our design systems to speed up meaningful work, standardise things to a high quality, and scale the things we actually want to reproduce - then the reverse is also true.

It means that we can also use our design systems to:

speed up problematic work
standardise things to a poor quality
scale things we don’t want to reproduce

In other words, not only is this work not inherently valuable, it is also not inherently harmless - and that’s something I don’t think we can ignore.

The risk of design systems

To explore the ways in which design systems present a risk - and what happens if that risk isn’t managed - we should start by thinking about how they work, at the most basic level.

We create design systems by curating and distributing a collection of components, patterns and content.

As teams in our organisation start using the system to build websites and applications, these things start to get scaled across our digital product landscape.

But it’s important to say again that the mechanisms our design systems use to scale have no inherent value unless they’re things we actually want to scale.

And what if they’re not?

To explore that, we can look at some examples of what happens when the risk of design systems isn’t managed.

Example 1: Dropdowns

Let’s start by looking at a pretty common component. This is called a select - you might also know it as a select. It’s normally used to let people pick an option from a list.

But even though it’s pretty prevalent - the accessibility issues with it are well-documented.

Back in 2014, Alice Bartlett—a frontend developer who was working at the Government Digital Service at the time—gave a talk describing the problems she’d observed people having when trying to use a select.

Again and again, she saw users:

being unable to close the select
trying to type into the select
confusing focused items with selected items
trying to pinch zoom select options on tablets

And the thing is that a lot of the time, these issues are completely avoidable. In many cases, we don’t really need to use a dropdown, and could just as easily let our users answer using:

radio buttons
a free text input
a text input with an autocomplete

This doesn’t mean we should never use them: There are times where a select component is genuinely the best or indeed the only option. But they probably shouldn’t be the first thing we turn to.

And this is where I think design system documentation needs to do some of the heavy lifting.

Because there’s a significant difference between a design system that says “here’s a dropdown - knock yourself out” and one that consciously:

lays out the problems it carries
describes the common alternatives
helps designers and developers to make an informed decision about choosing to use one

A good design system helps its users make informed, conscious choices about when and when not to use components.

Example 2: Asking for people’s names

We can start with a common pattern - how we ask users for their name. This is something most design systems include.

But when I think about how lack of diversity in our industry as a whole really shows up in our work - this is one of the first things I think about.

And that’s because a lot of us working in this space have some very narrow and biased ideas about names - see this list of 40 false beliefs about names put together by Patrick McKenzie.

When these false assumptions inform our design systems, and our patterns for asking people for names, we start to exclude people.

There are hundreds and hundreds and hundreds of people being told their names are invalid, all all over the internet. There’s even a whole Twitter account dedicated to validation error messages on name fields.

And when I was collecting these examples, I was struck by a recurring comment made by people on the receiving end of these errors:

“This is the story of my life”

When this happens to people again and again and again, we’re giving them a clear message: this is not for you. We become authors in that story of exclusion.

In reality, our design systems cover much more than just name fields.

Our design systems are not just harmless scaling machines

When we don’t design for this full human spectrum of identities and characteristics and circumstances and experiences that our design system needs to serve, we’re not just excluding people - we’re erasing them.

Because although our design systems might sometimes seem like harmless scaling machines, we’ve got to start thinking about the human impact.

What happens if our components are inaccessible? What if our patterns are discriminatory, or our content is exclusionary?

What happens is we create a system of harm.

We industrialise discrimination, and set up a production line which allows us to ship exclusion to the people using our products: quickly, consistently, and at scale.

Design systems don’t cause all harm and design systems can’t prevent all harm. But…

Design systems alone are not responsible for these problems.

Design systems form part of our wider digital, political and social systems, and it’s those systems in their entirety that foster these problems.

But design systems can certainly perpetuate these problems and, I believe, can help to counteract them.

What we absolutely can do is recognise and mitigate risks and work to build conscious design systems.

So how do we do that?

How to create conscious design systems

1. Don’t assume that common practice ≠ good practice

There’s a lot of debate about whether design systems should set out what good looks like, or simply systematise existing practices. But at the very least, we should distinguish between the two.

It’s important that those of us who are working on and contributing to design systems question what we consider to be default solutions, and recognise that common practice does not equal good practice.

Returning to the dropdown example that I shared earlier, we can clearly see how incredibly prevalent these have become in our digital services, despite known issues with them. And I can’t help but think that a big reason for this is just “everyone else is doing it”.

When we see a digital practice forming it’s easy to assume that we’ve converged on something sensible - but that’s not always the case. Don’t underestimate the power of the bandwagon effect.

And relatedly, I also want to point out that just because Google does it, that also doesn’t mean it’s good.

Case in point: Until 2017, these were the text fields for Material UI - Google’s open source design system. Google’s design replaced traditional input boxes, for users to type into, with lines, for users to type onto.

This unconventional approach raised concerns with some designers and developers, who suspected that the affordance of the line would cause confusion for some people, and impact usability. But this was Google - so a lot of those people who had concerns, found themselves shouting into the void.

In my colleague Heydon Pickering’s article, Listen to me and not Google he describes the frustration of trying to convince a client to avoid Google’s approach and use a more conventional input box instead.

But the client felt that the source of this approach legitimized it. (Don’t underestimate authority bias.)

Then, in 2017, Google announced it was redesigning its text fields.

After deciding to conduct some usability testing on the original design, Google discovered for itself the issues that others had raised.

They wrote “The line affordance under the old text fields was not clear to some users [and] was confused with a divider.”

The trouble was, that even though Material UI may have updated its text fields, thousands of other organisations had already adopted its first design and have not followed suit on the change.

I don’t want to go too hard on Google here, but I will say that with great power comes great responsibility. People assumed that Google would have done its research in the first place, and that its patterns could be relied upon.

That’s why it’s so important to question our defaults - prevalence is not an indicator of quality. Just because an approach is common, doesn’t mean it’s inclusive.

2. Prioritise inclusion at every level

A theme across the examples I’ve shared here is exclusion. When we create design systems without a conscious intention to mitigate harm, and a strategy to help us fulfil that intent, we end up excluding people.

So to counteract this, we can think about inclusion.

Inclusion doesn’t start and finish with the experience of the people using our products.

The question of inclusion begins at the level of the design system team, and then expands out through:

people who contribute to the design system
teams who use the design system to build their products and services
the wider organisation
and eventually the community of people who use the products it's used to create

It’s important for us to think about inclusion at all those levels, to understand whether the experiences we’re helping to create are inclusive or not.

So perhaps the very first place to start is with the team who creates and maintains a design system. And a quick test might be: does that team look like this?

Now it’s really important to say that diversity isn’t inclusivity. Diversity is just variety. And aiming to recruit a diverse team without thinking about inclusivity is a recipe for disaster.

But if you don’t have or can’t sustain a diverse team, it’s a good indicator that it’s not inclusive.

So why does this matter? How is it that those of us creating design systems can impact the people who are all those layers away, using the products and services they’re used to build?

It all comes down to the knowledge and experiences that get fed into our design systems.

Kim Crayton, Antiracist Economist, talks about 2 types of knowledge:

Explicit knowledge, which is easy to articulate, codify and store, and can easily be transferred to another person
Tacit knowledge, which is difficult to transfer to another person by writing it down and verbalising it

Tacit knowledge is acquired through lived experiences - and it’s this that enables us to propagate inclusivity through our systems.

Or to put it another way: If we’re not building our design system in an inclusive environment that supports participation from a diverse set of perspectives - it’s near impossible for us to design inclusive experiences.

And if we haven’t experienced exclusion, it’s very hard to mitigate it because we’re much less likely to spot it until it’s too late.

I am not a diversity, equity and inclusion specialist - but I can see the connection between a lack of attention to inclusivity in organisations and the lack of inclusivity of experiences they create - and having visibility of this is the first step towards addressing it.

3. Create strong feedback loops

To create conscious design systems, we’ve got to understand their impact and be able to respond accordingly - and that means having strong feedback loops.

One important way we can do this is to invite contribution from the teams who are using our design systems to create products and services.

I’m not going to cover contribution in detail here as I’ve written several, more detail articles on the subject before:

The bottom line, when it comes to contribution, is that it’s very hard to create sustainable contribution practices - and we absolutely must do it anyway.

4. Centre stress cases

It wouldn’t be practical to try and create our design systems in such a way that they’re 100% inclusive for every single person, and every scenario in which they might access something from it.

Human beings are complex, and there are too many variables to consider, so we have to think about a more practical option.

My advice is to prioritise the people who are most at risk of harm if we don’t take them into consideration. Or to put it another way: prioritise stress cases.

The term “stress cases” was coined by Eric Meyer and Sara Wachter Boettcher in their book Design for Real Life, which I really recommend if you haven’t read it.

The book says: “Real life is complicated… We might experience harassment or abuse, lose a loved one, become chronically ill, get into an accident, have a financial emergency, or simply be vulnerable for not fitting into society’s expectations.”

Historically, our industry has called these edge cases because they only affect a small number of users.

In the book, Sara and Eric propose redefining these situations not as edge cases, but as stress cases: “the moments that put our design and content choices to the test of real life”.

Instead of treating stressful situations as fringe concerns, we should move them to the centre and start with the most vulnerable users, and then work our way outward.

And if you’re thinking this all sounds like an awful lot of work, you’re right.

Building a conscious design system will slow you down—do it anyway

Building a conscious design system will slow you down. There are no silver bullets here because part of building a conscious approach is reducing our speed to understand our impact.

Nothing I’ve shared here is a quick fix, but it’s a direction of travel.

It’s important that we balance the conversation around design systems and spend at least as much time talking about human impact as we do about the mechanics of our design systems.

The mechanisms our design systems use will change because technology will change, our environment will change, our requirements will change and our expectations will change. Concentrating on human impact provides a consistent focus, and will help us to weather this change and adapt our systems accordingly.

And in the end, it’s the only thing that really matters. We can’t know exactly what challenges lie ahead in the world of design systems, and certainly in the wider world - but we can choose what to centre.

We can choose to create conscious design systems that put people at their heart, even if it slows us down.

We can choose to do it anyway.

Inclusion doesn't come for free with open source software

2022-11-14T00:00:00Z

At the time of writing this, many people are setting up Mastodon accounts - an open source social media platform - in response to Elon Musk's takeover of Twitter.

I've seen a lot of debate about the inclusivity of Mastodon as a platform, with comments like:

"Mastodon is way more inclusive than Twitter because it's built by a community"
"But Mastodon has accessibility issues"
"And most of the people flocking to Mastodon are white"
"If you find an issue with Mastodon, you can just fix it yourself. That's the beauty of open source!"

There's a pervasive perception that opening something up for contribution inherently makes it more inclusive, and I want to challenge that here.

What is open source software?

Open source software is simply a model for building software in which the person who owns it gives users access to the code, and the right to change it.

An open source product may be created and worked on by a mix of owners and public contributors.

Open source ≠ inclusive

Open source software decentralises control of a product, and redistributes it amongst people with enough technical knowledge to participate in its production and maintenance.

This last bit is crucial.

The Venn diagram of people using OSS and people making it is not a circle - and not all of the people who use open source software have the technical ability to change it.

This means that if someone using an open source product hits a barrier, they might not be able to change it for themselves.

Decentralised control also means decentralised responsibility, which can make it harder to hold someone accountable when we encounter a problem. The thing which is everyone's problem is also no one's problem in particular.

Open source just a model for building software - and certainly not one I'm against.

But it's important to recognise that this model lives in our existing world with all its problems. It doesn’t magically transcend those problems and it doesn’t single-handedly solve all of those problems.

None of this is to say that open source software cannot be designed, built and maintained to be extremely inclusive - but it's not an inherent part of the package.

Decentralisation ≠ no governance

If we agree that the model of open source software creation is not inherently inclusive, then we have to do work to make it so.

Accountability structures within private organisations often rely on centralised control.

So when we look at the decentralised nature of open source engineering, it can be hard to work out how to create accountability, when no one's "in charge".

But distributed control doesn't mean no control--and decentralisation doesn't mean no governance.

Owners and maintainers of open source projects who care about inclusion must consider the risks that this model poses. They must ask questions like:

who will this empower and who will it disempower?
what are the implications of that?
what does exclusion look like in this work?
how will we monitor it?
how will we learn about abuse and harassment on our product?
how will we respond to it?
how can we communicate this to people who use and contribute to our product?

Exploring these questions can help us begin to develop a governance framework to support inclusion.

Inclusivity requires active work

Letting people contribute to an open source product is a passive step, that will encourage some to participate.

But cultivating inclusive spaces in which to contribute, and creating inclusive products calls for intention and proactivity.

Building communication, education, support and governance into our open source work is the route to prioritising inclusivity.

It's hard work, and it's non-negotiable.

A complete list of the times when it's OK to use lorem ipsum instead of real content in your design work

2022-11-10T00:00:00Z

End of list.

The case for jargon

2022-11-10T00:00:00Z

Jargon is defined as “special words or expressions used by a profession or group that are difficult for others to understand”.

Jargon has negative connotations, but it’s not unequivocally a bad thing.

Now you might be surprised to find me - content designer, plain language proponent, and inclusion advocate - arguing the case for jargon, but hear me out.

Jargon can support belonging and solidarity

Jargon is exclusionary to those not familiar with it, but for those who have learned its meaning, it can create an important sense of solidarity and belonging.

When I consider this, I often think about Eric Bailey’s article on the term a11y - a numeronym used primarily by disabled people and disability rights advocates as a shorthand for the word “accessibility”.

Although people new to the term might not understand it on first encounter, it’s become an important way for the web accessibility community to signal solidarity, understanding and allyship.

Searching the #a11y hashtag on social media lets people quickly connect with a community of disabled people, and others who are interested in making things more accessible.

The term “accessibility” has fairly broad connotations, while a11y allows people to signify something more specific, and in doing so it creates a sense of solidarity and belonging for those who use and understand it.

Jargon can be efficient

Let’s think about how Twitter uses jargon. If you’re familiar with Twitter, the following terms won’t feel like jargon at all, but there’s a high chance that someone who doesn’t use the platform wouldn’t accurately understand me if I mentioned:

Tweets
Retweets
Quote Tweets
Fleets (god rest their soul)
DMs- Handles- Mentions
Blue ticks (though it seems as though Twitter itself is still figuring that one out)

Using these terms on the platform allows us to communicate efficiently with each other.

Imagine if every time we wanted to ask our follows to retweet something, we had to say “would you mind opening the post I’ve just written, and sharing the post to your followers by clicking or pressing the icon with the two arrows?”. What a faff.

Most of us who use Twitter, even moderately, use it regularly enough that the initial language learning barrier has paid for itself many times over with the speed those terms now afford us.

That initial jargon-induced learning barrier still existed once, for all of us, but it’s passed.

The overhead of learning jargon is transient

As I write this, many people are flocking to Mastodon and - myself included - commenting on the initial impenetrability of the platform’s language conventions:

“what’s a Fediverse?”
“so… Tweets are called Toots over here?!”
“why is sharing someone’s post called reblogging and not retooting? That doesn’t make any sense!”

If Mastodon becomes, as some are predicting, the main replacement for Twitter, this discourse will die down. The platform-specific terminology will quickly become part of our language systems and turn into helpful shorthands that we use unconsciously.

All jargon is not equal: use it responsibly

I’ve talked about some under-discussed benefits of jargon here, but of course I - a content designer, plain language proponent, and inclusion advocate - do not condone its widespread and unquestioned use.

Jargon always gives power to those who understand it, and takes power from those who don’t. It’s really important that we recognise this and think about who we’re empowering and disempowering when we use jargon.

For example, briefly disempowering new users in exchange for a much more efficient experience for regular users, in a service designed for regular use is OK in my books.

And using jargon when it empowers a marginalised community and its allies to communicate with each other is also a wonderful thing.

Jargon that creates friction with little-to-no tradeoff, or simply empowers the already privileged needs rethinking.

In summary - jargon is inherently neutral. It’s what we do with it that counts.

Cultivating design systems by bringing intention

2022-11-09T00:00:00Z

Over the past few years, there’s been a significant shift in the way I think about the work of creating design systems.

Previously, I saw the task of establishing design systems as the act of making something new. And this is still how most organisations I consult with tend to approach the work.

Nowadays, I think of the work more as the practice of changing existing cultures, processes and tools to cultivate design systems that better support our needs and goals.

Why design systems work is more about changing than making

When we think about the work of creating a design system, we tend to foresee it happening at a point on a linear journey.

We hire our design system team and plan our work around what our version 1 design system will entail. We work on that until it’s released, and we go from having no design system, to having one.

And approaching the work with this mindset means that we often dismiss all those other processes, practices and resources that existed before version 1 as “not a design system”.

But what if we looked at things differently? What if we considered that before we’d even begun the official work, we already had a design system?

And that system might consist of:

designers creating prototypes in local Sketch libraries
a siloed design-to-dev handover process
developers working in localised, fragmented, frontend code libraries
lots of inconsistencies in our user experience

A design system like this might not be very effective. It might not help us work efficiently at scale, and our products might not be very consistent, and the quality might not be good.

But thinking of it as a design system doesn’t make any of that less true.

What it does do, however, is help us to avoid one of the most common missteps I see teams making - and that I myself have made - which is that we inadvertently create 2 design systems: The new “official” one, and the existing “unofficial” one.

Existing systems can undermine our efforts if we don’t engage with them

The thing about unofficial existing systems that emerge organically in our organisations, is that they tend to have strong roots.

So when we simply lay a new shiny design system on top, those roots have a habit of growing back through.

It’s why teams often cling to their existing product-specific components, rather than moving to centralised design system ones.

It’s why people continue to reference local pattern libraries, rather than visit a design system documentation website.

It’s why designers and developers continue to work in silos despite touchpoints, artefacts and processes designed to get them to collaborate.

So I think it’s really important that we don’t dismiss our existing design systems, but instead engage with them.

We need to recognise their validity, and bring them on the journey with us as we work to cultivate a design system that better serves our intentions.

Our job is not to set up new systems, but to bring intention to existing ones

So what if we thought about design systems not just as the bits we’d actively created, but as the practices and processes that allow us to design and deliver our experiences?

Looked at through this lens, our job is not to craft something entirely new, but rather to bring intention to those practices, to create a design system that better supports our goals.

For this to work, we have to take the time to understand our contextual purpose. What are the biggest problems our design system needs to solve? Where is it supporting those needs today, and what can we change to close the gap between our current design systems and our intentions?

This is a departure from the way we typically approach the work of establishing design systems, but one that I think offers a lot of opportunity.

Embracing the practice of bringing intention frees us up from the pressure to deliver system artefacts, and allows us to make incremental steps towards the place we want to get to.

In this world, every small movement counts as a success.

Your Figma library is not a design system. So what?

2022-11-08T00:00:00Z

Recently, I’ve noticed an uptick on my Twitter timeline of people stating, with frustration, that a Figma library is not a design system.

In my experience, the real meaning of this statement is usually one of these 2 things:

“Some of the people I’m working with don’t understand design systems in the way that I do”
“We’re spending too much time on our Figma library at the expense of things I think are more important”

So let’s look at those.

What if the people we’re working with don’t understand what a design system is?

I always urge people to be cautious in assuming that there’s one shared model of design systems, even amongst experts.

I’ve worked in this space for 6 years now. I consider myself an expert on design systems. And yet I often find myself and other experts disagreeing about their scope, purpose and how to implement them.

With that said, I do agree that a Figma library does not constitute a whole design system. But as design systems advocates, isn’t it part of our job to educate those around us?

Saying what design systems are not doesn’t tell people what they are. If people in our organisation are misaligned about the scope of a design system, we’re better off starting a constructive conversation to build shared understanding, instead of lashing out.

These conversations must start from a place of respect, humility, and recognition that there is no single definition of design systems.

What if we’re spending too much time on our Figma library instead of more important things?

We might have a perception that our organisation is over-focusing on a Figma library at the expense of other, seemingly more important parts of the system.

And we might be right about that. I’ve certainly seen it happen.

But no one is over-focusing on Figma just to piss us off.

We feel that someone is spending more time on something than it deserves when there’s misalignment between our priorities and theirs. And simply saying “that bit you’re working on isn’t a design system” won’t help us bridge the gap.

That’s why it’s so important that design systems work is underpinned by regular communication about goals and priorities.

A Figma library is not a design system. But…

A Figma library is not a whole design system, but this is rarely the real point worth making.

Not everyone shares the same understanding of design systems, and that’s OK. By surfacing discrepancies in our definitions, we can work towards a shared vision.

Likewise, not everyone shares our priorities when it comes to design systems work, but putting that on the table means we can negotiate that and come up with a plan.

So let’s stop pointing out that a Figma library is not a design system.

Let’s have a more useful conversation.

It's OK

2022-11-07T00:00:00Z

It’s OK to…

know you want a to make a change but not what change to make
take your time
not know what you think
not live every day like it’s your last
not have an opinion
hold back from sharing an opinion
want to share an opinion, without knowing what your opinion is
take a while to respond
apologise too much
decide to stop apologising
reject the idea that there’s a right amount of apologising to be done
grieve something you willingly gave up
have a day off worrying
not be able to have a day off worrying
rest, physically
rest, mentally
be unable to the last 2 things at the same time
feel left behind
feel inferior
feel superior, then judge yourself for it
feel a constant sense of urgency
quit Twitter
return to Twitter
resolve to spend less time on your phone
increase your screen time by 25% that same week
make mistakes
say no
say yes
feel attacked
feel defensive
feel exhausted
feel the full human spectrum of emotions and sensations, even the inconvenient ones
be imperfect
be human

Tension: Reflections from Leading Design conference 2022

2022-11-04T00:00:00Z

On Wednesday and Thursday this week, I went to Leading Design conference at The Barbican in London.

Rather than give a rundown of all of the talks, I thought I’d share some thoughts on a prevailing theme that emerged for me over the 2 days: the idea of tension between opposing forces.

Ray Ho and Jane Austin’s talks focused on the tension between design and other disciplines.

Nicola Ryan talked about the tension between introversion and extroversion for introverted leaders.

Alberta Soranza explored the tension that arises in global organisations from different cultural attitudes to time.

And many of the speakers talked about tension and change: the contrast from where we are, and where we want to get to.

Tension can be positive or negative

A reflection I had after watching the talks is that tension itself is inherently neutral. Tension is just what occurs in the space between opposing forces.

Tension can create balance, or it can create stuckness. It can cultivate creativity and innovation, or it can lead us into dead ends. It can energise and invigorate, or it can cause exhaustion.

It’s the conditions in which tension occurs that determines whether it’s positive or negative for those experiencing it, and what it results in.

We can ease tension, challenge it, or use it

Several speakers talked about ways to ease tension between user-centric design work and profit-focused organisations. Some advocated designers learning to frame their work in the context of business goals.

Holly Habstritt Gaal challenged whether these things are in opposition at all. At DuckDuckGo, she explained, employees and leaders in the organisation are aligned on the idea that profit does not have to come at the cost of user exploitation.

Jill Lin challenged our concept of tension between work and play, with a fascinating insight into how the Lego group integrates play into its ways of working.

Other speakers, like Ray and Alberta, talked about using tension to our advantage, to create necessary opposition, avoid stagnation, and power creative friction.

How can we create the conditions for positive tension?

A question I’m left with is how we create the conditions for positive tension. What makes the difference between the productive tension, and that which drains and obstructs us?

Acknowledging tension seems important. Lisa Welchman, who delivered my favourite talk of the conference, urged us to recognise that we are in a chaotic moment in the establishment and governance of our digital infrastructure. Given this, we must simultaneously recognise the limitations of our power against the conditions in which we’re operating, whilst holding ourselves accountable for safeguarding the experiences we create.

Others, like James Stevens, emphasised the need for leaders to engage in self-reflection and self-care when working in periods of tension. He also spoke about the importance of sharing vulnerability - advice echoed by Aleks Melkinova.

I think what draws these things together is trust. Honesty and vulnerability help to build trust, and when I picked up this question with a couple of the speakers after the event, we were in agreement that trust is one of the main foundations for healthy tension.

And trust grows not from agreement, but from respect. If we can cultivate respect and trust in our teams, we can create an environment in which positive tension can thrive.

Why we need to test our content with marginalised users: a short case study

2022-11-03T00:00:00Z

Last year, I worked on a service designed to help children and young people find support for their mental health.

To find relevant support options, the service asked users what kind of support they’re looking for. One of the original options we gave was “I want some ongoing help to get better”.

The wording seems fairly innocuous, but when we tested it with a Transgender teen, they spotted a problem.

Having already answered that they were struggling with issues around their gender identity, they hesitated at the question.

They told us that the phrase “get better” made it sound like the service was suggesting conversion therapy.

“This isn’t something I need to get better from, this is who I am” - they told us.

While saying “get better” might make sense for someone who’s struggling with disordered eating or anxiety, it’s not appropriate for people struggling with their sexuality or gender identity.

We’d done our best to use inclusive language throughout the service, but as a team of cisgender people, this didn’t occur to us.

Thanks to this feedback, we updated the wording of the option to “I’d like to understand my feelings and learn ways of coping”.

If we hadn’t done this research and updated our content, we could have dissuaded a whole contingent of people from getting the support they desperately needed.

The connotations of our language can change depending on the person who’s reading it, and the context in which they’re seeing it.

That’s why it’s so important to test content with marginalised people, and with those at most at risk of harm from exclusion.

Should consistency be a goal of design systems?

2022-11-02T00:00:00Z

It’s becoming increasingly unfashionable to cite “consistency” as a goal for design systems.

I’ve seen plenty of design system teams ditching the term in favour of words like “alignment”, “cohesion” or “unity”.

The goal of swapping these terms around, as far as I can tell, is to combat the perception that those of us building design systems seek to make everything look the same and stifle creative expression.

Personally? I don’t think ditching the word “consistency” is the fix we’re looking for.

Consistency ≠ everything looking the same

One of the UK Government Digital Service (GDS) design principles is “Be consistent, not uniform”.

While GDS advocates using the same language and design patterns to create familiarity, but acknowledges that circumstances vary and context must guide individual design decisions.

Where it’s not possible to follow design and content patterns, GDS advises its designers to “make sure our approach is consistent” - and I think this is an important distinction.

Visual and functional consistency of individual components and design patterns is one version of consistency - but it’s not the only one.

We could instead create a design system that uses a consistent set of primitives and design values, but allows much more flexibility in how they’re applied to individual contexts.

So it’s important that we take the time to consider what level of consistency we’re seeking, and where there’s room for divergence.

No alternative term solves the problem

Taken from Google, here are the (relevant) definitions for the common terms design systems teams use to replace consistency:

Cohesion is “the action or fact of forming a united whole”
Alignment is “a position of agreement or alliance”
Unity is "the state of being united or joined as a whole"

If “consistency” as a term feels too constraining, then perhaps the intent of using these words is to create space through ambiguity.

But that introduces a new problem: a lack of precision. In fact, what they all imply is simply “a system” - a set of things that work coherently as part of something bigger.

Given this, what becomes important is what we mean when we use these terms. And if what we mean is some level of consistency, and that concerns people, then at some point that concern will resurface.

Terminology can’t replace strategy

There might be a design system team who found that switching the word “consistency” for the word “cohesion” allayed all of their stakeholders’ fears, and resulted in universal advocacy - but I’m yet to meet them.

What I often hear instead is that the act of changing the term to something new provided an opportunity to tell a story, to address objections, and to provide clarification. And I suspect these are the things that actually helped.

Design systems always aim to bring an amount of standardisation. It’s by reducing needless and unwanted inconsistency - in approach and in implementation - that they’re able to drive the efficiency that is the bedrock of so many design system investment cases.

How much consistency is desirable, and what we want to standardise, is up for grabs. It has to be discussed and agreed in context, based on what’s right for each individual organisation at a given time.

No one term can convey everything

I see this as an example of a wider tendency in the design systems field. We continually rake over our lexicon in pursuit of the right terms that will perfectly communicate what we mean to convey. When a term creates misconceptions, we’re quick to reach for something else.

But individual terms can only do so much.

In the end, I don’t think it really matters if we say consistency, or cohesion, or alignment, or unity, or anything else. What matters is what we mean, how we qualify it, and how we demonstrate it.

National Blog Posting Month 2022: day 1

2022-11-01T00:00:00Z

For the second year in a row, I’ve decided to take part in National Blog Posting Month, or “NaBloPoMo”, for short.

What is NaBloPoMo?

According to this post by Michelle Weber, NaBloPoMo was founded by an American blogger called Eden Kennedy, in response to National Novel Writing Month (NaNoWriMo).

Participants write a blog post every day throughout November, to break away from perfectionist ideals that might otherwise prevent them from sharing their work.

Since “perfectionist ideals” are a particular blocker for me when it comes to writing, the idea spoke to me.

My starting point

Having taken part in NaBloPoMo last year (See a summary of 2021’s effort), I found out the hard way how important it is to get ahead with ideas and drafts, rather than leaving it until the day of each post to write it.

Have I learned from my mistakes and organised myself better this year? No. But here we are.

So I’m going into this slightly chaotically and with a lot of apprehension - but that’s what makes it interesting right? Right??

One lesson I am going to heed this year, to help myself, is to give myself weekends off.

What I’m expecting

My brain is awash with disorganised thoughts and opinions and I’m hoping that the next 29 ideas or so will help me to build and refine some of those ideas.

I’m expecting there to be a fair amount of overlap between the posts I write, with each other, and with past posts and talks I’ve written. And I’m fine with that.

What you should expect from me

I’m going to be flexible with topics. I’m planning to write about a mixture of things, both work-related and personal.

And since one of my objectives here is to challenge my perfectionist tendencies, my writing is probably going to be a little less polished and a little more chaotic than usual.

I’m going to allow myself a quick top-to-bottom proof-read of each post, and then I’m going to hit publish.

Here we go…

And so we begin.

Are you taking part in NaBloPoMo? I’d love to read your posts if you are.

Or, if there’s something you’d like me to write about, let me know—I need all the inspiration I can get.

Get in touch on Twitter or drop me an email at amy.l.hupe@gmail.com.

Your design system contribution practice is doomed to fail

2022-09-23T00:00:00Z

This article is based on a talk I delivered at Converge London 2022 - here's the video in case you'd prefer to watch it.

In 2020, Nathan Curtis wrote:

“It’s foolish to think a [design system team] sees everything, let alone understands all the subtle forces at play across an experience. It’s product designers and developers on the front lines, working to solve customer problems on a daily basis, that bring that seasoned perspective.

"The practice of contributions injects a much wider representation into the features and tools the system offers. Contributions bring new ideas, extending what a system team hasn’t seen or considered. Different patterns come into play, test and expand the work.”

I agree with this unequivocally.

In my 6 years working on design systems, I have rooted for fostering a sustained contribution practice in every organisation I’ve worked for and with.

But most of us working on design systems find it hard to achieve. I’ve struggled with this in my own work, and I know I’m not alone.

I regularly speak with organisations who tell me:

“We’re struggling to get people to contribute”
“People aren’t following our contribution guidelines”
“The things people contribute are a long way off being ready to release”

There’s a sense of swimming against the current. No matter how hard we try to achieve a steady flow of contribution, it seems like not contributing is the natural default.

Even teams who have fostered a sustained contribution practice tell me that the effort to reward ratio seems, somehow, off: That the time and effort required to elicit regular contribution, of a releasable standard, leaves them questioning if it’s worth it.

To explore why that is and what we can do about it, I’m going to invite you down a path of politics and economics. And more specifically: Capitalism and socialism.

A whistle stop explanation of capitalism and socialism

Capitalism is a system in which the means of production are privately owned.

The function of a capitalist system—and all of its constituent parts and processes—is to help private owners make as much profit as possible. They are free to grow their wealth and resources without regulation or interference from the government.

Critics of capitalism say that it disproportionately benefits a wealthy few, creating stratification of social classes and reinforcing systemic inequality.

In a socialist system, the means of production are publicly owned by everyone.

The purpose of a socialist is to distribute wealth and resources equally across a society.

Critics of socialism say that it removes the incentive to compete and so leads to a lack of economic growth.

What does capitalism have to do with design systems?

Since we live in a capitalist society, we can think about our organisations as a microcosm of that society.

We are incentivised to help our organisation’s owners and shareholders to make a profit.

More often than not, we are incentivised with the promise of power.

For individuals within the organisation, power translates to:

influence
career progression
visibility, either inside or outside the organisation, or both
immunity from consequences of disobedience and poor performance

For teams, it usually means::

influence
product performance (usually in the form of profit or money saved)
visibility, either inside or outside the organisation, or both
immunity from consequences of poor performance

How design system teams earn power

Design system teams can build power by creating common solutions that help other teams in the organisation to work more efficiently.

The more of these common solutions they're able to produce, the larger their audience grows and the more impact they have, the more money they save the organisation, the more business critical they become, the more investment they receive and, ultimately, the more power and production capacity they have.

And this becomes self-reinforcing as they can then use that extra capacity to create more of that common infrastructure that the organisation values and grows to depend on. And the cycle continues.

So where does contribution fit in?

Contribution to design systems is a socialist ideal

The idea of opening design systems up for contribution from other teams in the organisation is usually described in socialist terms.

It says that if everyone contributes to a design system, the design system becomes better for everyone in turn.

Capitalism discourages contribution by design

People are not incentivised to contribute

In a capitalist environment, a person's ability and motivation to contribute (or not) is governed by the best chance of earning power.

And most people earn more power from their core role than they do from contributing to a design system.

Design system contribution is usually not part of a designer or developer’s job description.

Even when it is, contribution takes time away from a person’s day-to-day work, which is normally what people are assessed against and compensated for.

So design system teams can spend time trying to elicit contribution, but they'll be working against the organisation’s default incentive framework.

Design system teams are not incentivised to support contribution

Spending too much time trying to elicit contribution threatens the design system team’s own power.

The more time they spend driving contribution, the less time they can spend producing that common infrastructure that they need to earn power.

There is sometimes a belief that contribution can help design systems grow faster. That by getting more hands on deck, the team can deliver more work, more quickly.

But as anyone who’s implemented a contribution practice will tell you, it’s not the reality.

When Nathan Curtis interviewed a group of design system leads in 2020, they told him that although contribution was valuable for other reasons, they “do not reduce workload and do not make [a] system produce more”.

In fact, in my experience, contributions actually increase workload and make our systems produce less.

Supporting people to contribute, and to produce features and documentation of a releasable standard takes longer than it would for a design system team to do the work themselves.

This means that most design system teams earn more power by building their system, than they do by helping people to contribute to it.

Even if you care about contribution, the system will work against you

Now I want to stress that I’m talking about systemic incentivisation here, not individual motivation.

You, as an individual, might be highly motivated by the idea of contribution, and investing in a greater good.

And if you’re working in a design system team, you might be committed to the idea of making contribution a success. You might even be willing to relinquish power to achieve this.

But the fact is that the system we’re operating in is not built to cultivate this.

So it’s not too far of a stretch to say that contribution, in this environment, is destined to fail.

But there's another layer of complexity that makes this even more problematic.

How contribution models can reinforce inequality

Earlier on I said that most people earn more power from their core role than they do from contributing to a design system.

While that’s true for most people, a small number of people get to both.

And that’s because even though we are all incentivised to earn power, some people already have it.

Now that might be because they earned it. They might have worked their way to the top and earned that influence that they have, and that visibility, and a degree of immunity from consequences.

But often, power comes from privilege.

Our systems do habitually favour some people and they do disadvantage others - whether that’s because of race, gender, religion, socio-economic background, disability, or any other number of things that impact the amount of power people have.

That’s why some people in our organisation are free to earn power through contribution and their core role, while others have to choose.

People who already have power don’t need to earn it as much, so they can afford to take time out of their core role to contribute to a design system.

They are influential, visible, and trusted already, and so they have less to lose than those without power.

And this inequality becomes self-reinforcing. If only individuals who have enough power already are able to contribute, then only those individuals can increase their power through contribution.

Over time, this widens the gap between those with power and those without.

And this doesn’t just affect the people in our organisations, but also the people who use our products. Because we’ve got to ask ourselves if it’s really possible to create a design system that represents a broad set of needs and perspectives, if only a privileged few can help shape it.

Viewed through this lens, contribution as a socialist ideal is not merely doomed not to work: it’s actually destined to reinforce inequality.

Can we make contribution viable and more equitable?

The capitalist system in which we’re operating is designed to impede a fair and representative contribution practice. Armed with this information, it seems as though we can either:

Revolt: change the system in which we’re operating so that we can realise our socialist aspirations
Give up: Accept the system in which we’re operating, forget about contribution altogether, and have the design system team make everything

To most of us, this choice probably feels a bit disempowering.

Spearheading a full-blown revolution probably feels, at best, a bit daunting to most of us. And, in any case, there are probably better contexts in which to discuss that than in an article about design system contribution.

And forgetting about contribution altogether doesn’t seem optimal for most of us either.

Uphill battle or not, there’s a reason so many of us persist at trying to establish a contribution practice.

It’s hard to imagine a context in which a completely autocratic design system team could succeed. Most designers and developers expect a degree of input into the decisions a design system encodes, and would struggle to trust one they couldn’t influence.

What’s more, regardless of whether or not design system contribution is compatible with a capitalist environment, most of us agree that its purpose matters. Representation matters. So we’re probably going to keep trying, despite a low likelihood of achieving that goal, given the way we currently approach it.

So instead of considering this a binary choice, let’s think of it as a spectrum. What opportunities lie in the middle ground between these two responses?

And instead of getting caught up in wondering whether we as individuals have the power to change things, let’s try asking a more empowering question:

“What can I do from where I sit?”

This question was introduced to me by coach and author Sara Wachter-Boettcher - and it’s a great way to break free of this kind of disempowering, binary thinking.

This is a complex, systemic problem with a myriad of imperfect, overlapping solutions to explore - so I don’t have a concrete answer to this question.

But I do have some thoughts that I hope might form the beginning of a conversation.

1. Recognise and name the problem

I think there is immense value in naming this problem - if only to provide reasoning and validation for the creeping sense of burnout many design system teams experience when negotiating this challenge.

If what I’ve talked about here resonates, then I encourage you to spend a bit of time with it.

How does it feel to consider that it’s not you getting it wrong, but rather that the task you’re faced with, and the capitalist system you’re working in, are in conflict with one another? What might we do differently?

Recognise that this is not just your problem to own. This is a systemic issue.

Naming and agreeing on the nature of the challenge we’re facing is the first step towards figuring out where we go next.

2. If we want to build representative design systems, contribution models must redistribute power

To be more equitable, our contribution practice must rebalance power between the people who can contribute, and those who can’t.

How can we empower a more diverse group of people to contribute?

Can we make it so that everyone receives a comparable return on investment for contributing?

Can we remove barriers, to lower the amount of time and effort involved for those who struggle to contribute? And can we introduce better incentives to increase the power they’ll derive from it if they do?

To be able to answer these questions, we have to know what bargaining chips we have to offer.

In other words, we have to identify our organisational currency.

3. If power is capital, what’s our currency?

If power is the main incentive in our organisations, then we can think of currency as the systems that teams and individuals can use to trade power.

Currency can be something that’s officially recognised.

For example, exceeding the objectives set out in your performance framework is a form of currency. Your performance over the course of a year surpasses what was expected of you, your line manager records this, and you receive power in the form of a bonus or a pay rise. In theory, at least.

Currency can also be unofficial.

Being friends with your boss might be a form of currency. The organisation makes a round of redundancies, and they put in a request for you to be kept safe. Your power is derived from that relationship and results in job security. This kind of currency might even be denounced by your organisation at an official level, but that doesn’t make it less real, or indeed, less valuable.

Organisational currency can range from getting a shout out in the monthly all-hands for a piece of work well done, all the way through to a promotion to director level.

Once we start to understand the systems of currency our organisation uses to buy and sell power, we have something to barter with. We understand how to participate in those systems, and when and how to disrupt them.

4. Balance acceptance with activism

The appropriate balance between acceptance and activism will depend on your organisation’s structure and culture.

However, in general I identify 3 main options for reconciling the socialist practice of contribution with the capitalist system we’re in.

Change our organisation’s culture and power structures to support contribution - this is the most radical and disruptive opinion.
Update our system(s) to make more space for contribution
Work with our system(s), designing our contribution practice around it.

For example, in strictly-governed organisations where people don’t get to choose what they work on, spending our time touting the value of contribution to designers and developers is going to be of limited value. They might care, but the system is designed to prevent the majority of them from being able to act on it.

At the most extreme end, we could aim to create a fundamental shift in the organisation’s culture to support a more autonomous way of working.

If that isn’t possible, we may work with the discipline leads and managers in our organisation to make contribution a recognised part of people’s roles, so that they’re allowed to dedicate time to it during their working hours.

And if that’s not an option either, then we can adapt our approach to be more proactive about eliciting contribution.

Rather than having contributors approach us, can we go to them? How could we harvest their insights and experiences to create a richer and more representative design system, without putting the onus on proactive contributors? We still need to think about what we can offer in return, but we can shift the deal in their favour if we reduce the investment required.

I believe that we can work to make contribution viable and more equitable, but this is a long game and there are no quick fixes.

In conclusion

Working on a design system can feel like an exhausting uphill battle at times, and I hope I’ve helped to shed some light on why that is.

I’ve spent the past 6 years working in this space, and I’m often struck with a sense of attempting an impossible task. No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.

But rather than continuing to swim upstream, stopping only now and then to complain about how hard it is, we can turn our attention to the current.

We can start to explore the forces that are working against us and ask ourselves why those norms exist and persist. It’s not because we’re doing a bad job - it’s because contribution is a socialist ideal that’s hard to establish and sustain in a capitalist system.

And none of that means we shouldn’t try.

We should try, and keep trying, because fair and equal contribution means representation. We aspire to it because it matters: representation matters, and so contribution matters.

So let’s face those challenges head on. Let’s see and accept those capitalist systems, and work to change them where we can. Let’s find opportunities for activism and learn when to work with the cards we’ve been dealt.

The task we’ve set ourselves is impossible.

Let’s keep going.

How to research components and design patterns

2022-08-09T00:00:00Z

I co-authored this post with Caroline Jarrett and
Ignacia Orellana

In our last blog post collaboration, we talked about how to share research in design systems. We explained why it matters and what designers and developers need from it.

In this blog post, we’ll describe 2 challenges that we’ve encountered when doing research on the individual components and patterns in design systems, and 4 ways of overcoming them.

The challenges: Unless they work on a design system, most people don't focus on components and patterns

When we're working on our design systems, we’re trying our best to make the patterns and components we provide the best they can be. And we know that means researching them with people - people who use the products that they go into, and teams who create those products.

But while those of us working on design systems are fascinated by improving our components and patterns, the people we need to research with aren't nearly as interested in them.

Challenge 1: Users are more interested in overall services than components and patterns

In order to test patterns and components with people, we have to put them into a service of some sort to create a context.

But the people using that service will typically be much more interested in the service itself than the (more subtle) details of patterns and components.

For example, Caroline worked with Kantar Operations to test some components in the context of a survey.

The research used an advertisement test survey, and asked respondents to share their reactions to an advert. The product team chose an advert for Muller Light yoghurt which featured cows running on a beach.

Respondents were happy to talk about cows and yoghurt in the research sessions, but they were somewhat bewildered by Caroline’s questions about the exact method of selecting an adjective from a list.

Image credit: Johnson, A., Coombe, R. and Jarrett, C. (2011) Usability testing of market research surveys, presentation at the European Survey Research Association conference, Lausanne, Switzerland.

Challenge 2: Teams are interested in testing products and services, not components and patterns

Another approach to test components and patterns is to find a team already using them in a service or product, and get them to do the research instead. After all, the teams creating products and services that happen to use your design system will be testing them with users all the time.

Quite rightly, though, teams will be focused on the research questions and hypotheses that are most relevant for their work - not yours.

This makes it easy to assume that components and patterns are working well - when in fact, problems might simply be going unnoticed.

For example, many service teams across the UK government researched dozens of services that used an older style of GOV.UK radios.

Example of the radio style used on GOV.UK services until 2016.

The Government Digital Service (GDS) team that looked after the components were not flooded with complaints from users, and nor did any designers or developers notice any issues.

But when the design system team observed research that colleagues were doing on their services, they discovered some problems.

They noticed that people with tremor or other conditions that cause poor motor control were struggling to point to the tiny targets.

They also noticed many people without a motor impairment were wasting time positioning their pointing device exactly on the target - not realising that the grey area was also clickable.

GDS has since updated the radios and checkboxes on GOV.UK.

Four ways to research components and patterns

Despite the challenges, we have found ways of researching patterns and components. So here are four ideas that we have found worked for us.

1. Make it clear when components and patterns need more research, so that developers and designers know what to look out for

Many design system teams would prefer to have every single component and pattern researched to a high standard before including it in the design system. But in our experience, that’s not realistic.

Sometimes decisions about what to include are based on instinct or design flair. Sometimes the need to ‘just get something out there’ is compelling. And sometimes we have a solution that works for one team but don’t yet know if it will work for others.

We’ve learned that being honest about this is a good way of getting teams who use our patterns and components to help with research.

The GOV.UK Design System approaches this by labelling components and patterns that need more research as “experimental”.

For example, this pattern for Asking users for Telephone numbers explains that “more research is needed to validate it”, and the pattern’s research section describes what research is needed.

The GOV.UK Design System's pattern for asking users for Telephone numbers uses an experimental status to show that it needs more research to validate it.

The GOV.UK Design System's invites users to share research on experimental patterns to help improve them.

Some teams will avoid using anything experimental, but others are glad to have something to start from and are willing to take on the task of doing some extra research in exchange.

2. Make it easy for designers and developers to share research findings - but don’t rely on it

Design system teams that have opened their design systems for contributions and feedback might be able to encourage teams to share what they’ve learned through testing.

We’ve seen through user research conducted with designers and developers that the main barriers to contributing are a lack of:

time
confidence
motivation
permission

If you want people to actively share insights, work to remove as many barriers as possible from your contribution process. Make it as quick, straightforward, rewarding and accessible as you can.

When a designer or developer does notice a repetitive problem, and takes it upon themselves to tell you about it, celebrate!

Try to make dealing with that issue a priority. If you can’t, then give them a clear indication of how valuable the insight is, and how soon you will be able to get to it. Whatever you do, don’t let that insight just disappear without any follow-up - that’s disappointing for the person who made an effort for you, and will discourage them from contributing again.

Ultimately, the responsibility for stress-testing components and patterns falls on the team that builds and maintains the design system - not the teams who use the design system. So although we definitely recommend that you encourage teams to contribute, don’t rely on contributions as your only source of research.

3. Attend teams’ user research sessions so that you can see how people use the components and patterns yourself

In our previous post, we mentioned the value of observing research that’s happening anyway, so that you can see for yourself how a component or pattern is working.

Teams are often glad to have an extra observer, especially if you volunteer to take notes for them. Many teams also appreciate an opportunity to spend a bit of time sharing experiences and questions about the design system.

Being at the testing session means that you can focus on how the component or pattern is working, while the team focuses on the service or product as a whole.

The only disadvantage of this approach is timing. The team creating the service or product will do research when it suits their deadlines and timetable, and that may not line up with your work on your design system. But this information is valuable - so it’s worth being as flexible as you can with your timings.

4. Create a fictional service for research purposes, to test your components and patterns

If there’s no real service or product where the deadlines line up with yours, then you can try building a service solely for research purposes. The benefit of this fictional service or product is that it’s under your control. The downside is working out how to make it feel realistic enough to your users, without having too many distractions - like the cows and the yoghurt that we mentioned in our first challenge.

GDS colleagues built a prototype service called “Apply for a Temporary Event Notice” to research some new components and patterns. It was based on a real government service - but one that wasn’t actually available online at the time.

This meant it would appear realistic to research participants, but had been carefully designed around the design system team’s research questions.

For example, the prototype included a character count component, and one of the research goals was to learn how users responded when they exceeded the character limit.

To test this, the team set an intentionally low character limit for one of the answer fields. This meant that most participants exceeded the limit, and the team could observe their response.

Do the research - and try more than one approach

Doing research on individual components and patterns is certainly challenging - but it’s a problem worth solving: Design systems that are grounded in research help teams to trust and use them, and lead to better user experiences.

Each approach to researching components and patterns has its pros and cons, so it’s best not to rely on just one.

Enlist the support of teams using the design system by making it as easy as possible to report relevant research findings. This includes being clear about research gaps, so teams understand what to look out for.

To get the best from observing research being done by a product or service team, be respectful of their timings and adapt to their needs.

Finally, don’t rely solely on second-hand research from teams using components and patterns in their services. Be proactive and creative, designing research that removes unnecessary distraction and helps answer the right questions.

Use the active voice to transform your design system documentation

2022-07-29T00:00:00Z

One of the most common pieces of feedback I give to design system teams about their documentation is this: write using the active voice.

In this post I’ll explain what the active voice is and why it matters.

What is the active voice?

Unless you write for a living, then trying to recall the difference between active and passive language from high school English class might be a bit like asking someone like me - that is, not a mathematician - to recite the Pythagoras theorem. So let me explain.

The active voice makes it clear who is doing what.

For example, “You are reading this blog post” is active, whereas “This blog post is being read” is passive.

Examples of the active and passive voice

Let’s look at some examples of how active and passive language might appear in design systems.

Active voice	Passive voice
You can use an icon with this button, instead of a text label.	Icons can be used with this button, instead of a text label.
The design system team reviews contributions against the component acceptance criteria.	Contributions are reviewed against the component acceptance criteria.
We last reviewed this documentation in October 2021.	This documentation was last reviewed in October 2021.

How using the active voice improves design system documentation

There’s lots of research to show how using the active voice makes content clearer and more readable in general.

Organisations that recommend using the active voice include:

And there are some specific benefits to using the active voice in design systems.

The active voice is easier to read and remember

If you’ve ever watched someone trying to install or use a design system in user research, you’ll know that getting people to read your documentation at all is no mean feat.

When we’re writing for busy designers and developers, it pays to do all we can to make our content as easy as possible to digest.

Research on whether the active voice is always easiest to read is mixed.

But my first-hand experience of observing people reading documentation in user research says that it's generally easier to parse - and there's some evidence to support this.

Jan Spyridakis, quoted in the GOV.UK Content Manual, explains:

"Not only do readers move more quickly through active voice text, but they prefer it and feel more familiar with it. Readers may even encode passive voice text in active voice."

Instructions written in the passive voice are easy to miss

A huge benefit of using the active voice in documentation is that it removes ambiguity about who needs to do what.

"The spellcheck attribute must be set to false on email address fields" gives no information about whose job it is to do that.

Passive statements about things that need to happen are easy to overlook. Instead, we can use the active voice to give a clear instruction:

"Set the the spellcheck attribute to false on email address fields" tells a developer reading the documentation that this is something they need to do.

Writing in the active voice encourages us to be more specific

Writing passive sentences lets us avoid giving details and making specific commitments. This, in turn, makes it easy to unintentionally break our promises.

For example: "Your pull request will be reviewed within a week" doesn't say who will review the pull request.

Making this sentence active forces us to assign someone - or a group of people - to the task. This helps design system users to keep us accountable, and builds trust.

In my experience, this often prompts important conversations about whether the commitments we're making are actually realistic, and make necessary adjustments to our processes.

Want to learn more about writing for design systems?

I’m putting together a half-day, online training course on how to write clear documentation for design systems. I’ll be running it later this year.

If you’re interested in attending the course, email me at amy.l.hupe@gmail.com and I’ll add your details to a waiting list.

Design systems for humans

2022-07-27T00:00:00Z

This post is based on my recent talk, Design Systems for Humans, from this year’s UX London. I’ll add a link to the recording once it’s available.

Something I’ve noticed in the past couple of years is a narrowing of our definition of design systems.

That definition tends to encompass the most visible parts of our design systems - the artefacts, tools and processes involved.

You’ll see that most conversations about design systems today centre around our component libraries, our documentation, how we integrate our systems with design tools, and our contribution mechanisms.

And whilst these things are usually critical to how we cultivate effective design systems (today at least), what concerns me is that we tend to focus on them at the expense of the human impact.

So let’s dig into that.

The human side of design systems

To talk about the human impact of design systems, we first have to think about the actual humans that this work touches.

I think it’s helpful to start by thinking about 4 groups:

the people who create the design system
the designers and developers who make our products
contributors to the design system
the people who use the products our organisations make

Let’s look at each of those groups in turn, thinking about how they operate within our design systems, and how it impacts them.

People who create the design system

Design systems are usually built and maintained by an individual or a team. They might be doing this as a full-time job, or as part of a different role.

I’ve sat in this group 4 times now. I’ve been lucky enough to work with some really brilliant people, but let me tell you: the work never stops being challenging.

And one reason for that, I think, is that we tend to significantly underestimate the work involved in creating and maintaining design systems.

Working on a design system: expectation vs reality

When we talk about the journey of establishing a design system, we often describe a linear, simple process.

Teams start off working in silos, until someone spots that a lot of repetition is happening
A design system team is hired to create a single source of truth
After a bit of time, version 1 is released

For some people, frustratingly, the journey ends here.

Even those of us who recognise that the work continues beyond v1 often envision that work happening as a set of predictable delivery cycles.

But this process doesn’t account for the many challenges, interruptions and curveballs we face along the way.

For example:

the many team-level component libraries that pre-date our design system, and have to be reconciled first
the teams who choose not to use our design system
local libraries that consume our design system and have to be maintained
company rebrands that derail our roadmap and necessitate us to pivot and release v2
teams that can’t keep up with our release cycles, and end up falling behind

Then there’s the endless title wave of design system user demand that engulfs most design system teams post-launch: “Can we have a progress bar?”, “This card component doesn’t have the layout I need”, “This third-party agency is using different branding - how do we reskin this?!”.

Before I depress everyone too much, let me be clear: None of this is unusual, none of this is bad, and none of this is wrong.

The only thing that goes wrong here is that we often go into the process of establishing design systems expecting something different. We put all of our focus onto the moment we release version 1.

When we over focus on creating the artefacts and the most visible parts of our design systems, everything else feels like an interruption. These challenges are not going to go away - they’re just part of the work. But what if we started to think about design systems a bit differently?

If we could account for these obstacles within our design system definitions, we might just start to feel less like we’re fighting a battle, and more like we’re on a journey.

The designers and developers who make our products

As I touched on in the last section, not everyone will choose to use our design systems - and that’s who I’ll focus on here.

When teams don’t use a design system, it’s usually not about ego

In every organisation I’ve worked in and encountered - no matter how much work goes into creating the design system - some teams will decide to do their own thing.

When this happens, we tend to dismiss it as ego. We wave it away as vanity - ridiculing people for suggesting that our design system might stifle their creativity.

But I think that’s reductive. I think it’s become a handy caricature that we use to lump together all the people who treat design systems with suspicion - even if that suspicion is justified.

And I think the reality is more complex.

Why people don’t use design systems

A few weeks ago I was listening to a podcast on leading with purpose in the digital age. Brene Brown was interviewing Dr Linda Hill, a researcher, professor of business administration, and chair of the Leadership Initiative at Harvard Business School.

Dr Hill described working with organisations who invest in new organisational data systems only to find, 6 months or a year later, that no one’s actually using them.

She invites these organisations to think beyond the practical work of getting the tools in place, and consider what mindsets and behaviours their employees need to have to know how to work with them.

I think we often don’t ask ourselves what kind of mindsets and behaviours the designers and developers we’re building the systems for will need to have to know how to work with it.

People won’t use a design system if they think it:

will create work for them
doesn’t meet their needs
isn’t meant for them
threatens their job

These are not character flaws - they’re barriers we have to work through with them to make sure our design systems get used.

In short, we can’t just build design systems and expect people to use them: we have to change mindsets and behaviours on the way.

Contributors to a design system

Designers and developers working on product teams are the ones working most directly with our organisations’ customers,

So by allowing them to contribute, we can make sure that the design system is representative of the needs of the audience it serves.

Or at least, that’s the idea.

It’s definitely true that contribution has the potential to make design systems more representative.

But what happens if all the people who contribute look like this?

In most design systems I’ve worked on, there has seemed to be a lack of contribution from people of colour - particularly Black people, from white women, non-binary and trans people, from really anyone who didn’t look like this.

Contributors have tended to be white men, in technical roles - either developers, or designers who are comfortable coding.

More often than not, they are also the most senior and experienced members of their teams.

Our industry as a whole has a diversity problem - so it might just be that most of our potential contributors are senior white men in technical roles.

But the thing is that most of our products’ users are not. So if we want to create design systems that ultimately serve their needs - we need to do better.

A good place to start here is by thinking about what people need in order to contribute, and the barriers we’re creating for them.

Barriers to contributing to design systems

When I worked on the GOV.UK Design System, we’d noticed a concerning lack of diversity amongst our contributors.

We did some research to understand more about why this was happening and what we could do to address it.

We discovered that people need 4 main things to be able to contribute:

time
confidence
motivation
permission

And although it didn’t come up in that research specifically, I’d also add accessibility.

What this shows is that it’s far too easy to introduce barriers when we invite people to contribute to design systems - unless we’re really intentional about understanding what they need and what challenges they might face.

For example, if people need time to contribute, one thing that’s almost certainly going to make it hard is if it has to be done in their spare time because it’s not considered part of their role.

Aside from people who aren’t up for working in their spare time - which is, you know, fair enough - this will disproportionately impact people who have caring responsibilities outside of work, like parents and carers.

So we can address this barrier by working with managers and discipline leads in our organisation to make contribution a recognised part of people’s roles. This gives people a more of an equal chance to contribute.

This is just one barrier, but if we start to investigate and dismantle them across our system, we can make it easier for people from all backgrounds to contribute - and this work is ongoing.

Inclusivity means continuously investigating the barriers people face when it comes to contributing, and doing the hard work needed to remove them.

People who use our organisation’s products

Our design systems are made up of components, patterns and content.

And as product teams start using them to build websites and applications, these things start to get scaled across our digital landscape.

But design systems are not just harmless scaling machines. Multiplying things has no inherent value, unless they’re things we actually want to multiply.

To explore this, let’s look at an example.

Example: How we ask for people’s names

Most design systems include a pattern, maybe even a specific component, for a name field.

But when I think about how a lack of diversity in our industry as a whole shows up in our work, name fields are one of the first things I think about.

And that’s because lot’s of us working in this space hold narrow and biased beliefs about names.

Time and time again, we see examples of people unable to enter their name into online forms. There’s actually a whole Twitter account dedicated to validation error messages on name fields.

And when I was collecting these examples, I was struck by a recurring comment made by people on the receiving ends of these errors: “This is the story of my life”.

When this happens to people again and again and again, we’re giving them a clear message: this is not for you. We become authors in that story of exclusion.

Are we creating systems of harm?

In reality, our design systems cover much more than just name fields.

Because although our design systems might sometimes seem like harmless scaling machines, we’ve got to start thinking about the human impact.

What happens if our components are inaccessible? What if our patterns are discriminatory, or our content is exclusionary?

What happens is we create a system of harm.

We industrialise discrimination, and set up a production line which lets us ship exclusion to the people using our products: quickly, consistently and at scale.

Reframing design systems

It’s my opinion that we need to reframe design systems, focusing less on artefacts and processes, and more on the people involved and the impact our systems have on them.

And I know that sometimes the suggestion of redefining design systems can make people wince. But I want to stress that I’m not talking about starting again - I’m talking about expanding.

I’m proposing that we broaden our definition, our perspective and our approach, to account for the human side of this work.

I really believe that if we move in this direction, we’ll end up with design systems that are better, and stronger, and kinder, because they’re more human.

Crediting contributors in design systems

2022-07-25T00:00:00Z

When we talk about how to incentivise design system contribution, something that comes up in almost every discussion is accreditation: Can we recognise design system contributors with a public acknowledgement of their work on a component or pattern? Or can we award individuals a contributor “status”, by naming them in design system documentation, putting their picture in a digital wall of fame, or sending them a sticker?

Such solutions are seductive in their apparent ease and lack of contention. Formally acknowledging someone’s work takes little time, is free to do, and is surely an attractive promise to prospective contributors.

But in these conversations I often find myself playing the role of spoilsport. Because although I believe, strongly, in making sure people get credit for their work - I also find myself wrangling with complexities that don’t often get talked about.

In this post I’ll give a rundown of some things to consider when crediting contributors, and why it’s more challenging than it might seem on the surface.

1. What constitutes a contribution?

In his article, defining design system contributions, Nathan Curtis explores different types of contribution on a scale. These range from small updates - like bug fixes - to small and large enhancements, all the way through to whole new features.

He also makes a case for distinguishing between “contribution”, which results in tangible, recordable change, and “participation”, which influences the system but does not directly change it.

(I have a slightly different take on this, but that’s another post for another time!)

Whether you agree with Nathan’s definition of contribution or you follow a different model, one thing is clear: When thinking about crediting contribution, we must first be clear about what we consider it to be.

And if our definition includes different types and levels of contribution, how do we reflect this in our attribution?

Do we credit people in different ways based on the size of their contribution? Should the size and significance of a contribution be based purely on the impact it has on the system, or does the effort of the individual or team count for something, too?

For example, based on system impact alone, we might decide that a single-line-of-code bug fix from an experienced developer is equal to a typo correction from a content designer.

But what if, to correct that typo, our content designer had to learn the basics of markdown and GitHub to be able to open a pull request? Do they receive the same level of acknowledgement as the developer who could make their update in a matter of seconds?

Or what if fixing that bug, with that single line of code, required several hours of research from our developer? Is it fair to represent their input as equal to fixing a typo, which required nothing more than a keen eye and a spell checker?

I don’t think there’s a perfect answer here, but in some ways that’s the point: fair and effective attribution requires us to engage with this nuance.

2. What if someone doesn’t want their contribution acknowledged publicly?

This is one we don’t often consider. The majority of contributors appreciate attribution, which can lead us to thinking that this position is universal.

But over the years I’ve encountered several people that didn’t want their name attached to a contribution because, for example:

they worked on it under the radar, without their manager knowing
the change was potentially contentious and they feared a backlash
they didn’t use social media and felt uncomfortable with the idea of people discussing their work on Twitter where they wouldn’t see it
they felt shy about receiving “a fuss”

In reality, there’s likely a myriad of reasons why people may not want their contribution recorded. Taking a fair and human-centred approach to crediting contributions means doing the work to understand preferences on a case-by-case basis.

3. How does a design system team protect contributors?

As I touched on before, some contributors fear criticism from the design system’s users once their work has been published - and that anxiety isn’t unwarranted.

If you’ve worked on design systems, you’ll know that it’s common to receive feedback - both constructive and… not so constructive - on the enhancements and features you release.

When that feedback is levelled at those of us in the design system team, we usually recognise it as something that comes with the territory. We share responsibility as a team, and we work together to decide on our response.

But when criticism is directed at the work of an external contributor, we’re in muddier water.

It’s easy enough to establish a policy that the design system team accepts responsibility for whatever gets into the system. We can agree that it’s our duty to respond to negative feedback, and to manage the consequences of anything the system releases.

But in practical terms, this can be hard to govern. Unless we wholly own all the channels of communication used by the systems users and contributors - and for many design systems that includes general design and engineering Slack channels, open repositories on GitHub, and even Twitter - it’s hard to reliably shield contributors from negative feedback, or manage their response.

And to demonstrate how this can escalate: an example.

A design system team I once worked on used an open source repository on GitHub to host discussions about current and upcoming patterns and components. One such discussion occurred on the subject of how to ask users about their gender.

Following suggestions and research shared by a trans person about how to better support trans users in answering this question, we updated the pattern. This unfortunately triggered a number of critical comments which, though not explicitly abusive or transphobic, amounted to disrespect, erasure and harm to the contributor and other trans users of the design system.

We acted quickly, but damage and harm had already been done to our contributor - and we couldn’t reverse that.

This is arguably a stress case, but it’s one worth thinking about when considering how attribution can go wrong, if we don’t proactively plan for worst case scenarios.

4. If a contribution evolves beyond the original author’s intent, should it still be attributed to them?

A final point to consider is how to maintain accreditation over time.

Consider this scenario: Someone contributes a design pattern for letting users select a country. Their design uses a dropdown menu (a select) to let users pick from a pre-defined list. We include their name and avatar on the pattern’s page in the design system website.

After the pattern is released, another team tests it and learns that users are struggling with the pattern, and find that using a text input with autocomplete works better. They contribute this update to the design system and the pattern is changed.

At this point, we have a few choices.

We can leave the original contributor’s details on the pattern. This acknowledges that their input was an important part of the pattern’s evolution, even though the implementation is different from what they proposed.

This may be the most equitable option, but it could be misleading. What if the original contributor disagrees with the new implementation? In that instance, their name is now attributed to something they don’t believe in. On the other hand, is it fair to credit someone for a solution they didn’t actually come up with?

Deciding to remove the original contributor’s details presents problems, too. Whilst doing so might be more accurate in terms of the system’s current implementation, it effectively erases their input.

Would we have discovered and included an alternative pattern, if not for the original contributor’s effort in producing and publishing that first pattern? Is it fair to cut them out of the picture, when they played an important role in the pattern’s development?

To some degree, these issues can be resolved by taking care to go beyond simply slapping a name and an avatar against a contribution, and providing context about the specific part they played. But it does require consideration, and makes it difficult to neatly automate a solution.

Crediting contributors is complicated, but critical

I want to finish this post by making something crystal clear:

None of the challenges I’ve discussed should merit not crediting contributors.

Attribution is an important currency between design system teams and external contributors. Making sure people get recognition for the work they’ve done is part of what makes our design systems fair, representative and worth contributing to.

But it’s important that we engage with the complexities and nuances I’ve discussed here, to make sure our approach is responsible.

If you’ve found a great way of crediting contributors, I’d love to hear from you. You can email me at amy.l.hupe@gmail.com or get in touch on Twitter.

Why it's time to update our language about bad design patterns

2022-07-01T00:00:00Z

Content warning: Racist language

This post discusses a term that’s commonly used to describe design patterns that cause problems for users. For the sake of clarity, I have used the full term once, at the beginning of this article.

There’s been an increasing number of conversations on my Twitter timeline, lately, about the term “dark patterns”.

The term was originally coined by Harry Brignull. He used it to describe tricks used in websites and apps to make people do things they didn't mean to - like subscribing to a service or signing up to receive marketing emails.

Since then, lots of us in the tech and UX industry have used the term to describe other kinds of bad design patterns, too. These include patterns that:

are hard to use, like captchas or selects
are confusing, like text inputs that provide a single line for users to type on top of, rather than a border that encloses the whole input area (thanks to Google for this one)
are inaccessible for disabled people, or people using certain assistive technology
exclude people, like gender form fields that don’t include options for transgender people

Thanks to industry leaders like Candi Williams and Jack Garfinkel, I’ve learned that this term has racist connotations, and it’s time to retire it.

Why calling design patterns “dark” is racist

One of the common responses I’ve seen to people calling for a change in terminology is:

‘The word dark is a common adjective. Does that mean I can’t say things like “dark night”, “dark chocolate”, or “dark mode” anymore?!’

The answer to this is no, it doesn’t.

The problem with using the term “dark” in this context is that it’s used to mean “bad”. Intuit’s guide, Abolish racist language, explains the issue in more detail:

‘Language that puts a positive connotation on white/light and a negative or mysterious one on black/dark reinforces anti-Black and colorist stereotypes. We choose more direct language to get our point across. We only use these words as literal visual descriptors (such as dark mode), not value judgments.’

More descriptive terms are better in general

The fact that Black folks have told us that our language around bad patterns is harmful is enough of a reason to change it.

But it’s worth pointing out that it’s also not a particularly descriptive term.

In many of the discussions I’ve seen on this issue, people have suggested alternative catchall terms to describe patterns that cause problems, like “anti-pattern” or “bad-pattern”. But I think we can go one step further.

In the introduction to this post I shared 5 different ways that patterns can cause problems - and that’s not an exhaustive list.

Updating our language gives us an opportunity to be clearer about what we really mean, and have more nuanced discussions about sub-categories of bad patterns. For example, we could talk about:

deceptive patterns (this is the option now favored by Harry Brignull, who coined the original term)
inaccessible patterns
confusing patterns
discriminatory patterns
exclusionary patterns

All of these terms provide more detail, and help people to understand more about the specific problem we’ve encountered with a solution.

A word on discussing harmful terminology

One of the reasons I wanted to write this post was to try and alleviate some of the pressure on my Black friends and colleagues to keep explaining this issue.

I hope that my explanation has been clear, and has convinced you to change your language when it comes to design patterns.

I’d also like to make another request. If someone from a marginalised group tells you that a term you’re using is racist, misogynistic, ableist, transphobic, homophobic, or causes any other type of harm to them: trust them.

If you don’t understand their reasons, carry out your own research into the origins of the term, rather than asking them to explain it to you. Listen, rather than becoming defensive.

Forcing people to qualify their lived experience of discrimination layers more harm on top of what they’re already experiencing. It’s painful, exhausting and unfair. And for those of us working in UX, it goes against one of the guiding principles our industry purports to stand for: inclusion.

Evolving towards kinder language

Learning to change our language can take time. Retiring terms we’re used to can feel jarring at first - especially if we didn’t spot that they were problematic in the first place.

We can give ourselves and each other grace when we make mistakes - as long as we remember that intent does not erase impact.

But contrary to the often-uttered outcry that “you can’t say anything anymore!”, I'm heartened and hopeful to see us consciously examining and evolving our language.

As the wise and wonderful Candi Williams said on Twitter:

“Words do not just have one fixed definition throughout time. The Oxford English Dictionary adds, removes and evolves the definition of words constantly.

Language is laden with connotation and words do not just hold a singular, binary meaning.

Our language shapes how we see the world. So, our language choices and considerations matter. Always.”

Acknowledgements

This post is largely just a summary of what I’ve learned from others. Special thanks go to:

Candi Williams and Jack Garfinkel for sharing their insights, and calling my attention to the problem with our language around patterns
Intuit for their wonderful guide on Abolishing racist language - which is an excellent resource for content designers and those of us working in UX to learn from
Tatiana Mac, whose work has taught me a great deal about using inclusive language, and the role of design systems in perpetuating exclusion

How to share research in design systems

2022-06-01T00:00:00Z

I co-authored this post with Caroline Jarrett and
Ignacia Orellana

“Use this because we said so” is not a convincing strategy for building trust with designers and developers who want to, need to, or are told to, use a design system.

“Use this because we’ve done research on why it works” is a more powerful argument.

In this post, we’ll describe the needs we discovered in our meta-research: user research with designers and developers about how they use the research that supports a design system - and what they need from it.

Then we’ll share some tips for how to incorporate research in your design system.

Good design systems rely on a lively community

A good design system relies on active contributions from the community of designers and developers who are using it in their work.

The community’s challenges, suggestions, and experiences help the design system’s team to keep it relevant, current, and, most importantly, heavily used.

Describing the research that has - or hasn’t - been conducted for design system components and patterns helps the community to make informed contributions to the system. It also helps designers and developers make informed decisions on what to use and how much further development or testing is needed for the context of their product or service.

Designers and developers want to see research for different reasons

Even the most obedient designer or developer is unlikely to accept the entire system as suitable for their work in every detail.

From our research, we’ve observed designers and developers in government having different reasons for wanting to see research on a design system. The ones we’ve heard the most often, expressed as ‘needs’, are:

I need to convince a manager or colleague to use this and I believe that research will help me.
I think the service or system I’m working from is different from the one the design system team had in mind. I need to understand their research so I can decide if their choice is likely to be appropriate for me.
I don’t agree with one of the things in this design system. I need to know what it’s based on before I decide whether to challenge it.
I’m going to use something from this design system and I need to know what gaps need filling, or what to watch out for, when using it in my service.
I need to see proof that this is accessible. I’ve been burned in the past by design systems that didn’t put enough effort into making sure that they would work for disabled people and for people who use access technologies.

Different needs often warrant different solutions. For example:

Information about the number of services or sites already using a component or pattern may be sufficient for the person who needs to persuade a manager.
Saying who took part in user research for a pattern and the service it was tried in may meet the needs of the person who has concerns about the component or pattern.
A description of the research that has happened can be a starting point for designers and developers who are planning their own research. This helps them avoid repeating work that has already been done.

Sharing research in design systems is challenging

These different reasons for wanting to see the research on components and patterns in a design system mean it’s hard to find a way of sharing it that suits everybody.

And even when design system teams know what research is useful to share, they might find it difficult because they:

lack the confidence to share what hasn’t worked
are reluctant to admit when research hasn’t been done
need to protect users’ privacy
are working in an organisation where there’s lots of variation in how people conduct and document research

It’s also challenging to research individual components and patterns. They usually need to be put into context to make sense, but this context can sometimes distract users and impact the findings.

We’re planning to write another blog post soon where we’ll explore this in more detail.

Decide on the right level of detail

Design system teams must balance the need to evidence design decisions with the risk of overwhelming users with too much information.

The “right” level of detail will vary based on organisational culture and on how busy people are.

For example, organisations where employees are expected to follow guidelines without question might not need to provide much rationale.

But in an organisation that encourages people to challenge the status quo and share responsibility for the overall quality of its products, employees may expect more information.

Someone in a hurry may only have time to grab what they need and go. They don’t want to have to wade through a pile of research to get there.

To support these different needs, a good approach is to:

stick to concise inline reasoning in component and pattern documentation
put more detailed research somewhere else

For example, in the guidelines for using a checkbox component, we might say something like:

“This checkbox has a touch target of 44px. Research shows this makes it easier for users who have issues with motor control to select it.”

We can then provide more detailed research in a separate place, for users who want to dig deeper. For example, in a research section at the bottom of the documentation page, or in a blog post that we can link to.

Use summaries and links

When deciding how to show research in your design system, be realistic. Let’s think about someone who wants to contribute research. We should consider:

how much effort they’ll have to put in
what tools they’re likely to have access to
how much time it will take them

A short summary of the research with links to more documentation (blog posts, articles, GitHub issues) lets people go further when they need to, without slowing down people who do not.

Be clear about what to aim for - but realistic about what’s achievable

We recommend a flexible approach. Aim for full research documentation where possible - typically for new additions and contributions. Accept that sometimes little or no research is available - typically, for older components and patterns where decisions were made some time ago and aren’t easy to trace.

When everyone knows how much research is expected for additions and changes and how to document it, it’s much easier to organise information and stick to what’s relevant.

For example, in the GOV.UK Design System team, Amy and Ignacia developed the following list of headings for research as “desirable”:

Who developed the pattern or component
Known issues and gaps
List of services using the component or pattern
Next steps (describing areas needing more research)

You can see an example of this applied to the ‘step by step navigation’ pattern, with all 4 areas described.

Sometimes, a design system team won’t have all that information. The GOV.UK ‘button’ component documentation, for example, has a much shorter research section. Nevertheless, we recommend having some evidence or rationale rather than none.

It is worth making the effort

Everyone involved in design systems - whether they’re a member of the team, a user of the system, or a contributor - knows that design choices are usually made based on a combination of:

research
design flair
let’s be honest - often arbitrary decisions made in the interest of ‘getting something out there’

A lively and questioning community of developers and designers helps to hold the design system team to account for their choices. This makes for a more representative, robust and reliable system.

If a design system does not describe the research behind components and patterns then it’s harder for a designer or developer who has concerns, or can’t find something they need.

Design system teams must give people the information they need to be able to ask questions, challenge choices, and put components and patterns in front of their users.

By being honest about what’s been learnt and what hasn’t, and what’s worked and what hasn’t, we can promote a more efficient way of working, and keep duplication of effort to a minimum.

This helps to foster a healthy culture of working in the open and encourages iteration. Allowing teams to collaboratively improve things over time.

Structuring documentation in multi-brand design systems

2022-02-18T00:00:00Z

I’m now working on my second multi-brand design system and am again facing the challenge of how to structure, write and present documentation for 3 different brands.

Let’s assume that at least some of what we provide is going to be brand-specific. This is usually the case if our brands are intentionally different, and we’re not trying to consolidate them into one.

2 questions we always face with multi-brand design systems are:

what's universal and what's brand-specific?
how do we present that information to the system’s users?

Here I’ll explore those questions, and how I’ve approached them with clients.

For simplicity, I'll focus this post on structuring that information in a documentation website.

I won't cover the documentation that lives in design and dev tools, like Figma, Storybook or GitHub - although I'll mention it at the end.

What's universal and what's brand specific?

This varies depending on the organisation and its design system’s goals, so it’s important to understand the context when exploring this question.

For example, a client I’m working with now includes several brands that were brought together in a merger and haven't previously been thought about as parts of a single entity. That means there are lots of differences that we have to deal with, but probably wouldn’t have introduced intentionally.

Stuff that's universal

In my experience, things that apply to all brands have included:

UX writing principles, for example, how to write error messages
relevant content styles, including grammatical conventions
accessibility standards and guidelines
guidelines on component structure and layout, for example, the order of form labels, hints, error messages and inputs
guidelines on component behaviour, for example, “don’t use inline validation on form inputs”
the steps (and their order) of common user flows, like registering, or signing in and out
content about the design system, for example, guidelines on getting started, contributing and getting support

Stuff that's brand-specific

Things that have varied from brand to brand have included:

voice and tone guidelines
context-specific content patterns, like the label used on a purchase button
how colours are used
certain design foundations, like typography, colours and use of imagery - I don’t see organisations differentiate spacing and layout as often
the way components are visually styled - like the fonts or colours used on a button or an error message

Taking the time to understand the overlaps and differences across our organisation's brands is an important step in deciding how to structure our documentation how to present it to users.

It’s also worth thinking ahead: does the situation we’re working towards differ from where we are today? If it does, how might we design our system’s documentation to support this future state, and to make sure it doesn’t constrain us?

How do we present this information to users?

When thinking about how we should structure and present universal versus brand-specific information to our users, my start point is always to ask: What do they actually need to know?

There’s certainly something to be said for keeping our documentation architecture consistent with the architecture of our frontend and design libraries. If components are organised into universal and brand-specific categories, it might be helpful to reflect that in the way we organise our documentation.

Then again, is this actually helpful for our users?

For example, if we know that most people who will be using the design system only work on one brand at a time, do they need to know whether a component is universal or specific to their brand? Do they need to know what components are available in other brands?

These are not rhetorical questions and we should explore them openly.

It’s useful to ask what information serves our system’s users, working to reduce noise wherever we can.

4 options for organising guidance in a multi-brand design system

1. A separate destination for each brand

At the extreme end, we could create a separate documentation site for each individual brand.

This approach might be useful if:

we know our users only ever work on one brand
our brands are very disparate and the documentation we need to provide for each one differs considerably

But - and this is a big but - publishing design system documentation to multiple places means maintaining that documentation across multiple places.

If we create completely separate destinations for each brand, we’ll probably need to provide some of the same information in each of them. In my experience, even when brands are stylistically very distinct, there are a lot of baseline principles and rules that don’t need to change.

And unless we’re using structured content to manage design system guidance from a single source - which is not something I see many teams doing today - the maintenance burden can quickly escalate beyond our capacity to keep up.

That’s why I favour publishing as much guidance as possible to a common destination, and only splitting information by brand where we really need to.

2. Let users choose a brand on the homepage

Another option we have is to organise our guidance by brand on our documentation site’s homepage.

This means most of our design system documentation will still live in brand-specific sections. But it does let us provide universal guidance about our system, like:

an introduction
installation guidance
information about the design system team
contact details
contribution guidelines

This is the approach we’re taking today on my current client’s design system, and my early observation is that we’re having to repeat a lot of information for each of our 3 brands - particularly in our accessibility and content guidelines.

3. Split some sections into brand-specific sub-sections

If certain parts of our system differ more than others across brands, we might choose to split some sections by brand but not others.

For example, we might conclude that our styles and components are different enough to warrant brand-specific sub-sections, but that our patterns can be shared.

4. Use in-page navigation to split some guidance into brand-specific sections

Finally, we could consider using some form of in-page navigation - like tabs - to provide some brand-specific and some universal documentation.

This means users see only the documentation that’s relevant for them. To bolster this, we could even ensure the default open tab is based on a user’s last interaction: If they selected Brand B on their last visit, we’ll make sure Brand B is the selected tab the next time.

From our point of view, it means we can decide whether or not to provide brand-specific documentation on an item-by-item basis.

This flexibility is particularly helpful if our design is changing - either towards or away from a consolidation of brands.

At the time I was working there, this is the approach we opted for on the BT design system.

Some downsides are:

tabs can be problematic from a usability and performance perspective
this doesn’t provide a neat solution in the case that 1 brand is an outlier, but 2 or more brands share guidance - although arguably that problem isn’t unique to this solution and isn’t made worse by using tabs

Beyond multi-brand: the many dimensions of design systems

I don’t pretend to have a perfect solution to this problem, but I hope this post has given you some food for thought.

It’s worth considering that I’ve only talked about multi-brand design systems here, but we also increasingly need to cater to:

multiple platforms, like web, native apps, voice and more
multiple localities with different languages
different tech stacks
various tools that interface with our system, like Figma, Storybook, GitHub and documentation sites

With that in mind, I believe the case is becoming clear for developing a content model to manage design system documentation and guidance.

If you’re exploring this already, I’d love to chat to you. You can get in touch on Twitter or email me on amy.l.hupe@gmail.com

Final thoughts on NaBloPoMo

2021-11-30T00:00:00Z

So here we are for the final installment of National Blog Posting Month 2021 (NaBloPoMo).

(If you’ve no idea what I’m talking about, here’s an introduction to NaBloPoMo.)

Here I’ll share some reflections and a roundup of the posts I’ve written.

Reflections

1. I did it!

I’m really proud of myself for sticking to the challenge. I wasn’t sure if I would, but I’ve managed to write and publish a new blog post every weekday this month.

I'm relieved it's over and ready for a break, but I'll seriously consider doing it again.

2. Writing every day is hard

I’m sure this comes as a shock to precisely no one.

The first week or so was relatively easy as I felt like I was working my way through a stalled backlog of ideas that I just hadn’t got round to writing yet. You may notice that my earlier posts are generally longer and more detailed—that’s because I’ve spent a bit more time thinking about them.

As the month has gone on, I found it harder to generate new ideas and often found myself getting to the end of the day with nothing written.

The great thing about this is that it forced me to prove to myself time and time again that I can come up with ideas even if I don’t have much time.

Thanks to a suggestion from Caroline, I decided early on to limit the challenge to weekdays and use weekends to have a break. I’m glad I did and I don’t think I would have finished it without that rule.

3. People connect with honest writing

Some of the posts I wrote this month were considered and analytical. Others were pretty personal and a bit more scrappy.

I found it was the posts I wrote on days when I didn’t have any obvious ideas that seemed to resonate most with people, like Rescue me and Just a job.

My theory is that those were the days where I wrote about the things that were top of mind and pushing to the surface. Or to put it another way, the things that were unconciously most important to me.

I think it shows that people connect with honest writing, and that there’s value in it even when you don’t have the time to refine and polish a post as much as you might like.

4. A commitment to writing is helpful

I have found it useful to have a reason to write. Having promised myself that I’ll share something every day has kept me producing a steady flow of content - something I’ve struggled to do in the past.

5. Everyday feels like too often for me

I think I’d like to stick with a regular writing practice, but with less frequency. Towards the end, I really missed having time to really work on things without feeling rushed.

I valued the nudge to challenge my perfectionism and share things even when I thought they could be better. But in reality, sometimes ideas do need time do marinade and unfold. I also felt like I didn’t have any time to research things—something I think is important when writing longer, more complex pieces.

There were certain topics I didn't want to touch in the second half of the month when I was in fire-writing mode. For example, I had an idea for a post about accessibility, but it felt irresponsible to write it without proper research, talking to disabled people and considering the impact of what I'll say.

That, along with some other posts, is on my list to develop now I've got a bit more time.

While I think there’s definitely a place for the kind of quick writing that loosens you up and frees you from over-thinking, there’s also a place for investing time, love and effort in your words.

My goal now is to find a healthy balance.

Blog posts

Read all the articles I wrote this month here.

Here were my 5 personal favourites.

Best laid plans

2021-11-29T00:00:00Z

In 1941, my grandmother—my Dad’s Mum—was at home celebrating her daughter Joanna’s 2nd birthday. In the middle of the festivities, a German fighter plane dropped a bomb on the house. Joanna was killed instantly and my grandmother was badly injured, narrowly missing a leg amputation.

On 1 April 1950, my other grandmother—my Mum’s Mum—was waiting for a taxi to take her to the church to marry my grandfather, who was nervously pacing while he waited for her arrival. The taxi, having been booked fairly last minute and on 1 April, assumed it was an April Fools’ joke and never turned up. My grandmother had no choice but to run into the street and hitchhike to her wedding.

In October 2016 I went to pick up a new kitten. He was the only boy in the litter and I’d chosen him from some pictures the owners had sent me. He had huge blue eyes, great big paws and a little white patch over one eye. I couldn’t wait to bring him home. I arrived at the house and was shown to the kittens. They handed him to me, and it was—on his part at least—disdain at first sight. He pushed his tiny paws into my chest with all his might, craning away from me and mewling desperately to be put down. I knew in my heart of hearts: this was not my cat.

In May 2020 I was in the middle of my first client contract and had just signed an extension for 6 months. I started to get unexplained pain and a rash on my neck and head and one day—without much warning—I became paralysed on one side of my face. I was diagnosed with a rare neurological condition called Ramsay Hunt Syndrome. I was told there was a 50% chance I wouldn’t get the movement in my face back, and had to quit my job while I recovered.

After nearly 2 years of this pandemic, on Friday, we received news of a new variant that’s left lots of us feeling scared, angry, and wondering if we’re going back to square one.

Accepting setbacks

When our plans go awry it can be a mild inconvenience, a difficult adjustment, or an excruciating blow that leaves you wondering “how on earth am I going to get through this?”.

When my plans are side-swiped I have a tendency to try and rush to acceptance. I feel like every second spent lamenting what’s happened is another second I’m not moving forward, into something new and more positive.

But here’s what I’m learning: Rushing to move past a setback and into plan B is not—as I often tell myself—an efficient form of acceptance. It’s a numbing strategy, intellectualising a solution to avoid facing up to the disappointment or the anguish of losing plan A. Thinking so we don’t have to feel.

And it doesn't work. Telling yourself something doesn’t matter doesn’t make it not matter. Pain has a funny way of demanding your attention one way or another—putting it off is just racking up debt on an emotional credit card. Eventually, you're going to have to pay.

I asked my friend—a therapist—what he thinks about acceptance, and what to do when bad things happen—and he said something that stuck with me: “Acceptance means you give yourself to yourself as you are.”

That means feeling the loss of plan A: whether that's losing someone we love who wasn't supposed to go, a wedding plan gone-awry, a kitten who patently hates you, an unexpected illness, or another twist in a relentless pandemic.

Acknowledging our reaction, whether it's what we'd choose to feel or not, is helpful. Why? Because it's an essential part of acceptance.

The good and the bad news is that there's always a next chapter.

The story continues

I’m not going to say that everything happens for a reason. Some things are just awful, and we’ll never be able to be glad they happened.

What I do believe is that life continues to unfold after its plot twists.

My grandmother whose daughter was killed in World War II was only ever going to have 2 children. After Joanna died, she had my uncle, and after my uncle, she had my Dad. If it weren’t for that night, neither he nor I would be here, and you wouldn’t be reading this blog post.

And my other grandmother—the one who hitchhiked to her wedding? She made it to the church. She married my grandfather and made the front page of the newspaper. They were happily married for 40 years before he died. They had 3 children and 9 grandchildren. She lived another 25 years, and regaled us often with the story of their wedding day over a glass of sherry.

As the kitten wriggled crossly in my arms and I silently wondered if I could reasonably adopt an animal who clearly despised me, my best friend crouched down behind me and picked up his sister. I turned around to see a scruffy, docile little black bundle sitting happily in her arms, with enormous whiskers and a signature white chin that made her look like she was frowning. She is now a 5 year old cat called Mabel, who purred all the way home that day and has been an enormous beating heart in our family ever since.

And as for my face, I slowly regained movement and am now pretty much back to normal. I took 2 months off to rest, read, listen to podcasts and sit outside in the sunshine. I realised work wasn’t the only important thing in my life and I learned that I’m tougher than I ever gave myself credit for, when I need to be.

I don’t know where we go from here, with this latest pandemic setback, but I do know that things will keep moving.

And if you feel bad today, feel bad. Feel sad or angry or scared or whatever it is you need to feel. Give yourself to yourself as you are.

Things will keep changing. Life will keep unfolding. We will keep going.

Worry time

2021-11-26T00:00:00Z

I’ve been thinking lately about how a lot of anxiety-management advice can feel quite vague. When people say things like “learn to accept your feelings”, I can grasp that in theory but struggle to know what it means in practice.

With that in mind, I thought I’d share a practical technique that I use when I’m feeling overwhelmed.

It’s an actual thing I learned in therapy, not something I made up, but I think there are variations on how to do it.

Here’s my version.

What is worry time?

Worry time is the act of setting aside time each day to let yourself worry about the things that are making you anxious.

For those of us who are prone to worrying and ruminating over and above what's helpful to us, it serves 2 purposes:

It allows us to postpone our worries throughout the day, safe in the knowledge that we'll get a chance to think about them at the designated time.
It can help us to worry more “productively”, recognising what we can and can’t control and planning to take appropriate action.

Postponing worries

An important part of worry time is postponing anxious thoughts that pop up throughout the day until worry time.

For me, this means writing them down in my bullet journal or my phone. If a lot of my anxious thoughts are on the same subject, I keep a tally of how many times they’ve come up.

Something I’ve learned is that it’s helpful to keep the descriptions of my anxious thoughts as brief as possible. This stops the act of postponing them becoming another way to get caught up in them.

For example, if I’m anxious about COVID-19, I won’t write “I’m anxious about catching COVID-19 and becoming really ill or having to isolate”. Instead I’ll write the minimum I need to remind me. For example, “COVID”.

The best time to worry

I’ve read that it’s good to try and do worry time at the same time each day. I think this is helpful, but not always possible.

Overall, I think it’s more helpful to have worry time than not to, so if I miss my designated time slot, I’ll just do it when I can.

The best time of day will be different for everyone. Personally, I’ve found the morning works best for me. I used to do my worry time at the end of the working day, but found that this left too much time throughout the day for my anxiety to accumulate. By the time 5pm came around, I’d feel really overwhelmed and found it hard to use the time constructively.

For me, having worry time in the morning means I feel I’ve “taken charge” of my anxiety before the day has started, which helps me feel more in control.

My worry time process

I typically allow 20 minutes for worry time, and no more than 30. I use a timer to make sure I don’t go over.

If I’m feeling very anxious and struggling to separate my thoughts, I’ll start with 10 minutes of free-writing. This helps me to pick out themes in my thought processes an gives me a clue about what my mind is fixating on.

When I get to the worry time, I open up a page in my notebook or a Google Doc and use the following 3 headings to write down my thoughts.

What’s on my mind

Here I make a bullet list of the things I’m worried about. I try not to go into too much detail, and just include a sentence on each.

What’s happening

I use this section to list:

external events that are impacting me
behaviours that are impacting my anxiety levels

For example, today I’ve listed that I’ve had a busy day of meetings, that I’m recovering from a cold, and that I’ve been doom-scrolling on Twitter and news platforms.

What I’ll do today

Here I list 3-7 things I’m going to do to try and tackle my worries today. This is enough to make me feel like I’m making a difference, without being overwhelming.

Often I’ll list the same things, like 10 minutes of meditation, going out for a walk, phoning a friend or family member for a chat.

Sometimes I can add more specific actions, like having a day off social media, or taking some vitamin C to help shift my cold.

The value of regular, time-limited worry

I find worry time a really useful way of helping me to step back and view my anxiety objectively, to recognise what’s impacting it, and to identify what I can and can’t control.

Doing it regularly stops me from overthinking it and worrying about getting it exactly right. I know if I miss something, I’ll have another go tomorrow.

Like any anxiety-management technique, worry time isn’t magic, but I’ve definitely found it to be one of the more useful tools in my arsenal.

If you decide to give it a try, I hope it helps you too. And if you have any questions, let me know and I’ll do my best to answer them.

Just a job

2021-11-25T00:00:00Z

A couple of years ago I was walking through London with 2 of my friends.

We were talking about what we’d done over the weekend, and I told them I’d had a busy one and had been able to completely switch off from work for the first time in a while.

I said, “Do you ever just have those moments that make you realise that work is just work, and it doesn’t really matter in the grand scheme of things?”

I’d expected emphatic nods and murmurs of agreement, but what I got instead were twin looks of confused panic.

“I don’t feel that way at all”, one of them said. She looked uncomfortable. “Work is really important to me”.

The other one agreed “Me too. I really care about what I’m trying to do…”

They weren’t being nasty, but it was clear that what I said had made them uncomfortable. Their reaction made me feel judged and a little annoyed.

It was only after a bit of time that I was able to see that conversation for what it was.

You see, that weekend I mentioned had come at a time where work felt all-consuming and kind of unrewarding. It had felt like an uphill struggle. I didn’t feel like the effort I was putting in was being recognised, and I needed that weekend to remind me that I was also a person outside of my work.

I found myself wanting to devalue work because it was making me feel undervalued, and I wanted my friends to reinforce that. Instead, their response reignited my fears that I didn’t matter enough in a part of my life that really mattered.

A few months later, I brought up that conversation with them, and told them how it had made me feel. To my surprise, they both remembered it straight away.

“Oh god!” one of them laughed. “I was having a dreadful time outside of work when you said that. Work was literally the only thing keeping me afloat.”

It turned out that, at the time of our conversation, they’d both been dealing with significant stress in their personal lives. For both of them, work was an anchor, and my declaration that it didn’t actually matter had made them feel stressed and attacked.

I see a lot of proclamations on Twitter about the position work should take in our list of priorities.

It seems like every other day someone’s telling us that if we’re not working evenings and weekends we’re doing it wrong or—on the other side of the argument—that jobs should just be jobs, reminding us no one in their dying moments looks back and wishes they’d worked more.

Maybe the problem is not to do with how much we do or don’t centre our work, but with trying to prescribe its respective priority for other people.

For me personally, work has been many things during different points in my life.

It’s been a burden and an anchor. It’s been a welcome distraction and a loathed interruption. It’s been a clock-watching exercise—at times when I couldn’t wait to finish for the day, and at others when I couldn’t bear to.

And we mustn’t forget that some people don’t get a choice. Having the choice to do something we find fulfilling and want to centre, and deciding how much time to dedicate to it, are privileges that not everyone has.

Likewise, there may be times when the other pieces of our pie charts are just too small, or too difficult, and allowing work to take centre stage is the only way we can cope with that.

Sometimes work is just a job. Sometimes it’s a lifeline. Sometimes it’s somewhere in between.

Perhaps for those of us who have the luxury of choosing, the best we can do is let work be whatever we need it to be, in this moment, and support others to do the same.

Sorry for the delay in coming back to you

2021-11-24T00:00:00Z

It’s just that:

I’ve been totally swamped at work
I’ve not been feeling well this week
I was having a panic attack
I’ve been thinking about how our society prioritises instant gratification too much and I’m busy writing you a letter
My cat required my attention
I like you an awful lot and I want to give your response the attention it deserves
It takes more energy to respond to your email about my subject of professional expertise than it does to subtweet Boris Johnson. This isn’t a reflection of my respect for you. Please don’t DM me to highlight this perceived inconsistency
I had something typed to you but I’ve just found it sitting in my drafts! Don’t know what happened there....
Someone needs me more than you right now
You sent me a detailed message and I need time to process it before I reply otherwise it’ll seem like I didn’t pay attention and I don’t care
I can’t quite get my head around the fact we’re still sending emails in the apocalypse
I really care about this response and I don’t have the bandwidth to write something that reflects that right now
My broadband went down
I needed to scroll through every eBay listing for a Shrimps coat
I was taking a lateral flow test for the 5th time today
~~I was talked into another wine~~ actually no, that’s a bit Live, Laugh, Love
Everything seems futile
I feel happy for the first time in a while and I wanted to spend those precious moments somewhere else
I was paralysed into inaction by the guilt of all the messages I haven’t responded to
I’m ~~a poor excuse for~~ a human

The middle ground

2021-11-23T00:00:00Z

I don’t spend much time in the middle ground.

When I’m faced with something that’s charged, weighty and complex, I’m often seduced by the idea of a binary: this or that, yes or no, right or wrong.

But binary thinking is limiting and often misleading. How can we challenge ourselves to break out of it, and discover creative solutions in the grey area?

Binary thinking is a distraction

For the past year or so I’ve been struggling with my mental health.

On bad days, I often catch myself thinking “Oh god, I hope I’m not going to become depressed or anxious again”.

But whilst there are diagnostic criteria that can tell me whether or not I meet the definition of “depressed” or “anxious”, the reality is transient and somewhat more blurry.

And although having a label can help with things like treatment access, on a day-to-day basis it's not actually that helpful for me.

Focusing on the question of whether or not I am depressed or anxious stops me from asking a more useful one: what can I do about how I'm feeling?

Binary thinking leads to inaction

Sara Wachter-Boettcher explains how binary thinking keeps us stuck with an example of how we—white people, especially—think about racism.

By imagining that we are either not-racist (good) or racist (bad), we act defensively, in a way we perceive is “safe”.

We avoid anything that might put us in the bad, racist camp, and if we conclude that we are not-racist, we may also conclude that our work is done and we don’t need to do anything else.

The problem, Sara explains, is that this stops us from thinking more critically about our behaviour as multi-dimensional, asking: “Where am I dismantling racist systems and where am I reinforcing them?’.

Limitations of the “two-sides” mentality

As well as causing us as individuals to get stuck, binary thinking can also create stalemate situations between people or groups.

I listened to a podcast recently, where Brene Brown interviewed relationship expert Esther Perel.

Esther explains how couples are often able to take strong opposing positions by disregarding the nuances in their own viewpoint—something she calls “splitting the ambivalence”.

For example, imagine a couple who’s considering getting a dog.

If one partner wants to get a dog, but the other is less keen on the idea, the partner who wants a dog may become more rooted in their position.

With their focus on persuading their partner that they should get a dog, they may set aside their own concerns about:

vet bills
who would will take the dog when they go on holiday
what happens when they’re both at work

The problem is that these concerns do exist and are valid, but by taking up opposing positions on either side of a binary choice, they are left unattended and unsolved.

We see this phenomenon playing out in group scenarios too, often with much more significant societal and political implications.

In Jay Caspian Kang’s New York Times article on Critical Race Theory, he discusses “binary consensus building”, which occurs when “people draw a line in the sand, oftentimes arbitrarily, and say that if you don’t align yourself completely with their solution [...] you must be sleeping with the enemy.”

Jay explains that creating a hard dichotomy between those who are for and against teaching critical race theory in schools has made it impossible for those who support it to challenge details of its implemetation, without a perception that they've "switched sides".

Binary thinking limits creative problem-solving

When we think about things in binary terms and create a dichotomy, we tend not to examine the weaknesses in our own position, or recognise the strengths in our opponents. We become more rigid and refuse to negotiate or compromise.

But the process of negotiation and compromise is often where solutions can be found—a point made by Adrian Rivera in his article, Just because you don’t believe in conspiracy theories doesn’t mean you’re always right.

The article discusses 2 opposing camps: conspiracists and reformists.

While the conspiracist “rants about shadowy schemes, nefarious figures, unseen hands and global cabals”, Adrian says, the reformist camp “preaches the gospel of rationality, a doctrine holding that even if all is not yet known, all is eventually knowable, and that if sensible rules are followed, chaos can be prevented.”

The 2 camps rally against one another at the expense of searching for solutions to some of the urgent global challenges we face.

Can we shift binary thinking with humility?

Adrian Rivera argues that part of the solution may be found in cultivating humility, asking:

“What would Covid messaging have looked like if humility had been built into the stories we told about masks and vaccines? If we had understood them to be highly effective preventive measures, rather than either silver bullets or ruses, would they have mutated into symbols, into sharp ideological lines dividing the nation?”

Perhaps if we were more humble and better at making room for our own position to be imperfect, we'd be better placed to recognise and prepare to deal with pitfalls.

Allowing multiple things to be true

There’s also value in challenging the binary in our language, finding opportunities to swap “but” for “and”. This subtle shift helps us move away from false dichotomies, allowing multiple things to be true.

To invoke another Sara-Wachter-Boettcher-ism, I like this example she shared last year on Twitter, on allowing space for our own suffering whilst recognising our privilege and helping others.

Rather than saying “I know I’m lucky in lots of ways and I’d like to do more to help, but I’m really struggling”, we can shift our thinking to recognise that we are finding things hard, and we have resources to help ourselves and others.

Over to you

I’m only just beginning to recognise the limits of my own binary thinking, and exploring ways to challenge it.

If you’ve got any experiences or thoughts you’d like to share on this subject, get in touch, I’d love to hear them.

Sprint to the finish line: becoming unstuck when writing

2021-11-22T00:00:00Z

If you’re anything like me, you’ll find yourself getting stuck from time-to-time, unable to move forward with a piece of writing or a presentation.

This can happen before you’ve even started, or somewhere in the middle, when doubts begin to creep in about what you’re trying to say and why.

The best way I’ve found to get through this is with a trick I’ve nicknamed “Sprint to the finish line”.

For me, the blockage usually happens because of a perfectionist voice in my head that says “don’t do anything until you can do it perfectly”. This very quickly snowballs into existential doubts about whether my original idea actually has any validity at all, and alarming thoughts of drastically changing tack (often when there isn’t time to do so).

What I’ve learned is that it’s actually the process of working an idea into a narrative that tells me whether or not it’s valuable. Trying to pre-empt that leads to overthinking, which in turn leads to paralysis.

So the idea of “Sprint to the finish line” is to go through that process as quickly as possible, and postponing evaluation and refinement until after you’ve become unstuck.

How it works

1. Acknowledge you’ve become stuck

This sounds basic, but it’s actually very easy to grind to a panicky halt, procrastinating and putting it off, without realising what’s happened. Identifying and accepting the fact you’ve become blocked is the first step to fixing it.

2. Recommit to your original idea

Remind yourself that you once felt compelled by the idea you’re doubting.

99% of the time, even if you’ve identified gaps and flaws along the way, the idea still holds value. The value might be different from what you first envisioned, but the evolution of your thinking is useful—for yourself and most likely for others, too.

Commit to seeing the idea through and trust that you’ll gain valuable insights along the way.

3. Get to the end as quickly as you can

The aim of this bit is to produce something you can critically evaluate and refine, so focus on getting it done, not doing it well.

If you’re writing an article, jot down messages as bullet points. If you’re working on a presentation, include placeholder slides with key words or phrases that capture what you want to say—you can flesh out later.

If you encounter any major questions or doubts along the way, make a note of them and keep going.

Above all, just keep going until you’re at the end.

4. Walk away

Take a break. Leave it overnight if you can. If not, go for a walk or do something distracting. The point of this is to give your brain a break and time to digest. It also helps you transition from creator mode into editor mode.

5. Edit your work

Now you’ve taken some time away, you can come to the much easier, more enjoyable and less daunting task of editing your work—in my opinion anyway.

I love Caroline Jarrett’s guide to editing.

Try to prioritise your improvements, placing most importance on the ones you must do before sharing your work (for example, turning memory-jogger phrases into full sentences, or adding images you’ve left placeholders for).

The best bit about editing is that you no longer have to overcome the hurdle of writing the thing—you already did.

From here, things can only get better (it’s OK if you sang this).

Over to you

I hope you’ll find the “Sprint to the finish line” method as helpful as I do.

Give it a try and let me know how you get on.

Rescue me

2021-11-19T00:00:00Z

When I was 7, I was in a car accident with my Dad. We were driving along the motorway to my uncle’s place, to help him move house. It was in January, back when we still had seasons, and it was a freezing day.

All of a sudden, my Dad shouted “Oh god!”, and my first thought was that we’d left something at home. And then he started turning the steering wheel very quickly, but nothing happened. And then the car started to veer to the left, and the last thing I remember before we hit the lamppost that knocked me unconscious was seeing road and sky and trees spinning, and then a hedge racing towards the windscreen. And then nothing.

When I opened my eyes I was lying on a sofa. A man who lived across the road from the crash had seen it happen and had brought me and my Dad back to his house to wait for an ambulance. I had a nasty concussion and my Dad had broken several ribs.

A few weeks later, in an unfortunate coincidence, I was in another car crash. Less serious this time, but bad enough to cave the front of the car in and shatter the windscreen. I was with my sister this time. The car in front of us stopped without warning and we slammed straight into the back of it. I couldn’t open the passenger door to get out, and my sister unclipped my seatbelt and dragged me out through the driver’s door.

I became scared of cars. I remember being with my sisters and their boyfriends one day and we pulled up outside a shop and I got out of the car and started screaming - I just suddenly didn’t want to get back in. They took me home to my Mum’s house, and she ran me a bath and gave me some clean pyjamas and hugged me on the sofa.

I’ve been thinking of those times a lot lately. The fear, the feeling that something terrible was about to happen, and the shaky aftermath.

But what I remember most when I think about those times was the rescue: The stranger carrying me across the field to his house; The paramedics gently explaining that we needed to come to the hospital to get checked over; My Dad tucking me into bed when we got back home; My sister pulling me out of the car and hugging me tightly to her at the side of the road; My mum enveloping me when I walked through the door sobbing after what I now realise was probably a panic attack.

After the past 2 years, I can’t be the only one who’s craving a rescue: A moment where someone says “it’s OK, you’re safe now, it’s over”. A moment of noticing that the danger has passed.

That moment, I’m afraid, isn’t coming. When the crisis has persisted for so long, and has been internal and external, it doesn’t work like that.

But here’s what I hope:

Perhaps in the absence of the rescue moment, we can create something more lasting.

A rescue that’s slower, and more subtle, and comes from within as much from without. A rescue that's tougher because it needs to be, to strengthen us for the challenges that lie ahead.

Not a sigh of relief but a slow, cautious exhalation as we look back at what we’ve been through and learn, finding our feet, and starting to turn outwards again.

Anxiety and the "right answer" fallacy

2021-11-18T00:00:00Z

I have a list of things to try when I’m feeling anxious. Things like:

Going for a walk or a run
Journalling
Talking to a friend or family member
Sketching
Meditating
Taking one of my meds
Reading
Listening to a podcast

The trouble is, when I’m overwhelmed with anxiety, deciding what to do to manage it can be an almost impossible task. This often leads me to freeze and end up doing nothing.

“Whatever you do, don’t get it wrong”

One reason for this is the belief that there’s a right answer hidden amongst them and the stakes for getting it wrong are high. Kind of like Deal or No deal for mental health.

“Make the wrong choice and prepare to feel even worse than you do now.”—a frightening prospect when you’re feeling awful already.

Another issue is that when I’m really anxious and my brain is racing, it’s often impossible to find a soothing thought. I try to imagine myself on the other side of doing the various things on the list and if I don’t imagine myself feeling better, I write them off as “wrong answers”.

But thoughts are great at lying to us and feelings are prone to following suit.

Anxiety is a pessimist. It’s there to protect, and when it goes into overdrive, it labels almost everything as a risk.

Just do something

The bad news is that when it comes to fixing anxiety, there’s rarely a silver bullet: a single option guaranteed to make it stop.

The good news is that knowing this can release the pressure of finding the “right answer”, and help us move forward with one of the options on our list.

And it doesn’t even have to be done well. “Do it badly” has become a useful mantra I use when I catch myself stuck in indecision.

In the end, doing something almost always feels better than doing nothing.

How to stop being anxious: a set of contradictions

2021-11-17T00:00:00Z

Be mindful. Focus on the present. Ask yourself if this problem will matter in 5 years’ time. Think back over your day and write down 5 good things that happened. Remind yourself you’ve been here before and you got through it. Tell yourself this will pass. Do all of this while staying present.
Sit with your feelings. Don’t run away from them. Write them down. Feel them. Distract yourself. Don’t navel-gaze. Take your mind off the thing that’s worrying you. Meditate on the thing that’s worrying you and allow the thoughts and feelings to wash over you.
Let yourself rest. Run! Burn off that anxious energy with exercise. Go for long walks. Lie down and read.
Sleep as much as you need to. Don’t nap during the daytime or you won’t sleep at night. Go to bed at the same time every night. Here are some stressful thoughts about sleep: Too much sleep is bad for you; A lack of sleep is bad for you. But don't get stressed about sleep: Stress affects your sleep.
Trust your gut. Follow your instincts. Also, feel the fear and do it anyway.
Greet your feelings like guests. “Welcome and entertain them all”, like Rumi said. But remember that feelings are just feelings and thoughts are just thoughts: they don’t control you. Honour all of your emotions equally. Choose happiness.
Accept the things you cannot control. Be the change you want to see in the world. Shoot for the moon, you’ll never know what you’re capable of until you try. Respect your limitations.
Don’t compare yourself to others: everyone’s path is different. You do you. Also, I fixed my anxiety and you can, too. Just do exactly this.
Take time for yourself. Embrace solitude. Resist the urge to withdraw. Do something for someone else. Put yourself first. Spend time with others. Spend time alone in nature.
Ignore your anxious voice. Befriend your anxious voice, it’s not the enemy, it’s trying to help you out. It’s making a pig’s ear of it though, so don’t let it run the show. Anxiety is just an overprotective friend. But you are not your anxiety - of course not! No one wants to be that guy. But listen to it and talk back to it. Kindly.

Above all, don’t overthink it. You'll make yourself anxious.

Mutant rat kebabs and the limitations of design systems

2021-11-16T00:00:00Z

Last week I watched Jennie Yip’s talk, Reimagining the Atlassian Design Systems, from Figma’s Schema 2021 conference.

In the talk, Jennie discusses the importance of setting expectations about what a design system is and is not responsible for.

For example, a design system can provide tools and standards to support teams in creating products. But they cannot guarantee good products: that’s the job of the product team.

To illustrate this, I’d like to share an anecdote with you.

Back in 2014 I was working for Which? Magazine, and we ran an investigation into the contents of lamb kebabs and curries.

We had lab-tested 60 samples of lamb curries and kebabs from London and Birmingham. We completed our usual due diligence, following stringent fact-checking and quality assurance processes before sharing our data.

Shockingly, 40% of the samples we tested contained meat other than lamb, and several contained no lamb at all.

When we published our findings, the Food Standards Agency launched its own investigation which eventually corroborated our findings, and began to crackdown on food contamination.

This was what we’d called for when we published our findings and what we’d hoped would happen. In short: a good outcome.

Around the same time as Which? published its story, several news publishers had reported sightings of larger-than-average rats on the London Underground.

The 2 stories had no relationship to one another.

However, in a somewhat astonishing move, the Daily Star proceeded to publish a story claiming that “mutant rat” meat may have found its way into the UK’s kebab supply chain. This was entirely unsubstantiated.

This was not what we’d called for when we published our findings, and not what we’d hoped would happen. In short: a bad outcome.

The moral of the story is this:

Build the best design system you can and be clear about how it should and should not be used, but recognise your limitations.

You cannot completely control what people do with the tools you give them.

The emergency exit only works if you use it

2021-11-15T00:00:00Z

I'm someone who likes to plan my emergency escape routes. If I’m going into a situation I’m uncomfortable with, I like to know how I’ll get out of it if I need to.

If I'm going to a party I'm not sure I'll enjoy, I like to have my excuse at the ready.

If I’m going abroad, I like to know exactly how I’ll get home if there’s an emergency. That’s one of the reasons I’m not ready to travel outside of the UK just yet. I know how easily my escape plan could be scuppered.

I have a box of antidepressants on my bedside table that I was prescribed back in April. I collected the tablets and never started taking them. Somehow I moved past needing them, but it helps to know they’re there, just in case.

When I started working as a contractor, I knew that every project I worked on would come with its very own in-built escape plan: the clause in my contract that says I can be out within 1 week if I decide to. That was part of the appeal: the emergency exit is right there.

But there’s a problem with this.

The trouble with knowing I can leave at any time brings with it an unspoken implication that goes like this:

“The emergency exit is right there, so what’s another day?”.

That notion, that having my escape hatch at the ready somehow nullifies the experience I’m having has got me into trouble, in the past.

It’s what kept me medication-free through the darkest days of depression and anxiety earlier this year. Sure, I came out the other side, but those days still happened, and I can’t get them back and they affected me in ways I can’t reverse.

And it’s what kept me working through months of unsustainable stress at the start of my contracting career until I burned myself out so badly that half my face stopped working. In the end, knowing I could walk away at any time became the main reason I didn’t.

I powered through with my attention so fixed on that exit door that I failed to notice my mind and body shutting down.

But I’m learning.

Today I am having a sick day. I’ve got a sore throat and an earache, and to be frank, I’ve been feeling low and anxious for 3 weeks now. I’m overwhelmed.

I’m working with an understanding client and I’m working from home. It would be easy to spend the day working from my laptop, knowing I could stop at any time if I started to feel worse: nap if I need to and make the time up later.

But today would still have happened. Knowing I can have a sick day is not the same as having a sick day.

Because the thing about the emergency exit?

It only works if you use it.

Design systems and structured content

2021-11-12T00:00:00Z

When people talk about design system documentation, they often mean:

values for design foundations, like colours, spacing and layouts
component specification, like size, spacing and behaviour
the system’s information architecture - how things are categorised and named

But not everything can be “baked in” and communicated through a token’s name, a component’s code, or an annotated visual.

Sometimes we can’t just show what we mean, we have to say it. I'll call this "usage guidance". It includes things like:

when to use a certain component or design element, versus another one
accessibility guidelines, like how to use semantic heading levels
how to write copy for the text elements in a component, like the label or hint text on a form input
relevant research findings
how to contribute
how to ask for support

For me, usage guidance is where the value lies. It’s where we tell people not just what to use but how, and why. It’s where we can communicate purpose and intent; helping to establish the values we adhere to, even if the specific applications of those values change.

Most design systems do provide usage guidance, but they’re often treated as secondary to the first set of things I mentioned—and that’s disappointing.

One system, many tools

Most design systems today include a number of different tools and platforms, for example:

documentation websites, built from scratch or using an off-the-shelf solution like Zeroheight
code repositories, for example, in GitHub
developer documentation tools, like Storybook
prototyping tools, like Figma or Sketch

By harnessing APIs and plug-ins, it’s becoming easier and easier to deliver design rules and component specs into these different tools from a single source.

This makes our design systems much easier to maintain.

It also means we can tailor what we deliver to each audience, which may differ depending on how much overlap there is (or isn't) between design and development in our organisation.

Are we forgetting about usage guidance in our multi-tool design systems?

While these solutions can help us show implementation details and configuration options, I can’t help but feel that usage guidance is being left out of the equation.

How are we going to manage that across different tools, so it can live alongside the component or style element it refers to, in whatever tool our audience is using?

Let’s use the example of a tabs component. We can create a single source of truth that shows developers in Storybook and designers in Figma:

how to style the tabs with the right colours and fonts
the size of the tabs
how the tabs change at different breakpoints
how the tabs behave on hover, focus, and when selected

But where do we explain that tabs can be a usability nightmare, causing users to miss content?

How about the fact that tabs probably work best in regular-use systems, where the need to efficiently switch between related information might be more important than simplicity of first-time use?

And what about guidance on how to write clear labels for tabs, which can’t just be hard-coded since we don’t know the context in which they’ll be used?

Our current solutions are inadequate

Unless you work in an organisation where designers alone make these kinds of decisions, and developers just implement them, this information is relevant for both disciplines. But currently, the best solutions we have for providing it in multiple tools within a design system are:

put in all in our documentation website, which may become less relevant and less likely to be looked at the more we cater to our users’ in-tool experiences
publish the same content in multiple places and update each instance every time there’s a change - a solution with huge maintenance overhead and that risks information falling out of sync

Neither of these solutions seems satisfactory. I worry that they’ll lead us to a place where usage guidance gets forgotten about, and our design systems turn into spec-libraries, devoid of context.

Could structured content be the answer?

Here’s the bit where I tell you I don’t really have an answer.

I’m a content designer thinking about a content problem, and I don’t yet know what’s technically possible, but one of the ways I think we could start to solve this problem is with structured content.

Structured content is content that has been broken down into its constituent elements, which are then categorised, tagged and named.

For example, if we were to take a structured content approach to our component usage guidance, we might break it down into:

Content element	Example
Title	Tabs
Description	The tabs component lets users switch between related sections of content, displaying one section at a time.
Installation guidance	To use the tabs component, you’ll need to import the component package from npm.
Suitable situations	Use tabs when users might need to switch between related sections of content and won’t need to view more than one section at a time.
Unsuitable situations	Don’t use tabs when users might need to view all of the content at once.
Implementation rules	Write clear labels to help users understand what content is included in unselected tabs. If the tabs contain content that needs to be looked at in order, arrange the tabs to support that. If not, organise them in order from most-to-least important, based on user needs. Don’t disable tabs—it’s confusing. If you don’t have any content for a tab, remove it.
Support details	If you need help using this component, email us at example@designsystem.org
Contribution guidelines	If you want to contribute a change to this component, open a pull request on GitHub

This is an over-simplified example, but hopefully you can see how structured content helps us think about what information is needed, independently of the constraints of the individual tools we’re using.

We’re effectively creating a content API that can be consumed by other applications.

We can then deliver whichever combination of those elements we think will be useful into the relevant platforms.

The potential benefits of this approach

This approach makes our design system's usage guidance easier to maintain and lets us tailor information to different audiences if their needs differ.

For example, we’d probably want to display the component title, description, support details and contribution guidelines everywhere the component appeared.

However, we could decide to only show the suitable and unsuitable situations to designers, if we know they’re responsible for choosing whether or not to use a component in the first place.

And we could decide to only show the installation guidance to developers, depending again on how people work in our organisation.

What now?

I don’t know if what I’ve described here has been done already, or if it’s even possible with the suite of design system tools most of us use.

However, I’d like to put usage guidance on the agenda for our discussions about publishing design system docs into multiple tools and platforms.

And if you’ve got any thoughts on this, I’d love to hear them. Contact me on Twitter, or email me at amy.l.hupe@gmail.com

Acknoweldgements

A big thank you to Heydon Pickering, Jen Lambourne, Luke Murphy and Michael Haggery-Villa for reviewing this article and providing generous and helpful feedback on it.

And thanks to Dave House who also reviewed it, and who helped me with the surprisingly challenging task of making the table above look acceptable!

Don't be afraid of the Big Long Page

2021-11-11T00:00:00Z

I co-authored this post with Caroline Jarrett

Long pages of content can seem daunting, so to make them look shorter, designers and developers often reach for things that hide some of the content, such as accordions, tabs, carousels or a “reveal” widget. We’ll call these things ‘content-hiding interactions’.

But hiding content doesn’t solve this problem, and often creates further difficulties.

Long pages aren’t inherently bad

A long page of content is not the same as “too much content”.

If people are confident that the content is going to be useful or interesting, then they are willing to engage with it and to scroll. Just look at how we behave on Twitter, or at the lengthy introductions on many recipe blogs.

When content is “too much”, it’s usually because:

it’s not what users are expecting
it doesn’t seem relevant
it’s too hard to read or to scan
it’s trying to cover too many things

Forget “the fold” but remember to start with the best bit

Another misconception is that users ignore content that sits below “the fold”. “The fold” originated with newspapers. Broadsheets are folded in half, so when displayed on a newsstand only the stories “above the fold” are visible.

In the digital world, we used to observe that people were reluctant to move “below the fold”, meaning the part of the page that was invisible until they had scrolled.

Nowadays, the amount of content they see depends on the device they’re using and whether or not they’ve adjusted the text size on their screen. If they’re using a digital watch, they may only see a few words. There’s no single fold to design for any more - it’s a myth.

It is true that users often pay most attention to information that sits higher up the page. That’s why it’s important to start with the most useful chunk.

Hiding content creates more work for users

Let’s look a bit harder at those content-hiding interactions - the accordions, tabs, reveals and other things that are often used to make long pages look like short ones.

Hiding content can give the impression of a less daunting page, but the penalty is that we’ve added extra interaction.

Some users will not know how to use the content-hiding interaction, or won’t notice it, and will end up missing the hidden content altogether.

Other users have limited ability to concentrate, perhaps because of an attention disorder, because they’re in a distracting environment, or because they’re stressed or in a hurry. Adding the extra step of deciding to deal with the content-hiding interaction gives them more to do, and threatens their concentration.

And to top it off: the content-hiding interaction may require JavaScript to work, which can impact page loading times and performance.

The content-hiding interaction is giving a false impression. It just swaps the default interaction (scrolling) for a more complicated one.

Instead of reaching for those content-hiding interactions - tempting when you’re thinking about interaction design - it’s time to jump disciplines and think about content design instead.

Plan and edit your content

Start by considering the scope of your content. Try to stick to one main message per page of content.

See if you can describe the main message in a single sentence, and if you can’t, that’s a good sign that you’re trying to fit too much on one page.

For example, here’s our sentence about this article: “We explain why using content-hiding interactions to shorten a page creates problems for users, and what to do instead”.

Look through the page to see what the messages are, then think about how relevant they are to your users.

Remove irrelevant information, then put the most important bit first and move less important messages further down the page.

You’ll have a shorter page and you’ll have users who are more engaged when their main need is met early on.

Try how to edit anything to get started.

Make content scannable and readable

If you divide your content into meaningful chunks then it will be easier to read and to scan.

Use clear, descriptive headings to help users locate what they need without having to read all of the content from top to bottom. We recommend making each heading into a mini-sentence.

Breaking up walls of text with paragraph breaks, bullet points and relevant images also makes a big difference to readability.

For very long pages, putting a list of links to the different sections at the top can help users who want to quickly skip to the information they need. There’s lots more advice on making content easier to read, try these plain language guidelines.

Test your Big Long Page with users

If your content still seems lengthy after editing and breaking up blocks of text, get your users to help you.

Testing a Big Long Page of content will help you to learn what’s needed and what isn’t.

For example, to discover whether a particular chunk seems useful or not, try some plus/minus testing.

And don’t just test your content once. Content might get updated and user needs will change. Testing your content with users periodically will help to keep it focused and stop unnecessary information creeping in over time.

Put your accordions away

What if you have no opportunity to change the content at all, and the only way you can make the page look smaller is with content-hiding interactions - the tabs, the reveals, the accordions?

Put them away and do nothing! Accept that the content is what it is. A long page, with or without content-hiding interactions, is a long page. Avoid adding extra interaction challenges to it.

Creating a coherent career

2021-11-10T00:00:00Z

My background is in content design, and most of my career has been focused on that.

Over the past 11 years I’ve spent:

6 years at Which?, working in publishing, moving through the roles of researcher, writer, editor and digital content creator
3 years at the Government Digital Service, working as content lead for the GOV.UK Design System
4 months contracting at Babylon Health as a product manager for their design system, before leaving abruptly due to illness
2 months doing sporadic freelance editing and copywriting while I recovered
9 months contracting at BT as product owner for their design systems
6 months contracting with Mace and Menter on 2 local NHS services

Now I’m working on design systems at Springer Nature. I joined as a content designer, but after discussions with my client about what they most needed, I’ve ended up doing more of the strategic planning I might have done as a product manager.

I’m so random - wanna hire me?

On the one hand, broadening my skills and experience is no bad thing. As a contractor, it means I can offer more services and consider a wider range of opportunities, which so far has meant a steady stream of work.

On the other hand, I started to worry that I was building a meaningless mish-mash of a portfolio. I feared that would put clients off, and I wondered how I would create a sense of purpose and cohesiveness for myself within this ostensibly random collection of projects.

So the big question I had was: can I find a common thread that allows me to explain to myself and others exactly what it is that I do?

Bringing order to chaos with a core perspective

Inspiration struck last year when I sent myself on a brilliant 6 week coaching course: Sara Wachter-Boettcher’s Courageous Leadership programme.

Sara encouraged us to think about our own triad of values, skills, and experiences, which we then used to come up with a short statement, which she calls a “core perspective”.

This was mine:

”I want to share the importance of open, inclusive communication and practices when building systems. I approach this work from my unique viewpoint as someone with relative power and privilege, who has experienced exclusion. I do this because I believe people can bring value and make positive change when they’re empowered to participate.”

Writing this core perspective helped me to see the common narrative in my career. It continues to help me to assess new opportunities by asking:

is this in line with my values?
will I find it meaningful?
will I be able to apply my skills and experience?

It’s helped me to avoid the temptation of roles that offer a good day rate but nothing else, or high-profile roles that I know would look good on my CV, but aren’t quite right for me.

I know it’s an incredible privilege to be able to make these choices. It’s one I know I might not always have, and that I’m extremely thankful for while I do.

Evolving my perspective over time

I expect and plan to revisit and update my core perspective statement over the next few years, as my values evolve, and my experiences (and hopefully skills) grow.

I actually made a tweak to my statement when I wrote this blog post. I changed “design systems” to “systems”, to make space for the work I did with Mace and Menter which I gained a lot from, and would like to do more of in future.

However, having a more stable concept of “what it is I do” helps me understand my purpose and values, and create meaning in my career.

Vegan recipes and cooking tips

2021-11-09T00:00:00Z

In January last year, I took part in Veganuary—a campaign which encourages people to eat vegan for a whole month.

Like a lot of people, I want to reduce my meat and dairy intake and eat more sustainably-sourced plant-based foods.

I also felt stuck in a bit of a food rut, and as someone who usually enjoys cooking (and, of course, eating), I wanted to see if introducing a constraint to my diet would help me find new meals and rediscover my culinary creativity.

It did.

Here’s a round up of my favourite recipes and discoveries from that experiment.

Vegan recipes round-up

Planet friendly bolognese from Gizzi Erskine’s Slow - as the book title suggests, this takes a while to make. On the plus side, the recipe makes a large amount and it’s great for freezing and using in pasta dishes, cottage pie, and other mince-based dishes
Jamie Oliver’s vegan shepherd’s pie - I like this because it’s not trying to taste like meat. It’s just a delicious, flavoursome and comforting vegan pie
Madhur Jaffrey’s mushrooms with chickpeas - serve with rice, naan, or in wraps with a dollop of coconut yoghurt. I like to add spinach
Meera Sodha’s scrambled tofu akuri - if you’re not sold on the idea of scrambled tofu (I certainly was not), this might just convert you
Burnt aubergine chilli hands down the best vegetarian chilli I’ve ever had (and I’ve had many) - we’ve made this over and over. Don’t worry if you’re not into aubergines - they melt away and you don’t really know they’re there
Buffalo cauliflower tacos - who doesn’t love tacos?
Yotam Ottolenghi’s french beans and tofu with chraimeh sauce - it’s all in the sauce which I immediately wanted to eat on absolutely everything
Dishoom’s jackfruit biryani - this is one of my favourite things to order in a Dishoom restaurant and I’m pleased to say the make-at-home version is just as good. You’ll need to swap the yoghurt, butter and cream for plant-based alternatives. The Dishoom cookbook gives suggestions
Rukmini Iyer’s lime and coconut dal - comforting with a kick, and very delicious

Other vegan cooking ideas

As well as specific recipes, I also found a number of tricks that helped us keep going.

Make a batch of salsa macha (a dark, sticky Mexican peanut and chilli dressing) and have it on everything
Pickles make everything more interesting
Nuts make most things more interesting
A couple of squares of dark chocolate in your (plant-based milk) porridge will change your life. Salted almonds on top will change it even more
After extensive research I can confirm that the H!p salted caramel chocolate is the best vegan chocolate around (not a spon)
I strongly advise you not to bother even trying with vegan versions of cheese*, yorkshire puddings, cream, eggs
*The exception to the cheese rule is smoked gouda but only when used in cooking, not eaten “straight”
Ben and Jerry’s Non-Dairy Phish Food ice cream tastes as good as the dairy version

Why you should prioritise quality over speed in design systems

2021-11-08T00:00:00Z

Last Wednesday I spoke at a Zeroheight design systems webinar with Josh Clark and Michael Haggerty-Villa.

At the end of the session, we were asked to share our most important piece of design system advice, and Josh’s answer stood out to me:

“Always prioritise quality over speed. Don’t inject crap into the arteries of your system, because you won’t be able to get it out.”

This resonated with me because it’s an issue I often encounter amongst design system teams I talk to and work with.

“That design system we didn’t know we wanted? We need it yesterday”

It usually takes several months (sometimes years) to build a business case for a design system and secure investment for a full time team.

However, almost as soon as that’s been achieved, something curious happens.

Historically-overlooked multiplication of effort—which those pitching the system have spent months hammering home to stakeholders—is suddenly seen as an intolerable problem which needs fixing urgently.

Product teams who were, until now, happily creating their UI without a system, are suddenly completely blocked by its absence.

“We need a design system and we need it yesterday” quickly becomes the organisation’s new mantra.

The result? That newly-hired design system team finds themselves suddenly crushed under the pressure and urgency of delivering something the organisation only just realised it wanted.

“Just hurry up and release some components - we can always iterate!” becomes the insistent cry of stakeholders from across the organisation.

Whoever’s heading up the design system team may suddenly find themselves in back-to-back meetings, explaining why the system isn’t ready yet and making wild guesstimates about when it might be.

The “Ship now, fix later” fallacy

In this environment, it’s perfectly understandable for a design system to bow to demand and start churning out subpar components in the hope it earns them some breathing room.

I’ve been a decision-maker on such a team more than once, and I’ll admit that’s what I did.

Under such enormous pressure, it’s easy to fantasise about future opportunities to go back and fix things. “Let’s just make things consistent, and then we can make them good”, goes the design system team’s new strategy.

But once they start scaling their system’s tools, content and supporting processes, the demand that’s already drowning them is only going to increase.

For a system to be successful, they’d do better to hold their ground.

Quality over speed saves time overall

We must remember that our design systems, when introduced, are not replacing nothing. They are replacing inefficiently-created, but often good-quality solutions: Solutions that have been designed by product teams in context and with thoughtful attention to their users’ needs.

Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.

When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.

We undermine teams’ trust in the system from day one by providing brittle and poorly-researched solutions.

We disappoint stakeholders who see teams choosing to continue working in silos over using an inadequate system.

The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.

Ultimately, when we prioritise speed over quality, we end up with neither.

What to do about it

To avoid this calamity, I offer four suggestions, depending on your context.

If you’re in the process of pitching a design system, exercise caution when emphasising the consequences and urgency of multiplied effort. Manage expectations and set realistic timelines against your KPIs.
If you’re a senior stakeholder who’s just commissioned a design system team, give them trust, time and space. Support them in pushing back on demand if they need to—you will get better results in the long run.
If you’re in the new design system team and are facing the situation I’ve described, resist the demand to rush out components as best you can. I don’t say this lightly. I know it’s hard, sometimes impossible—do what you can. Rushing your system will only create debt, and that breathing room you’re compromising for will probably never come.
If you already did rush out your components, slow down, go back and do it right. As the old Chinese proverb goes: the best time to build your system right was from the start. The second best time is now. (Or something like that).

Thank you to Josh Clark for inspiring this article and articulating this challenge so well.

A note on fairy lights on portaloos

2021-11-05T00:00:00Z

A house at the end of my road is undergoing some construction.

One side is completely demolished, and there are bricks and debris everywhere.

Scaffolding encases the entire house, peppered with empty bottles and sandwich packets betraying the builders’ fondness for an M&S meal deal.

The overall impression is, to put it mildly, one of complete and utter carnage.

The residents of the house are living there while the work is going on. I see them coming and going each day, brushing the brick dust off their coats before getting into their car. They look stressed.

Outside the house is a portaloo: a big blue plastic thing standing between the wall and the front window. Positioned as it is, it blocks any daylight threatening to enter the house.

As most portaloos are, it is ugly.

Yet.

Draped across the portaloo—wound around the railings and the branches of the hedge at the front of the house—is a string of fairy lights.

I noticed them for the first time a couple of nights ago when I went out for an evening run.

I run past this house often, and I tend to notice things like fairy lights as I’m sweating and swearing and lamenting my decision to exercise.

And because of this, there’s something I’m quite certain of: these fairy lights are new.

These.

Fairy.

Lights.

Are.

New.

What that means is that at some point, during the destruction and the dust and the seemingly relentless hammering of a pneumatic drill, someone in that house held their index finger triumphantly aloft and said: “I know what to do!”.

They travelled up into a dusty loft to fetch the fairy lights.

They stepped outside into the cold and the rain, and they wrestled those fairly lights around the railings, and through the branches of their laurel bush, and across the top of their portaloo.

They sourced an extension lead to plug them in, and fed it through a small gap at the edge of their front door.

They switched the lights on, and they stood back to admire their handiwork.

I pondered this.

“Why bother?” I thought crossly as my protesting legs propelled me past the house. “You’re living in complete chaos, your house is in ruins, the sound is driving me to distraction and I’m not living in it—and you’ve chosen to expend your presumably waning energy on illuminating a vessel into which multiple people defecate.”

I won’t lie, it felt metaphorical.

And then I realised.

And now it was my turn to hold an index finger triumphantly aloft. Aha!

“This isn’t about the fairy lights at all!” I observed, shrewdly.

We are living in an age of uncertainty, misery and mayhem.

We are crawling our way through the fringes of a deadly pandemic.

We are witnessing extinction and forced-migration on a scale I doubt any of us thought we’d live through.

Billionaires are jaunting into space while the planet burns and societal fractures seem to become more deeply entrenched with every day that passes.

“Why bother?” has become an internal mantra I recite without thinking, anytime I bear witness to the irksome practice of “fun.”

Seeing people getting on with their lives has begun to feel like a deeply personal slight when I feel so frozen in anxiety and gloom.

But—and I’ll bet you can see where this is going—that’s wrong.

It’s not wrong to feel sad. It’s not wrong to feel embittered and nihilistic and hopeless. It’s not wrong to feel anxious. It’s somewhat rational to feel those things in these times, and I do say that knowing there are many people dealing with much worse things than me.

What is wrong, though, is to begrudge people their efforts to seek joy in the darkness.

Happiness is one of our most basic human needs and it is our right to find it in whichever way we can—as long as we don’t hurt anyone in the process.

So the least I can do is to get out of their way and to respect them when they do.

The next time I run past that house—sweating and swearing and lamenting my decision to exercise—I will nod to my neighbours’ house.

I will mentally salute their optimism and fortitude.

If the world can hold space for sadness, joy, and a festooned lavatory or two, then so can I.

No Social Media Day safari

2021-11-04T00:00:00Z

I’ve been spending way too much time on my phone in general, and on social media in particular. It’s affecting my mood, wellbeing, concentration and memory to an extent that’s starting to scare me.

I was really inspired by Michaela Coel’s Emmy acceptance speech in which she said:

“In a world that entices us to browse the lives of others to help us better determine how we feel about ourselves, and to, in turn, feel the need to be constantly visible — for visibility, these days, seems to somehow equate to success — do not be afraid to disappear. From it, from us, for a while. And see what comes to you in the silence.”

I’ve tried to cut down the time I spend on social media use by deleting the apps and setting time limits, and it hasn’t worked. So today I set myself a simple goal: spend one whole day off social media.

The rules

24 hours of no Twitter and no Instagram - those are the ones I use.
Write a little about the experience.

How it went

7.30am

I usually wake up and scroll through social media for an hour until I get up and shower. Sometimes I’ll read a bit of my book, too, but I often get distracted and keep picking up my phone.

Today, I do a New York Times crossword to keep myself busy, and then read a couple of chapters of my book, Scary Smart by Mo Gawdat. Fittingly, it’s about the rise and risks of artificial intelligence.

The crossword is absorbing enough that I don’t feel tempted to open Twitter. While reading, on the other hand, my attention keeps wandering and I feel repeatedly distracted by an urge to open Twitter. This didn’t used to be this hard and I find myself thinking: What have I done to my brain?

Midday

I’ve spent the morning using the Pomodoro method to break up my time whilst staying focused on my tasks. This is something I do often when I’m trying to resist distractions.

I’ve been pretty productive: some emails sent, half a blog post written, 2 important client decisions made, a slide-deck started and halfway to finished.

I notice I’m using this post as a social media replacement. Opening it up and adding a bullet point to my notes when I feel the urge to open Twitter or Instagram.

My brain feels restless, like it knows there’s something missing. I feel anxious and a bit irritable. I keep thinking that this shouldn’t be so difficult, and feeling ashamed that it is.

2.30pm

I’m back at my desk working after stopping for lunch. James and I walked to the shop at lunchtime and I left my phone at home. I felt a bit odd without it, but I paid attention to my surroundings and listened properly to James when we were talking. I realised with a guilty pang how little I’ve been doing that recently.

When we got home, I did another crossword and emailed my Dad some stuff he’d asked for. I feel like I’ve actually had a lunch hour today - normally it seems like it’s over in a flash.

Something that’s becoming apparent in the absence of the ability to squash it down with mindless scrolling is how anxious I still feel about COVID-19.

It’s really on my mind today. I’ve had one of those weeks where it feels like it’s creeping closer again: a few people I know have tested positive and my niece got pinged and my Dad had to take a test after feeling a bit sniffly.

I realise how much I’m using social media to reassure and distract myself from this big, looming, existential horror show we’re all still living with. The trouble is, it doesn’t really help, it just leaves me with a nagging sense that something’s wrong. Actually, it feels better to acknowledge that fear head on than to keep seeing it out of the corner of my eye.

5.30pm

I’ve just finished work for the day. Gradually throughout the afternoon my focus seems to have improved. I’ve made some headway on a report I’m writing and I’m glad I’ve spent the day doing that uninterrupted and not pausing to check in on other people’s lives.

The interactions I’ve had this afternoon: texts from people, conversations with James, Slack messages, have stood out to me more in the absence of exchanges on Twitter.

I feel a bit restless now. The end of the working day is usually my cue to enter a scroll-hole. I’m going to go and make dinner, go for a walk with a podcast and then settle down for the evening.

What I learned

Whilst having a day off social media felt harder to me than it should have, it was easier to stick to a whole day off than trying to limit my time on it.

I think that’s partly because having a specific goal always helps, and also because I couldn’t kid myself about whether I had achieved it or not.

In some ways, it was a relief to have a blanket rule to follow, and not to have to make lots of micro-attempts to resist the temptation throughout the day.

In conclusion

I’m sure that to some people this goal sounds ludicrously easy. It does to me, actually. And yet it hasn’t been. Social media is a socially-acceptable addiction, but it is an addiction, pure and simple.

I am completely addicted to my phone and social media is the main part of that. After today, I’ve realised I need to do more than setting time limits on social media. It’s the regularity with which I use it as much as the amount that’s causing a problem.

I’m going to aim for at least 2 days a week where I don’t go on social media at all. My hope is that regular breaks will help me learn to lean on it less, and use it with moderation.

Make things open, it makes things better. But...

2021-11-03T00:00:00Z

My favourite of the government design principles is number 10: Make things open, it makes things better. The principle says:

“The more eyes there are on a service the better it gets - howlers are spotted, better alternatives are pointed out, the bar is raised.”

I really believe that—especially when it comes to content.

It’s why I dedicate a lot of my free time to coaching and mentoring people on writing about their work. It's also why I ran the 10 More Blog Posts experiment in 2019, to get more people blogging with the help of a buddy system.

There are a lot of challenges involved in making things open—on personal, organisational and even societal levels—and I don’t want to undermine that.

But there’s an aspect of this principle—or at least, the way it’s sometimes interpreted—that I want to examine.

What “making things open” means

Sometimes “make things open” is used as a shorthand for “make things public”.

I’ve had clients and colleagues quote it to me to try and convince me we should publish something I don’t believe is viable. As someone whose job it is to advocate well-designed information, that’s frustrating.

Because making things open is more than just making things public.

To make things open in a way that actually does make things better, they have to be made truly available and inclusive.

That doesn’t mean everyone should become a context expert, or keep their ideas to themself—far from it.

It means being clear in our intent to help people to find and understand the things we’re making open, so that more people can benefit from our ideas. Doing this means that they can spot those howlers and propose better alternatives.

To me, that means that they’re:

findable - so people can discover it in the first place
inclusive - so people can access and understand our content
easy to navigate - so people can scan and search our content
relevant - so people know if it’s for them
useful - so we achieve our goals of making it open

These, in my view, are the pillars of minimum viable content.

Over the next month, as part of my NaBloPoMo effort, I’ll publish posts covering each of these principles in more detail, with practical tips to achieve them and create truly open content.

How to integrate content guidelines into design system documentation

2021-11-02T00:00:00Z

I wrote before about why design system teams need content designers and what happens when they don’t include one.

Now I want to follow up on that with some recommendations about how to incorporate content guidelines into a design system’s documentation.

Content guidelines and their relationship to design systems

Content guidelines explain the rules, conventions and principles an organisation follows when designing content for its users.

They include things like voice and tone guidelines, spelling and grammatical rules, A-Z style guidance, preferred terminology, and content design principles and processes.

An organisation’s design system needs to promote, embody and propagate its content guidelines: Text elements like labels, error messages, hint text and headings should be designed with them in mind, and the decisions about how to achieve this must be documented.

Why it matters

Content design impacts a user’s experience as much—if not more—as visual, functional and technical design.

When someone creates content independently of visual design and code, or vice versa, they lack the context needed to create a coherent user experience.

Because of this, an important role of design systems is to encourage collaboration and knowledge sharing between content designers and other disciplines.

What’s more, many organisations don’t have enough content designers to work across all of their product areas. Until that changes, design systems must also equip designers and developers with the information they need to design user-centred content in the absence of a dedicated specialist.

Don’t just link out to content guidelines

It’s not enough for design system documentation to just link to some content guidelines that live somewhere else, and otherwise pretend they don’t exist.

This sometimes happens when an organisation has pre-existing content guidelines which are owned by someone other than the design system team.

Some organisations, like GDS, include both:

an editorial division that produces longform content (like articles and advice guides)
product teams that produce transactional or interactive content

These organisations may continue to need separate content guidelines which include rules that aren’t relevant to design system users.

Likewise, if the editorial teams are using a content management system (CMS) which restricts their control to text elements within preset templates, they’ll probably find much of the design system documentation unnecessary, even confusing.

But simply linking out to content guidelines from a design system (and possibly back the other way) is not an adequate solution.

We need to do the hard work to surface the content guidelines that are relevant to our design system users at relevant points in their journey, where they’re more likely to see and follow them.

Don’t just create a separate section for your content design guidelines

For similar reasons, it’s also not enough to just bolt content guidelines onto a design system without properly integrating them into every part of the system they apply to.

A design system like this creates a clear division between “content” and everything else, and is likely to deepen entrenched disciplinary silos.

Don’t just link to content guidelines from component and pattern pages

Even linking to relevant content guidelines from individual documentation pages for components and patterns isn’t enough.

Using placeholder content, like "error message goes here" in component examples is a missed opportunity to demonstrate what good content design looks like. (For more on this particular subject, see my post on handling example copy in design systems.)

And although this approach shows the design system team has made more effort to highlight content design guidelines at the right points in the journey, it still requires someone to go somewhere else to look at them. Unless they consider it their job to do this, they’re probably not going to.

Combine content and design guidelines

For effective integration, design systems should use real content in examples, to show content best practice in the same way that they show visual design conventions.

Of the approaches I’ve shared, this is undoubtedly the hardest to implement—especially if you need to keep your existing content style guide or content design manual.

In this case, unless you’re going to employ structured content published into multiple places using a headless CMS, you’ll need to accept some repetition of content guidelines. This means having processes for keeping content design guidance in sync across more than one platform—but I’d argue that this is a small price to pay.

Proper integration of content and design guidance helps to reinforce that content design is as integral to a component or pattern as the way it looks and works.

It improves understanding across disciplines by helping non-content designers to see what good content looks like, and it reduces the chances of inconsistency and errors creeping into prototypes and products.

My NaBloPoMo debut: Day 1

2021-11-01T00:00:00Z

I’m taking part in National Blog Posting Month, or “NaBloPoMo”, for short.

NaBloPo... what?

I first became aware of NaBloPoMo via my former GDS colleague Steve Messer, who is a much more consistent blogger than I, and has participated in it for at least the past couple of years. (Sorry Steve, I haven’t gone to the effort of checking your exact inaugural year. And everyone else, that’s an example of the kind of meticulous fact-verification you should expect from me over the next month.)

As I understand it (read: as this post told me) NaBloPoMo was founded by an American blogger called Eden Kennedy, in response to National Novel Writing Month (NaNoWriMo).

It encourages participants to write a blog post every day throughout November, to break away from perfectionist ideals that might otherwise prevent them from sharing their work.

Since “perfectionist ideals” is (are?) my middle name(s?), I thought this year I’d give it a go.

My starting point

I decided to take part in this year’s NaBloPoMo a couple of weeks ago, in a not-entirely-uncharacteristic moment of wildly overestimating my future capacity and enthusiasm for such a venture.

I had visions of breezing up to my desk each morning before starting the day’s work: my hair inexplicably several inches longer, my hands clasped around a mug of something involving turmeric and nut milk, a candle flickering on my windowsill, birds chorusing gently outside, my home office overflowing with hygge and my brain brimming with ideas.

I imagined a carefully organised drafts folder on my desktop, filled with blog posts I had written ahead for the days I lacked time and energy—something suggested helpfully by someone on Twitter.

Instead, I’m sat here at the end of my working day, staring at a can of Pepsi Max (#NotSpon) which represents the only liquid I have consumed all day, feeling a little frazzled and distinctly uninspired. My drafts folder is non-existent and thus devoid of drafts.

But the point of this was to let go of perfectionist fantasies, and so here I am anyway: warts and impending UTI an’ all.

What I’m expecting

I’m expecting and hoping that NaBloPoMo will reignite my sense of creativity at a time when it’s never felt more lacking.

I’m hoping that today and the next 29 will get my writing juices flowing again, because writing is the love of my life and lately I’ve neglected it.

I’m intending to challenge my natural urge to refine my ideas to perfection before sharing them, and to see what happens as a result.

What you should expect from me

I’m going to do my best to stick to this and post daily throughout the month, but I’m going to be flexible with topics. I’m planning to write about a mixture of things, both work-related and personal.

And since one of my objectives here is to challenge my perfectionist tendencies, my writing is probably going to be a little less polished than usual. I’m going to allow myself a quick top-to-bottom proof-read of each post, and then I’m going to hit publish.

Let’s go

And so we begin.

Are you taking part in NaBloPoMo? I’d love to read your posts if you are.

Or, if there’s something you’d like me to write about, let me know—I need all the inspiration I can get.

Get in touch on Twitter or drop me an email at amy.l.hupe@gmail.com.

Why design systems need content designers

2021-08-20T00:00:00Z

Although often viewed primarily as vectors for visual design and code, design systems include a whole lot of content.

That includes content that tells you what the design system is and how to use it—things like home and landing page content on a system’s documentation website, or guidance on how to get started, how to ask for help and how to contribute.

There’s the content that sits within components: button and form input labels, error messages, hints, warnings, headings, and so on.

There’s design guidance explaining how and when to use those components, and technical documentation that tells you how to apply styles, install components and update to new versions when they’re released.

Good design systems also include content design information like voice and tone guidelines and a content style guide to capture writing conventions.

And yet most design system teams still don’t include a content designer.

And I really, really want this to change.

But Amy, how do you know design system teams don’t include content designers?

As a design systems consultant, I spend a lot of my time—unsurprisingly—talking to and working with design systems teams. Content design is one of the most common skill gaps I encounter.

When I gave a talk on design system documentation at Patterns Day in 2019, I asked for a show of hands from the content designers in the room.

Out of the 300 design system practitioners in attendance, there was just one.

To see if things had changed, I recently ran a Twitter poll to ask people if their design system team included a content designer, and only a third said theirs did.

Design systems are not new. Whereas once you might only find a design system being worked on as someone’s unofficial side project—most organisations now fund and sponsor them properly. That makes this level of under-representation from content designers unacceptable and, frankly, risky.

What happens when we ignore content design in design systems?

Inconsistent content

Without content design, components like buttons, links, error messages, form inputs—where the usability is at least as much about the words used on them as it is about the visual design—suddenly become a lot more vulnerable to inconsistency in how they’re applied.

Providing a coherent and familiar user experience means standardising language, not just visual design and functionality.

Perhaps I’m biased, but I’d wager that using different words to describe the same actions, processes and information is the most damaging and confusing kind of inconsistency of all.

Placeholder copy in live products

Anyone who’s ever used the internet to do anything will have encountered those vague error messages that simply tell you “something happened”, “try again” or “bad request: error code 5849734793”.

There are also more extreme examples, where lorem ipsum or other placeholder copy ends up getting published into a live interface.

These instances usually start life as placeholder copy and sneak through quality assurance checks when it’s no one’s job to review them, or write something better.

Truncation

Another common consequence of leaving content out of component design is truncation. These navigation cards from the Gumtree website have not been designed with content in mind.

Truncated copy in navigation cards in the Gumtree website.

Whoever’s writing the copy for them is—I’d hope—unaware of the character limit.

In every instance, the content is cut off so early that it leaves us with very little idea about what they’re linking to.

If these cards had been created collaboratively by designers, developers and content designers, at the very least a copywriter could have worked within the card’s constraints, to shorten the text and front-load the important terms.

Better yet, they could have been designed with a more realistic character limit to support more content.

No-context links and buttons

The web is riddled with links and buttons that just say “click here”, giving the user no indication of what will happen when they do.

Content designers know this is bad practice, but the problem persists.

Design systems make it easy for these problems to scale.

Bad content, multiplied

Design systems are great multipliers—so if something like the examples mentioned above makes its way into a reusable system component, either as placeholder text or just a poor content design decision, then it can very quickly be disseminated across a company’s entire product landscape.

That means we’re not just dealing with an instance of bad content anymore. Now it’s bad content at scale—which is bad news all round.

When content designers aren’t included in the process of creating design system components and patterns, it’s bad news for our users, who find themselves on the receiving end of these mistakes and misjudgments.

It means content designers have to spend time identifying and correcting widespread issues they probably would have caught at the root, had they been involved in the design of the system component or pattern.

Given that content designers are so often spread thinly across multiple teams and product areas, this kind of inefficiency adds unnecessary pressure to an already stretched discipline.

And when the mistakes are found and identified, they need to be corrected, which usually means rework for designers and developers. And these problems are exactly the kind that design systems aim to solve.

In conclusion

A design system needs to promote, embody and propagate content design best practice.

It’s not enough to start thinking of content design once the designers and developers have got things off the ground—language is a core part of a system’s foundations and needs to be included from the beginning.

Leaving content out of the equation damages the user experience, and when we do this at the level of design systems, we’re allowing that experience to scale.

But when designers, developers and content designers work collaboratively on creating components and design patterns, we create cohesive, intuitive and user-centred products and services.

The bottom line? Hire content designers.

Hope in the dark: a post for mental health awareness week

2021-05-11T00:00:00Z

I’m not sure what triggered my latest bout of anxiety and depression.

Maybe it was the pandemic. Maybe it was getting ill last year. Maybe it was the scary blood test result I had in November which scared me half to death before it turned out to be nothing. Or maybe it was the second or third lockdown, each of which I found harder than the last one. Most likely it was all of the above.

I’ve concluded that the “why” doesn’t really matter, and trying to think my way out of the mess I thought myself into isn’t really helping.

What does feel important is the “what”: What it’s been like, these past few months, to battle with my relentlessly over-protective mind.

It feels important to share because—for all its good intentions—mental health awareness week sometimes feels like a parade of clichés and platitudes that fail to scratch the surface of what poor mental health really feels like.

I’m all for removing the stigma around mental health, but sometimes being not OK—whilst it shouldn’t be stigmatised—is anything but OK.

So here’s what it feels like for me, to spend time in the dark, and to find my way back to hope.

30 March: Dark

Today is the worst day of my life.

Things have been getting gradually worse over the past few weeks. The low-rumbling of anxiety has become louder and now, suddenly, it’s deafening.

I’ve been having panic attacks every day. I’m struggling to work. I’m struggling to eat or drink. I’m struggling to sit still and at the same time I’m struggling to get out of bed. I’m exhausted but I can’t rest. I feel physically dreadful. I feel sick all the time. Everything hurts. My eyes sting from near-constant crying. My muscles tense and twitch and my nerves buzz and zing with a seemingly impossible mix of energy and exhaustion.

I climb out of bed after another broken sleep and stare out of the window. I see the tops of the houses and the trees I see every morning, but today they don’t look the same.

Without warning, my mood is plummeting with alarming speed and force. Within a matter of seconds I’m feeling worse than the worst panic attack I’ve ever had. My feet are on the floor but I feel as though I’m falling. Time seems to whoosh and then slow down. I feel as though I’m suddenly 20 metres behind my eyeballs. The world looks like a sepia-toned nightmare, and everything warps and swims behind a layer of dread and horror.

In a few days time my therapist will tell me this feeling is known as derealisation. She’ll tell me she herself has experienced it recently, that it’s frightening but common, that it doesn’t mean what I think it means. But I don’t know that yet. I feel as though I’m losing my grip on reality. “I will never survive this”, I think.

I tell work I’m sick. I don’t go into detail.

James had to go into work this morning and I’m suddenly afraid to be alone. I frantically message my friend Anna, asking her if she’s free to facetime. My thumbs are fumbling and clumsy and I struggle to type. She replies straight away and within a minute I’m looking at her on my laptop screen.

I try to tell her what I’m feeling but I can’t find the words. “This is more than anxiety, Anna” I blurt out. “Something’s happening to me. I’m so scared”.

I’m really crying a lot now. I tell her I think I’m ruining James’s life and the lives of everyone around me. She tells me emphatically that I’m not, that she knows how awful I’m feeling but that I will get better. She tells me I should call her anytime I need to.

After a few minutes, I feel OK enough to end the call, but as soon as I do I feel a suffocating sense of dread.

I call the Samaritans.

A kind woman with a Manchester accent answers and I tell her straight away that I’m not suicidal. I feel like it’s something I need to declare. Perhaps if I say it, I can solidify it as a fact. Perhaps just by saying the words I can ground myself in the truth of being a person who is struggling, but who is not suicidal. The word “yet” hovers silently over the end of my sentence and I wonder if she hears it too.

It’s not a lie, but the truth is messy. The truth is that I can’t do this anymore. I tell her that, and I tell her I’m terrified of where this is heading. I want her to tell me it’s all going to be OK, whilst knowing she’s not really allowed to do that. Somehow she calms me down anyway.

I put down the phone and go to my Dad’s house. He lives alone and we’re in a support bubble, but I’ve been too scared to see him in person until now. Today I don’t feel like I have a choice.

I try to explain what’s happening. I’m trying to be careful because I know how awful the things I’m telling him must be for a parent to hear, and I don’t want to drown him in whatever I’m drowning in. At the same time, I’m trying to be honest because I’m afraid something’s about to happen and I feel like I need to arm him with the information he’ll need when he has to take over.

To my surprise he’s calm and seems to understand. We talk for a long time and I start to feel better. He puts on a comedy on the TV for us to watch, and tells me to try and get some sleep on the sofa.

I try to concentrate but I can’t. Waves of anxiety keep crashing over me. When I can’t sleep, and I can’t sit still any longer, we go for a walk around the block and then I call my psychiatrist who tells me to take a double dose of my meds.

My Dad walks me home and helps me explain the day to James. I take my pills and sleep for 14 hours, and I dream of tornadoes and floods.

9 May: Hope

I’m sitting in our back garden with James and his Mum and Dad. I’m biting into a warm scone with clotted cream and raspberry jam.

I’ve been looking forward to this scone. Looking forward to things has come back recently.

I pick a crumb off my jeans. The sun is shining on the back of my neck and a light breeze is gently moving the hair on the nape of my neck. I look out into the garden. The tops of trees and the houses that seemed so strange and menacing on that day a few weeks ago look normal again now. A pair of magpies dance and dive around the top of a tree at the end of our garden.

A few weeks ago I was kneeling at the edge of the lawn I’m looking at now, next to my Dad. He’d encouraged me to keep busy, and gardening felt like the right balance of absorbing, active and mentally undemanding.

I was pulling up the weeds from around the tulips that we didn’t plant, but that arrive faithfully every year like a postcard from the person who used to live here.

My mind would wander frequently as I worked, fearful and restless, assessing itself over and over for signs of danger.

And then I’d get to a particularly stubborn weed, or my Dad would say something, and I’d have to drag it back to the present.

It was ridiculously hard work then, getting my mind to focus on anything other than my anxiety. Carrying out basic tasks took the most colossal effort, and I struggled to hold conversations. If someone asked me a simple question, I’d stare at them blankly, trying to process what they’d said and retrieve the answer from the depths of my preoccupied mind.

Now James’s Mum is asking me how I’m doing, and I know she means my mental health. “I’m OK” I say, and I notice that I mean it. “I’ve just been trying to keep busy and look after myself”, I explain, “I’ve been gardening.”

This catches James’s Dad’s attention. He’s a keen gardener and wants to know what we’re growing. I list the vegetables and herbs we’ve planted and point to the courgette growing in a pot in the corner of the patio.

I planted those one morning a few weeks ago, when I felt so convinced something dreadful was going to happen to me that the idea I’d be around to see them sprouting up in a few weeks’ time seemed inconceivable. But here I am and here they are, with tiny fruits and blossoms starting to appear between the stems.

James’s parents go home and we start taking plates into the kitchen.

I’m wiping crumbs off the worktop and I move a book called “Overcoming anxiety” out of the way. It’s James’s, not mine. It was recommended by a friend whose wife struggles with anxiety and OCD, and he’s been reading it to try and get a better understanding of what’s been going on with me. Seeing it now reminds me that I’m loved and supported, even when it feels like I’m completely alone.

He bought it one day a few weeks ago after a particular talk we had. I was sitting on a chair in the living room, hugging my knees into my chest and absent-mindedly digging my nails into my legs so hard that later I found little purple half-moons on my thighs.

“I can’t explain it but I don’t feel like me.” I’d said to him, serious and wide-eyed. “You’re looking at me and I look normal you think I’m normal, but I’m not. My head is broken, James. I don’t know what to do.”

Understandably, he looked concerned and scared at this, and that scared me even more. I suddenly wanted to run away from him and that look, unable to bear seeing my own worst fears back at me in his worried expression. And so I went for a run. I ran until I felt exhausted and then I ran some more. I ran until I couldn’t think about anything but my feet hitting the pavement and the air moving in and out of my lungs.

I’ve been running a lot since then, and over the past few weeks things have shifted and I no longer feel like I’m running away. Now when I run, I’m running towards things: nature, sunlight, release, relief. I run towards that moment when my thoughts quieten down and give way to a sense of presence and peace. My focus narrows and my mood lifts.

The shift in my running habits reflects a shift of things in general, which are slowly but surely getting better.

There are more good days than bad, and that makes the bad days more bearable. Each day that passes gives me a greater sense of confidence in myself and in the future.

And with each day that passes, hope returns.

Enabling contribution in the early stages of the Babylon Health design system

2021-02-01T00:00:00Z

From January to May 2020, I contracted as Product Manager for the design system at Babylon Health. You can read about setting up the Babylon Health design system in this post by Jack Roles.

One of the reasons I was hired was because of my involvement in establishing a contribution model for the GOV.UK Design System. It was hoped I could help to introduce something similar at Babylon.

But at the point of establishing that contribution model, we’d been working on the GOV.UK Design System for 18 months. It was relatively stable, supported by a good-sized team, and it already housed a comprehensive collection of styles, components and design patterns.

At Babylon, the design system was in its infancy. When I joined, we were still a few weeks away from launching it. The team working on it was much smaller, with just 4 of us working on it full time, and there was a lot of work to do to populate it with even the most basic building blocks of Babylon’s UI.

What’s more, unlike the GOV.UK Design System—which only needed to support web—the Babylon design system also needed to support Babylon’s native apps for iOS and Android.

With so much work to do to get the foundations in place and build adoption, designing a contribution model felt like a distraction we couldn’t afford.

Nevertheless, our colleagues were understandably eager to contribute, and we didn’t want to waste that momentum. They were the ones working on Babylon’s products day in and day out. We—being one step removed from Babylon’s users—didn’t want to act as gatekeepers. So we had to think about how to enable contribution in a way that was manageable, and didn’t detract from our work on building the design system.

Proactive versus reactive contribution planning

One feature of the GOV.UK Design System’s contribution model is that it was reactive, from the perspective of us in the team maintaining it. If someone wanted to contribute, we’d work to support them in doing so, diverting our attention from other things if needed.

For the reasons I’ve outlined, I knew this approach wouldn’t work at Babylon. We needed to stay in control of our backlog while we were putting the foundations in place and avoid distractions.

So instead of waiting for contributors to come to us, we decided to create specific touchpoints for contribution. And instead of opening the floor to any kind of contribution, we planned to ask people to contribute to the components we were working on at the time.

This would allow us to keep progressing through our backlog and building the design system, whilst getting valuable input from our community of colleagues along the way.

Contribution as co-creation

We started to run weekly sessions called Atomic Thursdays, with each week dedicated to reviewing and improving a single component.

We’d advertise the session internally each week on our Slack channels, telling people what we’d be focusing on, so they could decide if it was relevant for them, or not.

To prepare for the sessions, Jack, our designer, would gather examples of the component from across Babylon’s products and from other organisations’ design systems. Based on this, he’d create an initial design for the proposed design system component and present it—together with the examples—on a Figma frame.

During the sessions, we’d ask attendees to spend a few minutes reviewing the component, and then add their questions and suggestions.

Once we’d collected everybody’s feedback, we’d talk through the comments one by one, and note down any actions we agreed along the way.

We’d hear from designers and developers who were using the components day-to-day about how to improve them based on actual user experience.

The sessions also included representatives from our team, who understood how to systematise them, and internal experts in content design, accessibility, engineering and visual design, who would provide feedback using their subject matter knowledge.

After the sessions, we’d write a summary of the feedback and next steps, and share it in our Slack channels to keep ourselves accountable.

Through this process, we made our components richer and more representative by co-creating them with experts in our organisation, and we created a space to share knowledge and learn.

Evolving contribution as a design system matures

I left Babylon while the design system was still in its early stages, but I’d hope to have seen this approach evolve as it matured.

As important as contribution is to a successful design system, it’s often not possible to design, test and maintain a process for supporting it, whilst simultaneously building the system to a point that’s useful enough for teams to start working with. After all, no one wants to contribute to a system that no one’s using.

And though some may argue that contribution could help you to grow the system more quickly, in my experience that’s never the reality. (See point 5 in my previous article on enabling contribution.)

With that in mind, a small design system team with limited capacity needs to make some trade-offs in the early stages of its development.

Finding a way to proactively encourage contribution to the components and patterns you’re already working on is one way to do this—but this practice should evolve over time.

As a system matures and starts to stabilise, it makes sense to loosen the reins and allow the system's users to contribute organically: to let them share what they’ve discovered and find a mechanism for them to centralise and share that knowledge and experience with others in the organisation.

Constraints are always critical but, over time, those constraints can become system standards, providing helpful guardrails that focus more on the how, and less on the what.

From content designer to product manager

2020-08-12T00:00:00Z

It’s been just over half a year since I moved from content design into product management.

Since I left my last content role on the GOV.UK Design System, I’ve spent 5 months product managing the design system at Babylon Health, and a couple of weeks ago I started a new role as product owner for the design system at BT.

Here I’ll share what I’ve learned from the transition: the good, the bad and the ugly.

One change of many

A quick disclaimer: it would be remiss of me to write this article without acknowledging the considerable number of other factors that have affected my experience of this transition.

Since moving roles:

the coronavirus pandemic means I’ve worked at home for most of this time period
I’ve had some health problems which meant terminating my contract with Babylon early and taking 8 weeks out of full time work
I’ve also started working as a contractor, as opposed to a permanent employee, which brings its own changes: another post for another time
I moved from a very large organisation (government) to a much smaller one (Babylon) and back again (BT)
I’ve moved from the civil service to the private sector

I can’t promise that the conclusions I’ve drawn here aren’t affected by these other factors: in fact I can pretty much guarantee that they are. Keep that in mind as you read this article.

Why I moved into product management

I’m a passionate and experienced wordsmith. I’ve been a content designer / writer / editor for most of my career. So moving into product management was, in some respects, a bit of a curveball.

While working on the GOV.UK Design System, I found I was increasingly interested (and interfering—sorry about that, Tim) in the product management aspects of my team’s work.

I was interested and opinionated about the product strategy, thinking beyond the scope of my role as a content designer, and considering the direction of the product as a whole. A few people, including my old product and delivery managers, told me they thought I’d make a good product manager—that my strategic thinking and strong communication skills would stand me in good stead.

And despite the fact that it was an obvious next step, I just wasn’t drawn to the idea of progressing into a more senior content role. When it comes to content, my happy-zone is doing, not decision-making. If I was going to become a decision-maker, I wanted to have influence over a whole product or service, rather than a discipline.

So I decided to do something about the growing curiosity I had, and try my hand at product management.

How I prepared for the move

Once I decided to take the plunge, I took some steps to prepare for my transition.

Limiting the amount of change

I decided I would try to offset the impact of the move by sticking with an area I knew well: design systems. I thought I’d have a better chance of changing my discipline if I understood the type of product well. I started looking for product manager roles on design system teams, and after a bit of time searching, I landed one at Babylon Health.

Asking my network for advice

In the weeks leading up to my start date, I reached out to some people in my network to get some advice on the challenges ahead.

I met my then colleague Si who’s also made the transition from content designer to product manager, to find out what he’d learned and what advice he had. He provided me with a very comprehensive reading list which I’m still working my way through now.

I met with my former product manager Alice, who shared tips on getting up to speed as quickly as possible.

“As soon as you get in there, find out what’s been promised” was a piece of advice she gave me which proved as useful when I joined Babylon as it did when I joined BT a few weeks ago.

I also met with Lily who was managing the design system at Lloyds Banking Group at the time. She shared some important advice on staying focused and not burning out. I didn’t appreciate at the time how much I’d need to remind myself of that in the months that followed.

Deciding on some ground rules

I know I tend to hold myself to unrealistic standards, and that that would quickly land me in trouble if I wasn’t careful.

So going in I made myself a list of ground rules to follow to avoid getting overloaded, and to focus my energy in the right places. They were:

stick to my working hours
spend the last 10 minutes of everyday listing outstanding tasks or thoughts to pick up tomorrow
keep work apps off my phone, or at the very least, switch off notifications
be relentlessly honest about what I know and don’t know, what I can commit to and what my team can commit to

I also set myself a very strong intention not to interfere with content, despite the temptation I knew would be there. The team I was joining had a content designer—a great one at that—and I wanted to make sure she had space and autonomy to do her role. I was joining as a product manager, and I was firm about staying in my lane.

What’s been good

Whatever the future has in store, I’m really happy I made the move.

After 8 or 9 years working as a content specialist, I needed a shake-up, and moving into product management has given me that.

I’m glad I considered how to limit the amount of change as product management has been a big learning curve, and if I wasn’t working with a familiar subject I think I’d be struggling to keep up.

I also think it impacts how people perceive me. I’m new to product management, but I’m an expert when it comes to design systems. This affords me a certain amount of trust and respect, and helps me to speak confidently about my work.

I’ve realised that content design has given me a lot of transferable skills to prepare me for product management. Here are some of the ones I’m most grateful for.

Communication - being able to clearly explain what we’re doing, why and how—in simple terms—has been a huge advantage for the amount of presenting and reporting I have to do. Lots of people have complimented me on the clarity of my presentations and written communication.
Showing value - content design is still seriously undervalued as a discipline, compared with others. As frustrating as that’s been at times, it means you get good at persuading people that what you’re doing is worthwhile, and this is a very important part of product management.
Negotiation - anyone who’s had to work with a legal team to produce an advice guide for an audience of not-lawyers will come to know a thing or 2 about negotiation. Since so much of product management is trying to find compromises between user needs and business goals, being able to negotiate effectively with the team and with stakeholders is a real asset.

And finally, I’m learning a LOT. I think I probably gained more knowledge and new skills in my first 3 months of product management than I did in my last 18 months of content design.

I’ve got a much more balanced understanding of the different disciplines that make up a product team.

I’m learning how to lead, how to admit when I don’t have the answer to a problem, whilst creating confidence that we’ll find it.

And I’m learning practical skills as and when the job demands them, like how to use new tools for reporting and roadmapping, how to put together a business case, or how to set up a sprint plan and review it at the end.

What’s been hard

I’ve had to become much more commercially-minded and business savvy, and fast.

I’m used to speaking in the language of user needs and design hypotheses. Now, as well as those things, I have to talk about operational efficiency and channel share and OKRs (objectives and key results, if you’re asking). I’m having to tell the same story in different ways to make sure it resonates with audiences I’m not used to dealing with. It’s satisfying when it goes well, but it’s tough.

I’ve realised that the bit of product management you see from a product team is the tip of the iceberg. Going in, I expected most of my time to be spent with the team, guiding the product strategy and prioritisation, stepping out from time to time to provide updates to stakeholders. In reality, only about a quarter of my time is spent with the team. The rest of it I spend meeting with other teams and people to gather requirements, report on our work or ask for support.

I’m not only busier now than I’ve ever been, I’m also context-switching more than I ever have, being pulled in many different directions by a group of people that extends far beyond my team.

I occupy the space between the team, the users and our stakeholders, and no one else shares that vantage point with me. This makes it really interesting, but also lonely, at times. Trying to find acceptable compromises is challenging when people are mostly thinking about their own piece of the puzzle, and not the big picture you see.

As a product manager, any bad news for the team comes to you first. When bad news comes, trying to balance honesty against protecting team-morale is tough. On days like that I miss being purely part of the product team, and feel retrospectively grateful to my previous product managers for shielding us from this, so we could get on and do the work.

What’s next

I often joke that I’m a content designer pretending to be a product manager. My skills and experience are very much rooted in content design, and I think that’s part of what makes me a good product manager.

I may go back to content design one day, or I may switch between the 2. If I do, I’m confident that product management has already given me new knowledge and skills that will make me a better content designer.

For now, I’m excited to continue as a product manager and to see what lessons the next 6 months have in store.

Useful resources

Here are some of the resources I’ve found helpful while transitioning to product management:

Why you don't need a separate design system for internal services

2020-04-09T00:00:00Z

Over the years, internal tools and services have suffered from a real lack of user-centred design.

Whether it’s requesting holiday through an HR portal, updating a website using a CMS, or managing user accounts through an administrative system, these activities are often needlessly painful, forcing us to wrestle with UI that we’d never dream of giving to our external users.

The good news is that many organisations are now investing time and money in properly designing these tools. But when it comes to supporting these efforts with design systems, there’s still a way to go.

Many teams designing and building internal services will discover gaps in their organisation's design system, finding patterns created for consumer-facing products that aren’t fit for their purposes.

And this often leads them to a common question:

“Should we create a separate design system for our internal services?”

In this article, I’ll explain why I think that’s the wrong solution, and what to do instead.

Colleagues are users too

There’s a poster you’ll see on the walls of various government buildings. It says “Civil servants are users too”. It’s a reminder to hold internal services to the same standard as you would a public-facing service.

And this principle is just as applicable outside of government. If we want to create inclusive workplaces, we need to provide usable, equitable experiences to our colleagues as well as our users.

Building a separate design system makes the problem worse

The reason that so many internal tools are poorly-designed, is that they’ve consistently been treated as secondary—or at the very least, separate—to the products we build for our customers.

Creating separate design systems to support internal services deepens this disconnect, creating a breeding ground for unhelpful and false ideas like:

internal services don’t need to be accessible
we don’t need user research on internal tools
our users are experts so we don’t need to use plain language

To truly improve the state of our internal services, we have to centralise the process of designing them. And that means doing the hard work to serve them with our existing design systems.

Creating separate patterns won’t help either

Just as I wouldn’t advocate creating a separate design system for internal services, I’d urge against creating specific internal service patterns.

Admittedly, doing so might be the simpler option in the short term. There’d be no tedious updating of patterns to make them work for internal services, or work to incorporate existing design patterns into established staff tools.

But long-term, it’s a sustainability nightmare. Maintaining at least 2 versions of each pattern —one for consumers, one for colleagues—is inefficient, and creates needless complexity for the many teams who work on both the consumer and colleague-facing sides of their service.

Designing patterns for internal services

Look for the overlaps before the discrepancies

None of this is to say that internal services will never need a different treatment to those designed for consumers, but that’s a lot different from saying they always do.

For starters, as well as context-attentive design patterns, most good design systems include a strong set of context-agnostic foundations, like typography, colours, spacing, common form inputs, buttons, tabs, accordions, tables and so on.

These foundational elements really don’t care where they’re used, so extending them to our staff tools should be straightforward, and reduces our maintenance costs. The hard work has been done, so why do it again?

Even when it comes to more context-specific aspects of our system, the beliefs that underpin differences in our colleague and consumer-facing services are often false.

For example, a common objection to using certain content conventions in internal services is that it dumbs down and frustrates experts. But there’s plenty of evidence to show that even experts prefer plain language.

And an even more unpleasant belief held by some is that tools for our colleagues don’t need to be accessible, leading to UI that’s riddled with “space-saving” form controls, images and icons missing alt-text, and poor contrast ratios.

But given that there are 13.9 million disabled people in the UK alone, it’s nonsensical to assume none of them do, or could, work in your organisation.

What’s more, there’s a wealth of research that shows designing accessible services makes them universally more intuitive to use.

By challenging our beliefs about what differentiates colleague and consumer-facing services and looking for areas of overlap, we can more easily create solutions that work for both.

Consider user needs over user types

Classifying users as either internal or external users is problematic. Among other things, the lines are often blurred.

The GOV.UK Design System and the GOV.UK Service Manual—both of which I’ve worked on—are primarily aimed at civil servants and those working on government services. Yet both are publicly available, and often referenced by people outside of the organisation.

Rather than focusing on user types, I think it’s more useful, and more interesting to consider what characterises a service and how people will use it.

For example, internal services like caseworking systems often need to optimise for regular use over simplicity of first-time use. A little extra time spent getting to grips with more information-heavy screens on first use might be an acceptable trade off for a more efficient experience on return visits.

And although we probably wouldn’t make this same trade-off in a consumer-facing contact form—which is unlikely to be used frequently—we might do so in something like a messaging platform which is designed to be used often.

By designing things based on user needs and not service types, you’re less likely to find yourself restricted to supporting only external or internal services.

Design flexible patterns

To effectively accommodate internal services in a design system, components and patterns need to be flexible enough to handle varying contexts.

This can be achieved through a combination of versatile components and contextual usage guidelines.

For instance, there’s no reason we can’t use the same buttons in a consumer sign-up flow and a customer account management tool.

For the sign-up flow, we can assume most users are only going to do this once. As such, we might try to reduce their cognitive load by sticking to one main call to action per page, and recommending only one button is used.

A simple sign up form might include just one main call to action.

For the customer account management tool, perhaps we know our users are mostly account administrators who spend their entire day adding entries to the system. In this instance, we might conclude that it’s useful to include multiple calls to action of equal importance on a single screen, where our users can see and access them quickly.

A customer account management interface might have multiple buttons of equal importance.

(Note: the approach shown in the last example could be just as useful for a regularly-accessed consumer-facing service like an email inbox. If we’d tucked it away in a separate design system for internal services, we might have missed this opportunity.)

In both cases described above, the button in question can be designed and built identically, but the usage guidance needs to acknowledge and accommodate the different scenarios.

By considering the range of scenarios in which our components and patterns might be used, we can create flexible solutions that work across a broader set of contexts.

In conclusion

Our colleagues are users too, and it’s important that we uphold the same standards for internal services as we do for consumer-facing products.

Creating separate design systems or patterns to support this work only deepens the divide, making it harder to see the overlaps in our work.

Removing the arbitrary line between internal and external users helps us to maximise opportunities to reuse solutions and create scalable, flexible design patterns.

And finally, creating design systems that focus on user needs rather than user types means we can design usable, inclusive experiences, for all of our users.

Acknowledgements

Another enormous thank you to the ever-supportive Adam Silver for his invaluable feedback on this article, for designing the illustrations, and for always encouraging me to overcome my imposter syndrome and share my thoughts.

So that was 2019...

2019-12-31T00:00:00Z

Let me paint you a picture.

I’m sitting here in my pyjamas, on the final day of the year and the decade, eating the last of the Christmas truffles, and feeling somewhat self-conscious about the self-indulgence of writing a year in review.

I’m thinking back over the past 12 months and feeling a mix of pride, sadness and a good dose of “what the hell just happened?!”.

Political events aside (I’m still technically a civil servant until 3 Jan 2020), it’s been a heck of a year work-wise, and I wanted to take a moment to look back and capture it.

So here we go…

I did lots of collaboration

This one reads like a bit of a “misc”, but the common thread in all of it has been the joy of collaborating with people I really respect.

Some of my favourite collaborations this year were, in roughly chronological order:

prototyping and testing a new version of the GOV.UK Prototype Kit docs with Debs Durojaiye and Rosie Clayton both of whom are awesome and I wish I’d got to work with longer
running GitHub training for content designers with Nick Colley and turning that into this handy guide on proposing content changes using GitHub
becoming Adam Silver’s official unofficial articles editor and helping him to publish some excellent articles - my favourite of which is the most recent Building trust as a designer
planning and running a cross-government workshop to explore design system contribution and assurance with help from the brilliant (and patient) Simon Whatley
working with the Design System team, as well as Adam Silver, Amanda Kerry, Frankie Robero, Gemma Hutley, Mike Owen, Nadia Huq and Simon Whatley and others from across government to get 6 new patterns published in the GOV.UK Design System
and most recently, just in time for this review, working with total legend Caroline Jarrett on reviewing some chapters of her upcoming book

I launched this website and discovered the joy of self-publishing

I started blogging on my own platform (thanks to Adam who built this site for me) which has made a huge difference to my motivation and confidence in putting my ideas into the world.

I wrote 9 articles in total, of which my personal favourites are:

I also published 18 weeknotes which I’ll carry on with in 2020.

I did a tonne of talks

This year, for me, has definitely been the year of the conference.

I hadn’t done much public speaking before but this year I had the pleasure of giving a number of talks, and building my confidence as I went. In 2019, I spoke about:

Building a design system for everyone at Frontend North East with Tim Paul
Design Systems documentation at Patterns Day and NUX8
Enabling contribution to the GOV.UK Design System at Level Up
How design systems can promote accessibility at Curio Conference

I find public speaking challenging, but I also really enjoy it and I’ve learned a lot from practicing.

Thank you to Colin Oakley, Jeremy Keith, Barry Briggs, Sybil Hoang, Lauren Pope and all the other organisers involved for having me, and for making your events such a pleasure to be a part of.

I’m hoping to do more speaking next year.

I watched a tonne of public speaking

One of the nice things about speaking at a bunch of conferences this year, was that it meant I got to attend a bunch of conferences this year. I’ve been really lucky to see some brilliant talks and, though I can’t mention them all, I’ve learned something from all of them.

Some of my personal favourites were:

Ignacia Orellana’s fantastic talk on designing the service behind the GOV.UK Design System at Upfront Conf which she gets extra points for delivering with a broken arm; I had the pleasure of not only watching Ignacia talking about this work, but also doing this work and it’s fair to say that in both cases, she absolutely nailed it
Ollie Byford's excellent talk on inclusive forms which took us through a fictional GOV.UK service to give a fascinating, funny and incredibly detailed account of the work GDS puts into making services accessible
Inayaili de León’s reassuring and affirming talk on 5 things that aren’t true about design systems at Patterns Day
Emil Björklund’s wonderful talk, also at Patterns Day, in which he took us on his journey of Meandering towards design systems
Vimla Appadoo’s talk at NUX8 on redesigning design in which she asked us to consider our shared responsibility to design ethically, focusing not just on our outputs, but how we get there
Chris McCrudden’s talk at Curio conference on being less shit which was as funny as it was thought-provoking
the only talk this year that made me actually cry, given at Curio by photojournalist Miguel Amortegui who talked about using photography to empower people to tell their stories in the very worst of circumstances

10 more blog posts

After a few conversations earlier in the year with people who were struggling to get blogging, I decided to launch an experiment, called 10 more blog posts.

With the help of some very kind people (Lauren Currie deserves a special mention for helping me get set up, and so does Dave House for designing the stickers), I set it up as a buddy system, using Twitter to partner people who wanted to write a blog post, with people who were keen to support them, whilst learning more about the post’s topic.

At my last count, the initiative had generated 18 blog posts, many of which were written by people who’d never blogged before.

My workload towards the end of the year meant that my intention to properly analyse the experiment and plan next steps fell somewhat by the wayside.

But I’m still really proud of what those of us who took part achieved, and I plan to follow up as soon as possible in the new year.

I left GDS :(

Without doubt the biggest event of this year has been my decision to leave GDS and, for the moment, the Civil Service.

Working there for the past 3 years has been hands down one of the best and most impactful experiences of my life. I met so many incredible people in my time there, many of whom I think will be friends forever.

My time at GDS has shaped who I am, personally and professionally, and helped me to understand what matters to me.

I’m immensely proud of the work I did with the GOV.UK Design System, and grateful for having been given the support and encouragement I needed to do it.

Even though it was the right time for me to go, it was a difficult decision to make.

But that’s been made a little easier by the fact that…

I landed an exciting new role for 2020

I’m going into 2020 as a contractor. I wanted to try it out in the hope it would give me more flexibility, more time and resources to spend on the things I care about.

I felt sure it was the right move for me, but that didn’t stop me from feeling pretty terrified when I handed in my notice with nothing to go to.

Luckily, I landed pretty much the best role I could have asked for to kick-start my contracting career: Product Manager for Babylon Health’s design system.

I’ll be joining them in January and I cannot wait to get stuck in. I’ve been introduced to some of the team already, and everyone I’ve met so far has been utterly lovely.

I’m looking forward to getting my teeth into a new challenge.

Happy new year

So that brings me to the end of my self-indulgent year in review.

A lot of great things have happened this year, and a lot of not-so-good things that I haven’t covered here). Without a shadow of a doubt, the best thing about 2019 has been the people.

If I’m feeling a bit low, my Dad always tells me to hang in there, because you never know when you might meet a person who will change your life. And this year, I’ve met many.

So to everyone who’s been a part of my year, whether you’re mentioned directly here or not, an enormous thank you for being you, and a Happy New Year. Here’s to 2020.

Design systems: 5 lessons in enabling contribution

2019-11-14T00:00:00Z

Over the past few weeks, I’ve been thinking and talking a lot about supporting contribution to design systems.

I’ve started reflecting on some of the ways that my thinking has changed over the past year or so.

While I still believe that allowing a design system’s users to contribute to it is critical, my beliefs about why that’s the case, and how to do it effectively, have evolved.

Here are 5 important lessons I’ve learned about enabling contribution.

1. Get comfortable with some multiplication of effort

We often talk about teams solving the same problems in silos as one of the problems a design system will fix.

As soon as there’s a centralised pattern, multiplication of effort can cease, and we’ll reach that desired state of optimum efficiency.

But if we’re not careful, contribution can become a kind of race to the finish line, and there’s a danger in trying to reach that end point too early.

Firstly, there is some value in multiplication. If 3 teams arrive at the same solution, independently of each other, that’s useful information. Likewise, if one team’s design is demonstrably more effective than another, that’s worth knowing.

In The Problem with Patterns, Cathy Dutton warns that “patterns should never sacrifice user context for efficiency and consistency”.

If we don’t make space and time for contextual design to happen, we won’t be able to create a sufficiently flexible pattern.

Trying to unify design within a pattern, before we’ve really understood the contextual variation it needs is risky, as illustrated by this slightly crude but fitting example I recently spotted on Twitter, in which the same design is used on both a bottle of cooking spray and a bottle of insect killer.

At some point, we have to make these findings open so that we can consolidate them into a single pattern, but we shouldn’t rush this step.

We have to diverge before we can converge, or we risk creating a solution that’s too constraining to be useful.

2. Don’t compromise on quality to make contribution easier

When thinking about how to help people contribute to a design system, it’s easy to start thinking exclusively about what contributors need.

Focusing on making it easy to contribute might point us to things like relaxing our standards and lowering the bar on quality—allowing things to be published before they’re really ready, to reduce the burden on contributors.

But we have to balance our contributors’ needs with the needs of our system’s users. For users of a design system, we need to provide clear, reliable and evidence-based patterns.

Publishing patterns when they’re not ready enough makes it more likely they’ll need to be changed in the short to medium term future. This creates instability.

If we’re constantly imposing updates on our users, we’ll start to lose trust, which is likely to impact adoption. And if people don’t use the system, it’s unlikely anyone will want to contribute to it anyway.

So, although we have to support contributors, we mustn’t do it at the expense of holding patterns to the standards our users need.

Making our standards open and clear, having a solid quality assurance framework, and providing hands-on support, is a more responsible way to support contributors, whilst still prioritising users’ needs.

3. Be inclusive and help the unlikely contributors

To be able to contribute to an open source project like a design system, people need time, confidence, motivation and permission.

If we wait passively for contributors to approach us, it’s likely that only the people with all of these things will do so—and that will influence our decisions.

Early contributors will be the people we’ll learn from, who’ll tell us which bits of our process are working, and what needs to change.

So if our early contributors are already well-equipped to contribute, and we optimise our contribution model for those people, then we’re only making it work for a privileged few. This is problematic.

If the community of people helping to grow the design system isn’t representative, the design system isn’t going to be representative either.

In her brilliant talk on fostering participation in design systems, Inayaili De León stresses the importance of “listening to the quiet ones”, and making safe spaces for everyone to share their ideas.

We have to do active work to lower barriers and build capability, with particular focus on those who might find it harder to contribute.

Because ultimately, we can’t create a design system that works for our whole community of users, unless the whole community helps to build it.

4. Accept that no one cares that much about contributing to your design system

I often talk to teams who are struggling to get contribution off the ground.

They’ve documented their conventions and processes, they’ve created shiny new guides on how to contribute, they’ve given people their email, invited them to design crits and even told them where they sit.

But despite their best efforts, hardly anyone is contributing, and when they do, there are big gaps to fill: Patterns arrive missing documentation, or haven’t been tested in user research, even though the contribution guidelines clearly stipulate these things.

As far as I can tell, this is a universal problem in design system land, and I think it comes down to one hard truth: No one cares that much about contributing to our design systems.

And that’s OK.

Those of us working on design systems are paid—or at least permitted within our paid roles—to work on our design systems. Our contributors are not.

Working on a design system is complicated and requires presence and sustained involvement to get it right.

It’s unrealistic to expect those working in other teams to hold contributing to our design system at the forefront of their minds, or to submit a textbook pattern when they do.

We can and should work to empower contributors with hands-on support and transparency around our conventions but in the end, it’s our responsibility to provide patterns—it’s not theirs.

Repeatedly reminding teams to contribute, going out and pattern hunting, and doing a significant amount of hand-holding is part of the job, and it probably always will be.

This might seem disheartening, but there’s another way to look at it: if working in silos is a default behaviour for teams within our organisation, then any contribution can and should be considered a big success.

If people are trying to contribute at all, you’ve done something seriously right.

5. Contribution doesn’t make things faster—it makes things representative

When making the case for supporting contribution, we often talk about about how it’ll help us to scale a design system faster. But in my experience, that’s not really true, and I’m yet to meet a team who’ve found it to be the case. (Though if you have, please drop me an email and tell me your secrets!)

Creating patterns is hard. It takes time. And that time has to come from somewhere, whether it’s from the central design system team or contributors.

There’s inherent complexity in making reusable patterns that work as part of a system.

It’s only through working on a design system over a period of time that we start to get good at navigating that complexity, so it’s unrealistic to expect external contributors to have that same capability.

As I said earlier, we can’t relax our standards just to make contributing easier, so time spent helping contributors meet those standards needs to be part of the equation.

In my experience, it usually takes longer to help an external contributor to produce a pattern than it does for the core design system team to do it themselves.

It’s unlikely then, that supporting contribution is going to lead to faster growth. So we have to look for the value elsewhere. And in my view, the value to be had from supporting contribution to a design system, is making it representative.

Opening up a design system for contribution gives more people a seat at the table, and a chance to have a say.

Government design principle number 10, Make things open, it makes things better says:

“The more eyes there are on a service the better it gets - howlers are spotted, better alternatives are pointed out, the bar is raised.”

The same goes for patterns.

Teams who are using the system to build products are perfectly placed to ensure that patterns are going to work in those products.

Enabling contribution means patterns are valuable and representative, both for the design system’s users, and the users of the products it’s there to help build.

In conclusion

Supporting contribution is one of the most challenging aspects of managing a design system.

Progress can feel slow to non-existent, and the rewards we first envisioned may turn out to be fantasy.

Getting people to contribute and then supporting them through the process requires significant effort, and that effort has to be sustained over time.

But it’s an effort worth making. With input from a community of users, a system’s patterns become infinitely richer and more representative than they would otherwise be.

And I believe that prioritising contribution and representation—even at the expensive of short-term efficiency—is the key to a design system’s success.

Acknowledgements

Thank you to Ignacia Orellana for providing invaluable feedback on this article, and for her general expertise and wisdom on this subject, which have heavily influenced the lessons it contains.

And thank you to Adam Silver for insisting I wrote this down in the first place, and for taking the time to review it and make it better.

10 More Blog Posts update

2019-09-19T00:00:00Z

On 6 August 2019, I launched an experiment called 10 More Blog Posts.

I wanted to find out if, through a simple buddy system, it would be possible to help 10 more people to share their work in the open, pushing 10 more blog posts out into the world.

I wanted to run the experiment for 3 months, which means we’re pretty much at the halfway mark now. Here’s how it’s going so far.

21 pairs, 5 blog posts and counting

So far, from my observations, 21 blogging pairs have formed as part of the initiative.

5 blog posts have been published, with more underway.

The first and fourth were authored by Edafe Onerhime, one of my own blogging partners, who has written 2 posts on data strategy, explaining:

Edafe is now finishing work on a third post in the series, which will look at business and big data after the hype.

The second blog post published was written by Amy Grinstead, who paired up with Lauren Currie, showcasing the value of content design by documenting a week in the life as a content designer.

The third blog post to come out of the initiative was Arfah's Community starts with two, written with help from Sam Villis.

Adapted from a talk she gave back in May, Arfah's post outlines the lessons she learned from setting up Muslamic Makers—a community space for Muslims working in the technology and creative industries.

The fifth blog post published was Adam Silver's brilliant and self-explanatory Where to put buttons in forms which he wrote with support from Caroline Jarratt.

As well as what’s already been published, Laura Morley has written a blog post with help from Adam Silver—who is taking part as both a coach and a blogger—which she plans to publish in the next few weeks.

What we’ve learned so far

There’s power in togetherness

First and foremost, everyone I’ve talked to about the initiative has commented on the value of working with someone else—which is exactly what I was hoping for. Having regular check ins to talk through concerns, someone to hold you gently accountable, and a ready-made cheerleader to help promote your post once it’s published have proved welcome benefits of working with a partner.

Bloggers I’ve talked to told me that working with someone else has helped them to feel validated and motivated, and means that there’s someone to help them move past the blockers we all hit when writing.

Starting is the biggest challenge

4 separate people I spoke to all cited “just starting” as the hardest but most valuable step when it came to writing a blog post.

Putting figurative (or literal, if you’re going old school) pen to paper is the first step towards dismantling the idea that you can’t do it.

As soon as you’ve started, you are doing it. Everything else can be figured out along the way, with help from your content coach.

A bit of structure helps

Those of us who’ve had periodic and semi-regular catch ups at pre-agreed times have found it easier to keep things moving than those that haven’t.

One thing I’d like to explore off the back of this is providing a lightweight timetable for blogging pairs to follow, which includes clear milestones and timescales to work to.

This could of course be adapted by each pair to make room for work commitments, holidays and other life stuff they need to tend to. But I think having a start point could be a valuable way of helping people stay on track.

Into the second half - what’s next?

I hope to see more blog posts appearing as we move into the second half of this experiment, and I’ll be delighted if we can make it to 10 by the time initiative ends on 6 November.

Join the 10 More Blog Posts Slack

I’ve set up a dedicated Slack organisation to help people taking part in the challenge.

It’s been reasonably quiet to date, but it’s a safe and supportive space to get help from others. If you haven’t joined already and you’d like to, let me know and I’ll send you an invitation.

You can send me a message me on Twitter or email me at amy.l.hupe@gmail.com

Let me know how it’s going

If you’re taking part, I’d love to hear how it’s going.

I’d especially like to hear from you if you’ve struggled to get things off the ground as I want to make sure this initiative is as inclusive as it can be.

Get involved

There’s still plenty of time to take part in the 10 More Blog Posts challenge if you’d like to.

If you’ve struggled to find someone to pair up with, or if the idea of asking on Twitter is just too excruciating, direct message or email me and I’ll see if I can help.

Publish a post and claim your sticker

My colleague Dave has kindly designed me some stickers to support the initiative—there’s 2 to choose from, one for bloggers and one for content coaches.

Once you’ve published your post, direct message or email me with details of where to send it to and I’ll post it out to you.

A week in my life as a content designer

2019-09-13T00:00:00Z

I’m a Senior Content Designer at the Government Digital Service (GDS). I work on the Design System team, who built and maintains the GOV.UK Design System.

I’m writing this in response to Amy Grinstead’s article A week in the life of a content designer.

Amy’s calling for content designers, like me, to share their #ContentDesignWeek as a way of helping organisations better understand what content designers do.

Like Amy says, we still have work to do when it comes to showcasing the value of content design, so with that in mind, here’s what I’ve been up to this week.

Monday

We offer a daily support service to our users, helping them with any questions they have, or if they get stuck using the Design System or the GOV.UK Prototype Kit or GOV.UK Frontend - which our team also looks after.

Each day, members of the team take it in turns to monitor emails, Slack messages and GitHub repos for questions coming in, and Monday was my day.

When I wasn’t answering questions from our users, I was chipping away at our accessibility statement.

Last year, a new piece of legislation known as the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 came into force.

This means that public sector websites, like ours, need to do work to be more accessible for everyone, including people with:

impaired vision
motor difficulties
cognitive impairments or learning disabilities
deafness or impaired hearing

This includes publishing an accessibility statement, outlining where our site meets accessibility standards, where it doesn’t, why that is, and what we’re going to do about it.

I’ve been trying to understand the rules around it, what it needs to include, what’s negotiable and what isn’t.

In the afternoon, me and our tech lead, Ollie, were interviewed by design systems legend Nathan Curtis about how we’ve supported contribution to the Design System.

We were the 3rd set of interviewees in a series Nathan’s doing, and I’m looking forward to seeing how our experience compares with the others he’s spoken to.

Tuesday

Tuesday is usually meetings day, and this Tuesday was no exception.

We started the day with a team retro, and then I met with Tim our Product Manager and Kelly, our Delivery Manager, to talk about content priorities for the next 3 months.

I’d like us to establish a content maintenance process. At the moment, we review content periodically for accuracy and up-to-dateness, but it’s done on a fairly ad hoc basis, and as the Design System grows, we’re going to need something a bit more formalised.

In the afternoon, I caught up with Ollie and one of our Interaction Designers, Debs, to talk about shipping some improvements we’ve made to the GOV.UK Prototype Kit guidance.

The Prototype Kit is a prototyping tool that lets users create high-fidelity prototypes that look and feel like real GOV.UK services using HTML and CSS.

We want to make it easier for people to get started with the Prototype Kit without having to wait to attend one of our training courses which we only run a few times a year.

In the evening, I caught up with a couple of people I’m coaching as part of the 10 More Blog Posts initiative I set up in August. It’s a buddy system, where aspiring bloggers can team up with content coaches, who help them write a blog in exchange for learning more about their area of expertise.

So far, we’ve got 21 pairs, we’ve had 4 blog posts published and there’s many more underway.

Wednesday

I started Wednesday with some work on my presentation for NUX8, a UX conference I’m speaking at in a few weeks time.

I’m going to be talking about principles for writing inclusive documentation, looking at how we’ve approached it in the GOV.UK Design System.

In the afternoon, our other Interaction Designer, Dave, and I met with Adam, Amanda and Gemma from the Ministry of Justice (MoJ) to discuss a contribution they’re making to the Design System.

They’ve been working on a design pattern to follow when asking users for bank details. With minimal support from us, they’ve done an excellent job and I’m looking forward to getting it published in the next few weeks, once it’s been reviewed by the working group.

Thursday

On Thursday I worked at home. In between remote meetings, I caught up on emails and did a bit more work on my NUX8 presentation.

I gave MoJ’s bank details guidance a 2i (we use this at GDS as a shorthand for ‘second pair of eyes’—basically a content edit) and sent it off to the working group.

I usually organise and run the working group review sessions each month. We run them remotely using Google Hangouts, and we’ve done lots of work over the past year or so to make sure they’re constructive and inclusive for both working group members and contributors.

Friday

In the afternoon, I facilitated the Design System catchup—a weekly hangout for people across government to get together and talk about design systems, patterns, tools and common challenges we share in this area.

This week, we talked about the challenges of getting people to contribute their work to design systems (this is a really important part of making sure they’re representative) and some of the different ways we’ve approached this in our teams.

I always find these calls really valuable. It’s great to hear what others are working on, and it’s nice to find reassurance that your problems aren’t unique.

Content designers: get involved

Join me in sharing your week as a content designer, and post it on Twitter with #ContentDesignWeek

Let’s write more blog posts: an experiment

2019-08-06T00:00:00Z

As someone who blogs sometimes about my work, I often find myself talking to peers and colleagues who tell me they’d like to do the same but—for various reasons—they don’t feel they can.

When I asked on Twitter about the biggest barriers to blogging about work, people told me that they:

lack confidence in their writing skills
struggle to turn their ideas into blog posts
don’t think there’s value in what they have to say
lose momentum throughout the writing process
fear criticism from others

I’d really like to change this.

There’s always value in hearing someone’s unique perspective on an issue, even if that issue as a whole has been discussed at length. The world is always in need of new voices and different perspectives.

So how can we work together, as a community, to help each other to share more of our work in the open, safely and without judgement?

The idea

There are lots of ways we could approach this problem, but in the spirit of being agile—and not completely overcommitting myself—I’d like to start with a simple experiment and build on it based on what we learn.

I know a lot of people find sharing their work in big groups intimidating, so this idea involves working in pairs.

A problem shared is a problem halved

Let’s create a buddy system, partnering people who want to write a blog post, with people who are keen to support them, whilst learning more about the post’s topic.

For example, imagine that Person A wants to write a blog about designing forms for users of screen readers, but needs a bit of help writing it. And Person B, who blogs a lot, wants to learn more about accessibility in web design.

Wouldn’t it be great if they could team up and swap their skills in a way that benefits both of them? Person A gets help with their blog post, while Person B gets to deepen their knowledge of the subject matter.

Maybe in time, they could even switch roles, continuing to champion each other’s work, but now with Person B blogging while Person A provides feedback and advice.

I want to see if, by connecting people who can help each other, we can help 10 more people to share their work, and push 10 more blog posts out into the world.

So, in the spirit of keeping it simple, I’m calling this initiative “10 More Blog Posts”.

How to take part

You’ll need a Twitter account to take part.

1. Find a partner

First, decide whether you’re:

a blogger—you’ve got an idea what you want to write about, but you need some support building confidence, structuring your ideas or getting some friendly feedback on your work.
a content coach—maybe you’re a professional content designer, UX writer, editor, copywriter or just someone who’s good with writing blogs. Could you help someone write a blog post?

If you’re a blogger

Write a Tweet using the following template. Make sure you include the hashtag #10MoreBlogPosts so that content coaches can find you.

I'm taking part in the #10MoreBlogPosts challenge.

I'm a [job title] looking for a content coach to help me write a blog.

[If you have a specific idea, say what you’d like to write about here, for example, “I’d like to share lessons I’ve learned in my first year as a user researcher.”]

Let's team up!

bit.ly/2ZArL5O

If you’re a content coach

Write a Tweet using the following template. Make sure you include the hashtag #10MoreBlogPosts so that bloggers can find you.

I'm taking part in the #10MoreBlogPosts challenge.

I’ll help you write a blog. I’d love to learn about [say what you’d like to learn about, for example, service design in government].

Let's team up!

bit.ly/2ZArL5O

2. Pair up

Search #10MoreBlogPosts on Twitter to find someone to partner with.

Be flexible, and keep an open mind when it comes to different subject areas. There are lots of interesting things to learn from people outside of our direct networks and with different interests from our own.

Everybody’s goals will be slightly different so don’t worry if it takes a bit of time to find a partner.

When you find someone you’d like to pair with, reply to their Tweet, or drop them a direct message, and let them know.

Swap contact details and agree a time and a channel for an introduction.

If you’re struggling to find someone, or if the idea of asking on Twitter is just too excruciating, you can drop me an email at amy.l.hupe@gmail.com and I’ll see if I can help.

3. Get blogging

Agree with your partner how you want to work together. How often do you want to catch up? Where will you share drafts? And most importantly, what do you both want to get out of it?

Working together can involve anything from a quick proof-read just before publishing, a couple of agreed review points or even a pair-writing session. Lauren Currie’s post on how to start writing for the internet has some ideas on how to get started.

Most importantly, decide what works for you and your partner.

There’s only one rule: Be kind.

4. Report back

This is an experiment, and there’s only one way to know if it works.

Once you’ve finished working together, and hopefully published a shiny new blog, share your feedback on Twitter by using the #10MoreBlogPosts hashtag, or by emailing me at amy.l.hupe@gmail.com.

How will we know if it’s worked?

My plan is to try this for 3 months, until the 6 November 2019, and review the feedback I’ve received to see whether there’s any merit in this approach.

If it has, I’ll use the feedback to iterate as needed and provide some more detailed guidance on how to work together.

I’ll be taking part, too—as a content coach—so I can get some first-hand experience of what it feels like in practice.

Any questions?

I’ve kept this guidance deliberately lightweight for now because I think it’s important for people to set their own rules and objectives.

However, if anything’s not clear, you’re welcome to email me at amy.l.hupe@gmail.com and I’ll do my best to help you.

I’ve also set up a Slack organisation for people taking part in this challenge. If you’d like to join it, drop me an email and I’ll send you an invitation.

Good luck, and happy blogging :)

Acknowledgements

A big thank you to Lauren Currie, Amy Leak and Adam Silver who gave me the push I needed to get this idea off the ground and supported me in keeping it simple.

Thank you to Ignacia Orellana and Ollie Byford for their advice on the practicalities.

And thank you to the many people who responded to the Tweet that kicked it all off for your helpfulness, enthusiasm, and for not thinking this was a terrible, terrible idea!

Communicating inclusively beyond our products, services and users

2019-04-23T00:00:00Z

Inclusive communication lets people access and understand it, and feel safe and empowered to respond. It's being clear, honest, and mindful of the impact what we’re saying might have on those who encounter it.

There’s lots of information out there on how to create inclusive content. But the vast majority that I see focuses on how we communicate within our products and services, and the need for inclusive communication goes beyond that.

We also need to consider how we talk about our work, and other people’s. Whether it’s in person, in presentations, in blogs and articles we write, what we post on Twitter, on GitHub, in our Slack channels, and so on.

I believe we need to think beyond how we communicate with our users, and examine how we communicate with our colleagues and peers in the wider community, too.

Here, I’ll explain why using inclusive communication outside of a product or service matters, and what it means in practice.

Why inclusive communication matters

If we want to make an inclusive web, we need to foster an inclusive environment in which to make it.

Speaking on complexity of tooling, Jeremy Keith said:

“I firmly believe that, as Tim Berners-Lee put it, 'this is for everyone.' And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.”

Likewise, I believe that failing to communicate inclusively can raise and introduce barriers because people may:

not understand what’s been said
feel too afraid to respond
think it’s not intended for them

When this happens, it impacts us and our work as well as those we’ve excluded.

Government design principle number 10, Make things open, it makes things better, reminds us that “The more eyes there are on a service the better it gets–howlers are spotted, better alternatives are pointed out, the bar is raised.”

But that's only if those eyes know what they’re looking at and the voices attached to them are empowered to respond. If we don’t communicate inclusively, we significantly limit our opportunities for feedback.

We risk finding ourselves in an echo chamber, our assumptions and biases get reinforced, and we stop learning anything new.

To avoid this, we need to enable people to understand and participate in our processes and decisions. And we cannot achieve that without inclusive communication.

How to communicate inclusively

Expose the journey as well as the outcomes

As maths tests taught us, it’s important to show our workings. But sometimes it seems as though we’ve come to value certainty and finality over consideration and analysis.

Punchy statements like “this technology is obsolete” or “that approach is always harder” might be impactful, but they’re also reductive and dangerous. Talking in absolute terms about things which are not clear cut is misleading to newcomers and those with less experience. It also masks all the valuable experiences that led us to a particular conclusion in the first place.

Doubt, uncertainty and questioning are an integral part of building knowledge. Without them, we would never progress as individuals or as a community. It’s up to us to expose that uncertainty wherever we can.

If we strongly believe in something, we should do the work to make our case and convince others, as we were convinced.

Be clear and open

We strive for clarity when designing content for products and services, but we’re often less careful outside of this context.

There are lots of reasons why we might obscure information.

Sometimes, we don’t want to make ourselves look foolish by over-explaining.

We prefix statements with “Obviously…” or “As we know…” to protect ourselves against the possibility of unknowingly presenting common knowledge as new information.

But this is problematic, because it’s almost certain that some people won’t know what we’re telling them.

As Brad Frost observes:

“The amount of available knowledge in our field (or any field really) is growing larger, more complex, and more segmented all the time. That everyone has downloaded the same fundamental knowledge on any topic is becoming less and less probable.”

For people who don’t know the information we’re sharing, these qualifiers imply that they’re on the outside of a more knowledgeable circle. We need to make it OK not to know things and to ask questions.

Sometimes, we don’t explain things clearly because we simply don’t want to burden people with lots of complicated information.

I was recently messaging with someone on Twitter about this, and they told me:

“When I joined my team as a junior delivery manager, I got quite a lot of ‘it's very very technical, don't worry'. Except that's really isolating. If I'm part of this team, I need to know what you're talking about. If I don't know and you can't tell me, I'm on the outside.”

This clearly wasn’t malicious, but was no less excluding. If someone expresses a desire to be taught, we should take our cues from them, and teach.

Failing to give clear explanations can evoke feelings of self-doubt. Many people, when faced with something they don’t understand, blame themselves.

In a recent round of user research, we asked people with limited experience of code to follow guidance on creating prototypes from HTML and CSS.

When participants got stuck, no one said “this is not explained clearly enough”.

What many of them said instead was “I’m being so stupid”, “Sorry this is taking me so long”, and “You must think I’m such an idiot”.

In this case, we were actively seeking feedback and will use it to improve our content. But in a real-life situation, we often won’t have visibility over how our communication makes people feel, so we need to preempt the impact it might have.

What prior knowledge are we assuming and how could we do more to help those who might not have it? Can we explain ourselves more clearly, or direct people to a source of information that does?

Communicating inclusively doesn’t mean explaining every single concept in granular detail, but making the effort to share knowledge and lower the barrier to entry, where we can.

Be collaborative not combative

In my experience, the best way to effect positive change is with strategic, constructive conversations. But all too often, we encounter something we don’t like and become combative.

We’ve all seen those mic-drop statements on Twitter. The attention-hungry smackdowns designed to rally support against someone’s design or technology choices, to settle a score or to speak out against a perceived injustice.

There’s no denying this kind of communication is satisfying and powerful. There’s a reason Tweets like this commonly go viral. But they're not start points for collaborative conversations that lead to long term change.

Communication that leads to positive change is significantly harder. To do that, we have to learn to engage with those who think differently from us.

Why? Because aside from the hurt and harm it causes, attacking people like this is fruitless, most of the time.

When people's work is attacked or ridiculed in public, many become defensive and look for a sympathetic ally. They’ll seek reassurance that the attack was unkind and unjustified and if they chose their ally well, they’ll get it.

The most likely result of all this is that they’ll end up feeling vindicated and having their views reinforced. Ultimately, we’ve made the situation we thought was bad, even worse.

And the negative effects of these attacks are not limited to those they’re aimed at. Absolutist, sarcastic, attention-grabbing criticism is unlikely to make us seem particularly approachable, or to elicit a response from anyone other than those who understand and agree wholeheartedly or those who disagree and want an argument.

It leaves little space for people who simply don’t understand or who feel uncertain and too intimidated by our approach to engage.

How people respond to our messages and posts is a good indicator of how it’s made them feel.

If we see people prefixing their replies with modifiers like “This might be a silly question…” or “Sorry if I’m being stupid…”, it suggests they feel unsafe. They are asking for mercy.

And that’s only the ones who were brave enough to respond at all. Communicating like this sends a very clear message about how we’ll respond to those with whom we don’t agree, so many people simply won’t engage.

If we really care about righting a wrong, we have to do better.

We should start with questions, and a sincere effort to understand the context. People may be dealing with constraints we’re not aware of, or lacking the knowledge and experiences that we have.

When expressing concerns, we need to do so sincerely and with a collaborative intent.

Some hard truths about inclusive communication

I believe that if we want to do meaningful work to make things better, communicating inclusively is the place to start–but there are some possible side effects.

Inclusive communication might get less likes

Inclusive communication isn’t necessarily sexy. Being clearer and more considerate means we might have to use more words to make our point.

Some of our posts may be less straight down the line and hard hitting, and that may mean, in the short term at least, less likes and shares on social media.

But it’s a trade off. By communicating more inclusively and enabling more people to properly engage with us, we can build more lasting relationships and better quality connections.

We have to worry less about raising our profile and focus instead on raising our game.

Inclusive communication won’t convert everybody

Using inclusive communication is not a ticket to make everybody agree with us, nor should it be.

But when we use exclusionary communication, our chances are pretty much off the table.

Even the most clear, honest and collaborative approach won’t bring everyone round to our way of thinking, but it’s less likely to make people defensive, which lays the foundation for a more constructive conversation.

Communicating inclusively doesn’t mean everyone else will

Some people will always be challenging. They’ll anger and provoke us and when they do we’ll want to cast aside these principles and retaliate. And sometimes we probably will.

But resisting the urge when we can is a better decision in the long run. It's about focusing on how inclusive communication benefits the community, and not the individual who’s in our face at that particular moment in time.

When we're pushed, it's a choice between what we want now and what we want most.

Conclusion

Our communication is a powerful tool when it comes to making an inclusive web. It’s not enough to only think of those who use the web–we also need to consider those who make it.

Inclusive communication goes beyond the content inside our products and services–it’s how we communicate with our colleagues and peers, when we agree, and when we don’t.

It’s communicating in a way that helps people understand, respond to and participate in our work.

Every small change that makes our communication more inclusive brings us one step closer to a web for everyone.

I hope this has inspired you to make a small change today.

Acknowledgements

A big thank you to Adam Silver and Tim Paul for their detailed and constructive feedback on this article which helped me make it a lot better.

And thanks to Andy Bell who also provided helpful feedback, and whose article Break out of the echo chamber gave me the final push I needed to get on and write this.

The myth that design systems solve easy problems

2019-03-02T00:00:00Z

On Thursday, I read a brilliant blog post about Barnardo’s design system.

There’s lots to say about this work, but for now I want to focus on this paragraph:

“Designers and developers want to focus their time on solving the problems unique to their product, instead of spending time reinventing the wheel on things like how navigation should work or what a button should look like.”

I was surprised but happy to see this statement used in place of the common alternative, which says that “Design systems solve the easy problems, so teams can focus on fixing the hard ones”.

Let me explain.

Design systems fix the common problems, not the easy ones

Design systems exist to stop teams doubling up their efforts fixing common, recurring problems, like how to write an error message or create a call to action on a page.

By providing tried and tested solutions to these problems, supported with usage guidelines and code, they can reduce duplication of effort and create consistency across one or more products.

But ask almost anyone who has worked on or contributed to a design system and they’ll tell you there’s nothing easy about it.

Making something that meets the needs of hundreds, maybe thousands of users, accommodates organisational requirements and limitations, and is versatile enough to be reused, is really very hard indeed.

Hard work is your best selling point, don't understate it

I don’t have evidence for this, but I strongly suspect that one reason we describe design system problems as “easy” is because we think it’ll help drive adoption.

By reducing the development of user interface elements and interactions to an “easy problem”, we think we’ll somehow put people off wanting to do it themselves and convince them to adopt the design system instead.

After all, who on earth would want to waste their time doing something as menial as designing a button when they could be focusing on so many more important, interesting, difficult problems?

It’s a nice narrative, but it doesn’t hold up. It’s too reductive and it undermines the hard work of design system teams and contributors.

Not just that, but it's precisely the kind of hard work that goes into laying the foundations that makes people want to use a design system.

It’s far better to sell it on its strengths, and with an honest portrayal of all the hard work that’s gone into it.

Design system problems are everyone's problems

By saying “Design systems solve the easy problems, so teams can focus on fixing the hard ones”, it suggests that design system problems are solely the responsibility of a design system team.

But contribution and participation from the wider community is integral to a system’s success. A good design system needs to fairly represent the people it serves.

That means sharing responsibility for creating, maintaining and evolving the components and patterns provided.

Put simply, you'll only end up with a design system that works for the whole community, if the whole community helps to build it.

A design system is not just a set of patterns

Providing common design solutions is just one of the hard problems that design system teams have to contend with.

You need to support teams who adopt the system. Unless your system was built at exactly the same time as all of your organisation, you’ll likely need to help teams embed it into existing products and services. Not just once but continuously.

It’s not enough to just publish a component or a pattern and leave it there to rot. You have to enable people to feedback on its performance, and use that feedback to evolve it iteratively over time.

As I touched on above, you need to get people to contribute their own work and research. Again, not just once but constantly and continuously.

To say this is challenging is an understatement. We’ve been developing the contribution model for the GOV.UK Design System for the best part of 2 years, and we’re not done yet. Not even close.

As my colleague Nick Colley put it:

“It's easy to build something that no one can use or input into. It's hard to build something that's useful for many teams and can be contributed to.”

We are not competing for hard problems

Working on a design system is hard. Working on a product or service team is hard, too. There are more than enough hard problems to go around and the difficulty of one doesn’t diminish the difficulty of another.

The job of a product or service team is to deliver helpful, considerate and positive solutions to help meet its users needs.

The job of a design system is to provide a start point for the common problems–a set of reusable solutions validated through robust research, and continually iterated upon with help from the community.

It's only by sharing the load of our problems, both the easy and the hard ones, that we'll stand a chance of solving them.

Acknowledgements

Thank you very much to Ignacia Orellana for your invaluable input in helping me make sense of these thoughts.

Handling example copy in design systems

2019-02-22T00:00:00Z

Earlier this week, I took to Twitter to ask a question. I wanted to know more about the different approaches people take to handling the copy (words) in design system examples.

But first things first.

What is a design system?

Design systems help organisations create consistency across one or more products. In large organisations especially, they also stop teams from having to solve problems that have already been solved by other teams.

You’ll find many a definition of design systems floating around the internet and in books (remember books?) but in this article, I’m defining a design system as a collection of:

code and tools, like design layout or prototype-making software
processes like peer reviews and quality assurance
best practice guidelines like content and visual style guides
reusable designs for common user interface elements like buttons, tables, links, headers and footers
solutions or design patterns for common user tasks like signing in or out of a website, searching for something or filling in a form

Design systems contain lots of documented examples, and those examples often include copy.

This copy doesn't replace a general content style guide, but it can help to reinforce best practice, and give guidance for more specific scenarios.

Types of example copy

Broadly speaking, there are 3 different types of example copy you can use – instructive, realistic, or placeholder copy.

Instructive copy

Instructive copy describes what information is needed to replace it. For instance, instructive copy on a button example might say “[button text]” or “button text goes here”.

Realistic copy

Realistic copy is what it sounds like. It’s an example of the actual copy that might be used in a real-life situation. In the button example, realistic copy might be “Confirm and send” or “Get a quote”.

Placeholder copy

Placeholder copy is dummy text, the most famous example being Lorem Ipsum. It shows how content will fill a space, whilst aiming not to distract the viewer with readable content. Lorem Ipsum, as well as derivatives like Hipster Ipsum and Bacon Ipsum, are commonly used in prototype applications, page designs and editorial layouts.

Which type of copy works best in design system examples?

Welcome back to my original question. In the case of design system examples, is it best to use instructive, realistic or placeholder copy, a mix of these, or something else entirely?

In the GOV.UK Design System, which I work on, we use realistic copy in most of our examples.

Radio buttons example in the GOV.UK Design System using realistic copy.

We’ve found it helps to give our users an idea of how something works in context and shows, at least implicitly, what good copy looks like.

This works especially well for things where the context is specific, like our asking for names or email addresses patterns. In these cases, a Design System user can just take the copy and it will likely make sense in their service.

But for other things, like a text input or table component we really can’t know what context it’s going to be used in.

If the user’s context is different, which it often will be, we’re not providing them with a template or structure that they can tailor to their needs.

With realistic copy, they’ll have to adapt what we’ve given to suit their use case, or start from scratch.

In this instance, is instructive copy more useful? Should we stick with realistic copy, but provide more examples to cover the most popular use cases? Should we use a combination?

I wanted to find out what other people were doing, so I went on Twitter and asked.

People who work on #designsystems I have a question. When an example includes copy, like the words on a button, do you use:

- instructive/illustrative text eg “button text goes here”
- realistic copy eg “submit”
- Lorem Ipisum
- a mixture of those
- something else

And why?
— Amy Hupe (@Amy_Hupe) February 18, 2019

What Twitter thought

I got a tonne of really useful responses.

There was an overwhelming preference for using realistic copy, as it:

helps users to understand the context in which something could be used, without having to imagine it
makes it easier to evaluate the efficacy and appropriateness of a component or pattern
gives hints about the correct content formatting, like length, case, grammar and punctuation

However, instructive copy does have some advantages. A system would struggle to predict every possible application of its components and prescribe a precise solution. And it shouldn’t try to either.

One benefit of instructive example copy is that some consistency can still be established by providing rules and a structure to follow.

And there’s always the option of a hybrid approach. At least 2 people told me they use a mixture of instructive and realistic example copy.

Deliveroo uses this approach in their content design examples. For example, their toggles and switches pattern copy is:

Toggle on

Label: [The thing] for example, Notifications Subcopy: [The result of the on state] for example, You’ll get notifications

Toggle off

Label: [The thing] for example, Notifications Subcopy: [The result of the off state] for example, No notifications for you

In this example, instructive text allows Deliveroo to communicate the structure and intention of the copy, while realistic copy shows how it works in practice.

Is a mix of instructive and realistic copy the answer?

Using a hybrid approach like Deliveroo has definite advantages. It enables users to find content design guidelines and best practice examples in one place.

That said, I’d use it with caution for context-specific patterns. For example, asking users for common information like names or addresses, or familiar interactions like signing in or out.

In these instances, there’s less of a need to tailor the copy, so instructive text may well be overkill. An example with realistic, well-tested copy is probably all you need.

And what about Lorem Ipsum?

Frankly, it wasn’t popular. Not one person in my Twitter thread recommended using it, and many warned against doing so. Not least because of the risk of Lorem Ipsum ending up in live services by mistake.

Using realistic or instructive copy in design system examples is a much better way to communicate the intention and use of a component or pattern.

There’s also an implication that by using placeholder copy in designs, the content is being treated as an add on.

As a content designer, I probably don’t need to explain why that doesn't sit well with me.

As Eli Montgomery put it:

"Content matters and designing with fake content means we're not going to make it right.

Design makes content work. Not the other way around."

A big thank you to everyone who responded to my Tweet and helped inform this article. If this sparked your interest, you can read the whole thread on Twitter.

Don't mistake volume for confidence

2019-02-06T00:00:00Z

I’ve found myself talking about anxiety recently with a few people who didn’t know I suffer with it.

There’s no special reason for them not knowing. I stopped trying to hide my anxiety a good few years ago – I just don’t feel compelled to talk about it much. Frankly, I just don’t feel it’s the most important or interesting thing about me.

Nevertheless, I found myself having these conversations – 3 separate conversations in fact – and saying some words about my own anxiety. And all 3 of the people I was talking to reacted in the same way. They said “I never knew you had anxiety. You always seem so confident”.

Now, there’s absolutely nothing wrong with that reaction. It didn’t hurt my feelings and the people who said it certainly weren’t speaking out of malice. But it did make me think about some of the misconceptions that people might have about anxiety.

Me and anxiety

To give a little bit of background, I have suffered with anxiety virtually my entire life. I’ve suffered crippling panic attacks which I’ve mostly learned to manage. But every now and then one will come out of nowhere and remind me I’m not immune.

I’ve been in and out of therapy since I was a child, and I’m having cognitive behavioural therapy (CBT) now to help me with a persistent phobia of overseas travel.

We also work on some of my day-to-day negative thought patterns and core beliefs – like how I’m not capable of dealing with certain situations like travelling, and minor illness and ailments, and conflict. Or that I’m just inherently weaker, worse and less intelligent than everyone around me.

That last bit is usually where people seem most surprised, and that’s probably because of how I behave.

Being anxious and extroverted

I don’t really believe in the whole idea of introverts and extroverts as fixed, binary personality types. I think that most of us will alternate at least occasionally between the two. But extroversion is most definitely a trait, and it’s one I exhibit a lot of.

I like thinking mostly out loud and talking to other people, most of the time. I talk a lot and, especially when I’m excited or anxious about something, I talk loudly. I can be assertive if I need to. I challenge things I’m unsure of, and I don’t shy away from asking difficult questions.

I think this is where the confusion comes in. People see me being talkative, outgoing and sometimes firm and they equate that with confidence.

It’s not an illogical assumption, either. Constantly sharing my thoughts and ideas might well seem like a strange thing to do if I’m full of self-doubt. But self-doubt is precisely the reason I do it.

I’m not afraid of showing weakness, but I’m terrified of making poor decisions. For me, thinking or working in isolation is a breeding ground for uncertainty and negative self-talk.

Seeking guidance, feedback and reassurance from others is my way of building confidence, and protecting myself against my own perceived incompetence.

In fact, I’d go as far as to say that generally the more extroverted I’m being, the more anxious I’m feeling.

As for assertiveness, it hasn’t come naturally to me. It took me a long time to realise I could be decisive and firm without damaging the personal and professional relationships I depend on.

Even now, many of those who experience me being particularly insistent on a matter will later receive a private apology, worried I’ve overstepped the mark.

Managing anxiety at work

None of this is to say I don’t manage these tendencies. My career has forced me to challenge my urge to rely solely on others and to think for myself. And thank goodness for that.

I’ve learned to make decisions based on my experience and professional judgement, and in doing so have built a wealth of evidence that I can in fact do it.

I’ve learned to speak my mind and afterwards trust that I did so respectfully and sensitively. I can be firm without always descending into a spiral of anxiety that I might have upset someone.

But for me, that pull towards second-guessing myself and deferring to others is something I’ll always have to work against.

Let's keep talking about mental health

I started this post by saying I don’t feel the need to talk about my anxiety, and to some extent that remains true. But I’m talking about it today because I believe this is something people should understand.

If people mistake volume for confidence, then my volume might trick someone into thinking I’m completely fine. That I’m just another person who doesn’t understand what they’re going through. And I’m not OK with that.

Anxiety can assume the guise of withdrawal and silence. But it can just as easily be energetic and communicative. The thing it always is, is awful.

So let’s keep talking about it, in all of its manifestations, and supporting each other the very best that we can.

Why every design system needs a service designer

2018-12-19T00:00:00Z

I saw a job advert recently — an organisation was hiring people for its new design system team.

They were looking for developers, interaction designers, user researchers, product and delivery managers. There were even spots for a couple of content designers (we’re a depressingly rare breed in design system teams).

But there was one glaring omission: they weren’t hiring a service designer.

After just over a year, our service designer is about to leave our team and move onto her next project. Seeing the gap in that recruitment plan made me reflect on the value she’s brought to our team in her time here and just how much we couldn’t have done without her.

Here are just 4 of the valuable lessons I’ve learnt from working with our service designer, and why I think every design system needs one.

1. Put community before ego

When working on a design system, a lot of the focus tends to be on the stuff it contains and the speed with which you can deliver it.

Practically, it’s often quicker to knuckle down and deliver it yourself. Reaching outside of the team means more opinions to negotiate and time spent teaching others about your conventions and processes.

But building a community is what differentiates a design system from a pattern library. You need people to participate by using it, contributing to it and advocating for it, and you need to foster a whole lot of goodwill to achieve that.

And that’s where service designers come in. They, ours in particular, possess an incredible natural instinct towards collaboration.

Eliciting cooperation from disparate groups of stakeholders is no mean feat, but it’s essential if you’re trying to engage a large organisation and get it to converge on a collection of patterns.

By valuing the whole over the individual, our service designer has empowered people to participate. She’s worked transparently, sharing and documenting her work to involve others, and in doing so has ensured its longevity. This doesn’t happen if you focus on individual ownership.

Prioritising collaboration even, sometimes, at the expensive of short term efficiency, makes a design system far more sustainable in the long run.

2. Favour action over deliberation

One of the government design principles is ‘Make things open, it makes things better’. The belief that by sharing work with others and receiving feedback improves its quality and reduces risks.

In practice, there is usually a good amount confidence-building that happens before something is shared in the open. You’ll mull over your idea first, make personal notes and sketches. You may discuss it with one or two team members, consider its merit, adjust it, then reconsider it.

This deliberation in the safety of a small group is a way of strengthening conviction before an idea or a piece of work is shared more widely, ensuring that the pitch is honed and challenges are expected and prepared for.

While there’s some value in that, working with our service designer has taught me that there’s infinitely more reward in having the courage to take action and make things open earlier.

She regularly turns to me at the end of a discussion and says “so what are we going to do?”. My natural instincts urge me to continue the discussion, but she’ll challenge me to make something happen.

I’d be lying if I said it wasn’t daunting at first, this pressure to share my ideas in the open before they were fully developed. The idea that someone might spot a flaw I could have preempted is uncomfortable, but that’s ego talking.

Turning deliberation into an artefact, a pilot process or a blog creates a talking point. It exposes strengths and the weaknesses immediately, accelerates discussion and alignment, and takes you far more quickly from an idea to a good idea.

3. Be both a decision maker and a doer

It’s a popular belief that at some stage in your career you have to kiss goodbye to practice and step into a world of theory. That in order to progress, you start planning and stop participating.

But good service design requires a good deal of both. You have to pitch in and immerse yourself in the detail, and you have to know when to step away and take stock of the big picture.

When helping us to develop our contribution process, our service designer spent weeks interviewing both past and potential contributors, researching open source models and understanding the challenges and opportunities at play. She used this to develop an impressively intricate contribution journey map, and helped the team to translate these learnings into a well-oiled contribution model.

She helped us create documentation detailing the steps and expectations for contributors, the assurance process, and what our team would do to support these activities.

Her attention to detail impressed me, but what impressed me more was her ability to step away.

Despite all she’d invested in it, when the time came, she quietly relinquished control. She moved onto the next challenge, entrusting the team and community to continue this work.

And that’s what good service design is. It’s mucking in, not just understanding the detail but experiencing it. Immersing yourself in the minutiae, gaining empathy for users by getting the full picture, and then zooming out again. Attention to detail is important but transient. Attention to the service remains a constant.

4. Practice human-centred design, always

When people talk about design systems, they tend to focus on the platform, the features and the significance of technology choices.

But making a design system work is not about bells and whistles. Success lies in how well it’s adopted into an organisation’s culture, processes and infrastructure, and the key to all of that is people.

Thinking in a more human way has led us to ask bigger questions of our service. How could we involve more people? How do we win trust? Where can we do better?

From helping us provide the best possible support to users when they get stuck, to enabling the wider community to contribute, our service designer has driven us to maintain a constant and necessary focus on our users.

By challenging us to be more considerate, more inclusive and more accommodating to our users, she’s taken us from building a product to delivering a service that puts people at its heart.

The value of service design

The value of service design can be tricky to quantify. It’s not one thing, but a thousand little things. From a shared sense of purpose cultivated within a team or community, to the collection of incremental improvements that combine to transform user experiences.

For me personally, it would be hard to overstate the value of our service designer’s input and support in the time we’ve worked together. As well as a valued colleague, she’s become my friend, and I’ll continue to watch and learn from her after she’s moved.

So my one piece of advice to you is this: if you’re building a design system, be sure to include a service designer — you’re going to need one.