Journal tags: design

UX London isn’t the only event from Clearleft coming your way in 2025. There’s a brand new spin-off event dedicated to user research happening in February. It’s called Research By The Sea.

I’m not curating this one, though I will be hosting it. The curation is being carried out most excellently by Benjamin, who has written more about how he’s doing it:

We’ve invited some of the best thinkers and doers from from in the research space to explore how researchers might respond to today’s most gnarly and pressing problems. They’ll challenge current perspectives, tools, practices and thinking styles, and provide practical steps for getting started today to shape a better tomorrow.

If that sounds like your cup of tea, you should put February 27th 2025 in your calendar and grab yourself a ticket.

Although I’m not involved in curating the line-up for the event, I offered Benjamin my swor… my web dev skillz. I made the website for Research By The Sea and I really enjoyed doing it!

These one-day events are a great chance to have a bit of fun with the website. I wrote about how enjoyable it was making the website for this year’s Patterns Day:

I felt like I was truly designing in the browser. Adjusting spacing, playing around with layout, and all that squishy stuff. Some of the best results came from happy accidents—the way that certain elements behaved at certain screen sizes would lead me into little experiments that yielded interesting results.

I took the same approach with Research By The Sea. I had a design language to work with, based on UX London, but with more of a playful, brighter feel. The idea was that the website (and the event) should feel connected to UX London, while also being its own thing.

I kept the typography of the UX London site more or less intact. The page structure is also very similar. That was my foundation. From there I was free to explore some other directions.

I took the opportunity to explore some new features of CSS. But before I talk about the newer stuff, I want to mention the bits of CSS that I don’t consider new. These are the things that are just the way things are done ‘round here.

Custom properties. They’ve been around for years now, and they’re such a life-saver, especially on a project like this where I’m messing around with type, colour, and spacing. Even on a small site like this, it’s still worth having a section at the start where you define your custom properties.

Logical properties. Again, they’ve been around for years. At this point I’ve trained my brain to use them by default. Now when I see a left, right, width or height in a style sheet, it looks like a bug to me.

Fluid type. It’s kind of a natural extension of responsive design to me. If a website’s typography doesn’t adjust to my viewport, it feels slightly broken. On this project I used Utopia because I wanted different type scales as the viewport increased. On other projects I’ve just used on clamp declaration on the body element, which can also get the job done.

Okay, so those are the things that feel standard to me. So what could I play around with that was new?

View transitions. So easy! Just point to an element on two different pages and say “Hey, do a magic move!” You can see this in action with the logo as you move from the homepage to, say, the venue page. I’ve also added view transitions to the speaker headshots on the homepage so that when you click through to their full page, you get a nice swoosh.

Unless, like me, you’re using Firefox. In that case, you won’t see any view transitions. That’s okay. They are very much an enhancement. Speaking of which…

Scroll-driven animations. You’ll only get these in Chromium browsers right now, but again, they’re an enhancement. I’ve got multiple background images—a bunch of cute SVG shapes. I’m using scroll-driven animations to change the background positions and sizes as you scroll. It’s a bit silly, but hopefully kind of cute.

You might be wondering how I calculated the movements of each background image. Good question. I basically just messed around with the values. I had fun! But imagine what an actually-skilled interaction designer could do.

That brings up an interesting observation about both view transitions and scroll-driven animations: Figma will not help you here. You need to be in a web browser with dev tools popped open. You’ve got to roll up your sleeves get your hands into the machine. I know that sounds intimidating, but it’s also surprisingly enjoyable and empowering.

Oh, and I made sure to wrap both the view transitions and the scroll-driven animations in a prefers-reduced-motion: no-preference @media query.

I’m pleased with how the website turned out. It feels fun. More importantly, it feels fast. There is zero JavaScript. That’s the main reason why it’s very, very performant (and accessible).

Smooth transitions across pages; smooth animations as you scroll: it’s great what you can do with just HTML and CSS.

Is it too early to start planning for 2025 already? Perhaps. But you might want to add some dates to your calender:

June 10th, 11th, and 12th, 2025.

That’s when UX London will return!

It’ll be be back in CodeNode. That’s the venue we tried for the first time this year and it worked out really well.

You can look forward to three days of UX talks and workshops:

1. Tuesday, June 10th is Discovery Day—user research, content strategy, and planning.
2. Wednesday, June 11th is Design Day—interaction design, accessibility, and interface design.
3. Thursday, June 12th is Delivery Day—iteration, design ops, and cross-team collaboration.

I realise that the alliteration of discovery, design, and delivery is a little forced but you get the idea. The flow of the event will follow the process of a typical design project.

The best way to experience UX London is to come for all three days, but each day also works as a standalone event.

I’m now starting the process of curating the line-up for each day: a mix of inspiring talks and hands-on workshops. If you trust me, you can get your ticket already at the super early-bird price.

If you reckon you’d be a good addition to the line-up, here’s a form you can fill out.

Now, I’ll be up-front here: if you’re a typical white dude like me, you’re not going to be top of the pile. My priority for UX London is creating a diverse line-up of speakers.

So if you’re not a typical white dude like me and you’ve ever thought about giving a conference talk, fill out that form!

If you don’t fancy speaking, but you want to see your company represented at UX London, check out our sponsorship options.

If you don’t want to speak and you don’t want to sponsor, but you want to be at the best design conference of 2025, get your ticket now.

The datalist element is good. It was a bit bumpy there for a while, but browser implementations have improved over time. Now it’s by far the simplest and most robust way to create an autocompleting combobox widget.

Hook up an input element with a datalist element using the list and id attributes and you’re done. You can even use a bit of Ajax to dynamically update the option elements inside the datalist in response to the user’s input. The browser takes care of all the interaction. If you try to roll your own combobox implementation, it’s almost certainly going to involve a lot of JavaScript and still probably won’t account for all use cases.

Safari on iOS—and therefore all browsers on iOS—didn’t support datalist for quite a while. But once it finally shipped, it worked really nicely. The options showed up just like automplete suggestions above the keyboard.

But that broke a while back.

The suggestions still appeared, but if you tapped on one of them, nothing happened. The input element didn’t get updated. You had to tap on a little downward arrow inside the input in order to see the list of options.

That was really frustrating for anybody on iOS using The Session. By far the most common task on the site is searching for a tune, something that’s greatly (progressively) enhanced with a dynamically-updating datalist.

I just updated to iOS 18 specifically to see if this bug has been fixed, and it has:

Fixed updating the input value when selecting an option from a datalist element.

Hallelujah!

But now there’s some additional behaviour that’s a little weird.

As well as showing the options in the autocomplete list above the keyboard, Safari on iOS—and therefore all browsers on iOS—also pops up the options as a list (as if you had tapped on that downward arrow). If the list is more than a few options long, it completely obscures the input element you’re typing into!

I’m not sure if this is a bug or if it’s the intended behaviour. It feels like a bug, but I don’t know if I should file something.

For now, I’ve updated the datalist elements on The Session to only ever hold three option elements in order to minimise the problem. Seeing as the autosuggest list above the keyboard only ever shows a maximum of three suggestions anyway, this feels like a reasonable compromise.

UX London is just three weeks away! If you haven’t got your ticket yet, dally not.

There’s a last-minute addition to the line-up: Peter Boersma.

Peter is kindly stepping into the slot that Kara Kane was going to be occupying. Alas, since a snap general election was recently announced, Kara isn’t able to give her talk. There’s an abundance of caution in the comms from gov.uk in this pre-election period.

It’s a shame that Kara won’t be able to speak this time around, but it’s great that we’ve got Peter!

Peter’s talk is perfect for day three. Remember, that’s the day focused on design ops and design systems. Well, Peter lives and breathes design ops. He’ll show you why you should maintain a roadmap for design ops, and work with others to get the initiatives on it done.

You can get a ticket for an individual day of talks and workshops, or go for the best-value option and come for all three days. See you there!

I really like the newly-launched website for this year’s XOXO festival. I like that the design is pretty much the same for really small screens, really large screens, and everything in between because everything just scales. It’s simultaneously a flyer, a poster, and a billboard.

Trys has written about the websites he’s noticed using fluid type and spacing: There it is again, that fluid feeling.

I know what he means. I get a similar feeling when I’m on a site that adjusts fluidly to any browser window—it feels very …webby.

I’ve had this feeling before.

When responsive design was on the rise, it was a real treat to come across a responsive site. After a while, it stopped being remarkable. Now if I come across a site that isn’t responsive, it feels broken.

And now it’s a treat to come across a site that uses fluid type. But how long will it be until it feels unremarkable? How will it be until a website that doesn’t use fluid type feels broken?

When I documented my approach to HTML web components I sang the praises of composability:

Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes.

I feel the same way about design systems. In my experience, the design systems that encourage mixing and matching different combinations are the ones that actually get used.

The design systems that struggle with adoption often have the best of intentions. “Look, there are all these pre-made components for you—you should just use them!” But that can be very disempowering. Where’s the sense of agency in using a pre-made solution?

Robin wrote a fascinating post recently called The Other Side (almost certainly not a reference to the Salter Cane song of the same name). He went from being on a design system team trying to enforce adoption to being on a team on the receiving end:

I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.

But by golly if a design system says “no” to me then I will do my very best to blow it up.

Colours, spacing, type; these are all building blocks that a designer can compose with. But it gets murkier after that. Pre-made form fields? Sure. Pre-made forms? No thank you!

It’s like there’s a line where a design system crosses over from being a useful toolkit into being a bureaucratic hurdle to overcome. When you hear a designer complaining that a design system is stifling their creativity, I bet it’s because that line has been crossed.

There’s a tired cliché of an analogy when it comes to design systems: LEGO. It’s not a good analogy but I think it can help to understand this imbalance.

Remember old-school LEGO? The pieces were unopinionated. You had to use your imagination to combine them into something.

Later we got LEGO kits. You followed instructions to create a pre-ordained final combination.

I’m not just being an old man yelling at a cloud when I say that those later sets were different. Not bad, necessarily. But the fun came from cosplaying as a factory worker rather than inventing from whole cloth.

There are certainly organisations where pre-made kits are going to be useful. But when you start mandating their use, don’t be surprised when you get pushback from designers who miss the combinatorial power of using simple building blocks. As Robin says:

I want the design system to carefully guide me instead of brute-forcing its decisions onto my work.

Brad recently wrote about the art of design system recipes. Recipes are combinations of the building blocks in a design system, but they’re not intended to be The One True Way for everyone else solving a similar problem. It’s totally fine if a recipe is a one-off solution.

The design system’s core components are the ingredients stocked in the pantry. Other product designers then take those ingredients to create product-specific compositions that meet their product needs.

I suspect that a lot of design systems have made the mistake of canonising recipes too soon, mandating their use.

A Darwinian approach works better. If multiple people keep creating the same recipe independently then and only then should it be considered for inclusion in the design system.

A design system team should be reluctant to allow a new component into the inner sanctum. Instead I see design system teams eager to mint as many ready-made components as possible.

But if the true test of a design system is in its adoption, then the safest bet is to stick to the basic building blocks. Support designers by taking care of their baseline needs. But don’t stop them from composing.

UX London runs for three days, from June 18th to 20th. If you can, you should get a ticket for all three days. But if you can’t, you can get a one-day ticket. Think of each individual day as being its own self-contained conference.

The flow of the three-day event kind of mimics the design process itself. It starts with planning and research. Then it gets into the nitty-gritty product design details. Then it gets meta…

Day three, Thursday, June 20th is about design systems and design ops.

Maintenance matters, not just for the products and services you’re designing, but for the teams you’re designing with. You can expect a barrage of knowledge bombs on alignment and collaboration.

The bombardment commences with four great talks in the morning.

1. Brad Frost kicks things off with the question is atomic design dead? Brad will show you how to imagine what a global design system might look like.
2. Alicia Calderón is going to be talking about unlocking collaboration . Alicia will show you how to use a framework for creating lasting aligment between developers and designers.
3. Benaz Irani will be speaking about empathy overload. Benaz will show you how to strike a balance between compassion and confidence within your team.
4. Kara Kane is going to talk about why UX building blocks need standards. Kara will show you how to use standards to enable adoption and contribution to design systems.

After the lunch break you’ll have your pick of four superb workshops. It’s not an easy choice.

1. Brad Frost is not only giving a talk in the morning, he’s also leading an afternoon workshop on the design system ecosystem. Brad will show you how to unpack the many layers of the design system layer cake so you can deliver sturdy user interfaces and help teams work better together.
2. Stéphanie Walter is running a workshop on designing adaptive reusable components and pages . Stéphanie will show you how to plan your content and information architecture to help build more reusable components.
3. Tom Kerwin will be giving a workshop on multiverse mapping. Tom will show you how to pin down your product strategy and to align your team around the stuff that matters.
4. Luke Hay is running a workshop on bridging the gap between Research and Design. Luke will show you how to take practical steps to ensure that designers and researchers are working as a seamless team.

Finally we’ll finish the whole event with one last closing keynote. I’m very excited to announce who that’s going to be—I’ll only keep you on tenterhooks for a short while longer.

When step back and look at what’s on offer, day three of UX London looks pretty unmissable. If you work with a design system or heck, if you just work with other people, this is the day for you. So get your ticket now.

But be sure to use this discount code I’ve prepared just for you to get a whopping 20% off the ticket price: JOINJEREMY.

If you can’t make it to all three days of this year’s UX London, there’s always the option to attend a single day.

Day two is focused on product design. You know, the real meat’n’potatoes of working at the design coalface (to horribly mix my metaphors).

The day begins with four back-to-back practical talks.

1. John V Willshire gets the ball rolling with a big-picture talk on the product of design. John will show you how to think about futures rather than features.
2. Tshili Ndou follows on with her talk aboutvalidating features. Tschili will show you how to create high value products and avoid wasting money.
3. Wioleta Maj is up after the break with a talk on understanding the impact of design choices. Wioleta will show you how to identify who we are creating our designs for (and who we are not).
4. Harry Brignull closes out the morning with his call to action, Do Not Pass Go. Harry will show you how to get to grips with our industry’s failure to self-regulate when it comes to harmful design patterns.

After lunch, it’s decision time. Whereas the morning talks are sequential, the afternoon’s workshops run in parallel. You’ve got four excellent workshops to choose from.

1. Ben Sauer will be giving a workshop on the storytelling bridge . Ben will show you how to find your inner storyteller to turn your insights into narratives your stakeholders can understand quickly and easily.
2. Tom Kerwin will be giving a workshop on multiverse mapping. Tom will show you how to pin down your product strategy and to align your team around the stuff that matters.
3. Serena Verdenicci will be giving a workshop on behavioural intentions . Serena will show you how to apply a behavioural mindset to your work so you can create behaviour-change interventions.
4. Brad Frost will be giving a workshop on the design system ecosystem. Brad will show you how to unpack the many layers of the design system layer cake so you can deliver sturdy user interfaces and help teams work better together.

Finally there’s one last keynote talk at the end of the day. All will be revealed very soon, but believe me, it’s going to be a perfect finisher.

If a day of outstanding talks and workshops on product design sounds good to you, get your ticket now.

And just between you and me, here’s a discount code to get 20% of the ticket price: JOINJEREMY.

UX London is just two months away!

The best way to enjoy the event is to go for all three days but if that’s not doable for you, each individual day is kind of like a mini-conference with its own theme.

The theme on day one, Tuesday, June 18th is design research.

In the morning there are four fantastic talks.

1. Tom Kerwin kicks things off with his talk on pitch provocations. Tom will show you how to probe for what the market really wants with his fast, counterintuitive method.
2. Clarissa Gardner is giving a talk about ethics and safeguarding in UX research . Clarissa will show you how to uphold good practice without compromising delivery in a fast-paced environment.
3. Aleks Melnikova’s talk is all about demystifying inclusive research. Aleks will show you how to conduct research for a diverse range of participants, from recruitment and planning through to moderation and analysis.
4. Emma Boulton closes out the morning with her talk on meeting Product where they are. Emma will show you how to define a knowledge management strategy for your organisation so that you can retake your seat at the table.

After lunch you’ll take part in one of four workshops. Choose wisely!

1. Luke Hay is running a workshop on bridging the gap between research and design. Luke will show you how to take practical steps to ensure that designers and researchers are working as a seamless team.
2. Serena Verdenicci is running a workshop on behaviorual intentions. Serena will show you how to apply a behavioural mindset to your work so you can create behaviour-change interventions.
3. Stéphanie Walter is running a workshop on designing adaptive reusable components and pages. Stéphanie will show you how to plan your content and information architecture to help build more reusable components.
4. Ben Sauer is running a workshop on the storytelling bridge. Ben will show you how to find your inner storyteller to turn your insights into narratives your stakeholders can understand quickly and easily.

After your workshop there’s one final closing keynote to bring everyone back together. I’m keeping that secret for just a little longer, but trust me, it’s going to be inspiring—plenty to discuss at the drinks reception afterwards.

That’s quite a packed day. If design research is what you’re into, you won’t want to miss it. Get your ticket now.

Just to sweeten the deal and as a reward for reading all the way to the end, here’s a discount code you can use to get a whopping 20% off: JOINJEREMY.

I was in Amsterdam last week. Usually I’m in that city for an event like the excellent CSS Day. Not this time. I was there as a guest of Vasilis. He invited me over to bother his students at the CMD (Communications and Multimedia Design) school.

There’s a specific module his students are partaking in that’s right up my alley. They’re given a PDF inheritance-tax form and told to convert it for the web.

Yes, all the excitement of taxes combined with the thrilling world of web forms.

Seriously though, I genuinely get excited by the potential for progressive enhancement here. Sure, there’s the obvious approach of building in layers; HTML first, then CSS, then a sprinkling of JavaScript. But there’s also so much potential for enhancement within each layer.

Got your form fields marked up with the right input types? Great! Now what about autocomplete, inputmode, or pattern attributes?

Got your styles all looking good on the screen? Great! Now what about print styles?

Got form validation working? Great! Now how might you use local storage to save data locally?

As well as taking this practical module, most of the students were also taking a different module looking at creative uses of CSS, like making digital fireworks, or creating works of art with a single div. It was fascinating to see how the different students responded to the different tasks. Some people loved the creative coding and dreaded the progressive enhancement. For others it was exactly the opposite.

Having to switch gears between modules reminded me of switching between prototypes and production:

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

Here’s something I noticed: the students love using :has() in CSS. That’s so great to see! Whereas I might think about how to do something for a few minutes before I think of reaching for :has(), they’ve got front of mind. I’m jealous!

In general, their challenges weren’t with the vocabulary or syntax of HTML, CSS, and JavaScript. The more universal problem was project management. Where to start? What order to do things in? How long to spend on different tasks?

If you can get good at dealing with those questions and not getting overwhelmed, then the specifics of the actual coding will be easier to handle.

This was particularly apparent when it came to JavaScript, the layer of the web stack that was scariest for many of the students.

I encouraged them to break their JavaScript enhancements into two tasks: what you want to do, and how you then execute that.

Start by writing out the logic of your script not in JavaScript, but in whatever language you’re most comfortable with: English, Dutch, whatever. In the course of writing this down, you’ll discover and solve some logical issues. You can also run your plain-language plan past a peer to sense-check it.

It’s only then that you move on to translating your logic into JavaScript. Under each line of English or Dutch, write the corresponding JavaScript. You might as well put // in front of the plain-language sentence while you’re at it to make it a comment—now you’ve got documentation baked in.

You’ll still run into problems at this point, but they’ll be the manageable problems of syntax and typos.

So in the end, it wasn’t my knowledge of specific HTML, CSS, or JavaScript APIs that proved most useful to pass on to the students. It was advice like that around how to approach HTML, CSS, or JavaScript.

I also learned a lot during my time at the school. I had some very inspiring conversations with the web developers of tomorrow. And I was really impressed by how much the students got done just in the three days I was hanging around.

I’d love to do it again sometime.

The third Patterns Day happened yesterday. It was lovely!

The last time we had a Patterns Day was in 2019. After five years it felt very, very good to be back in the beautiful Duke Of York’s for another full day of design systems nerdery.

I wasn’t the only one who felt that way. A lot of people told me how much they enjoyed the event, which swelled my heart with happiness. I’m genuinely grateful to everyone who came—thank you so much!

The talks were, of course, excellent. I feel pretty good about the flow of the day. I tried to mix and match between big-picture talks with broad themes and nitty-gritty talks diving into details. The contrast worked really well.

In the pub afterwards it was fascinating to hear how much the different talks resonated with people. So many people felt seen, in the best possible way. It’s quite gratifying to hear that you’re not alone, that other people are struggling with the same kinds of issues with design systems as you are.

At the very first Patterns Day when it was still early days for design systems, there was still a certain amount of cheerleading, bigging up all the benefits of design systems. In 2024 there’s a lot more real talk about how much hard work there is. The design systems struggle is real.

There was another overarching theme at this year’s Patterns Day. Even though there was plenty of coverage of technical details like design tokens, typography and components, the big takeaway was all about people. Collaboration. Agreement. Community. These are the real foundations of a design system that works.

I’m so grateful to all the wonderful speakers yesterday for reminding us of what really matters.

Harry popped ’round to the Clearleft studio yesterday. It’s always nice when a Clearleft alum comes to visit.

It wasn’t just a social call though. Harry wanted to run through the ideas he’s got for his UX London talk.

Wait. I buried the lede. Let me start again.

Harry Brignull is speaking at this year’s UX London!

Yes, the person who literally wrote the book on deceptive design patterns will be on the line-up. And judging from what I heard yesterday, it’s going to be a brilliant talk.

It was fascinating listening to Harry talk about the times he’s been brought in to investigate companies accused of deliberately employing deceptive design tactics. It involves a lot of research and detective work, trawling through internal communications hoping to find a smoking gun like a memo from the boss or an objection from a beleaguered designer.

I thought about this again today reading Nic Chan’s post, Have we forgotten how to build ethical things for the web?. It resonates with what Harry will be talking about at UX London. What can an individual ethical designer do when they’re embedded in a company that doesn’t prioritise user safety?

It’s like a walking into a jets pray of bullshit, so much so that even those with good intentions get easily overwhelmed.

Though I try, my efforts rarely bear fruit, even with the most well-meaning of clients. And look, I get it, no on wants to be the tall poppy. It’s hard enough to squeeze money from the internet-stone these days. Why take a stance on a tiny issue when your users don’t even care? Your competitors certainly don’t. I usually end up quietly acquiescing to whatever bad are made, praying no future discerning user will notice and think badly of me.

It’s pretty clear to me that we can’t rely on individual people to make a difference here.

Still, I take some encouragement from Harry’s detective work. If the very least that an ethical designer (or developer) does is to speak up, on the record, then that can end up counting for a lot when the enshittification hits the fan.

If you see something, say something. Actually, don’t just say it. Write it down. In official communication channels, like email.

I remember when Clearleft crossed an ethical line (for me) by working on a cryptobollocks project, I didn’t just voice my objections, I wrote them down in a memo. It wasn’t fun being the tall poppy, the squeeky wheel, the wet blanket. But I think it would’ve been worse (for me) if I did nothing.

It is now exactly five weeks until Patterns Day—just another 35 sleeps!

Everthing is in place for a perfect day of deep dives into design systems. There’ll be eight snappy 30 minute talks—bam, bam, bam!

Here’s the schedule I’ve got planned for the day:

9:00	Registration.
9:45	Jeremy introduces the day.
10:00	Jina delivers the opening keynote.
10:30	Débora talks about the outcomes, lessons and challenges from using design tokens.
11:00	Break.
11:30	Yolijn talks about the relay method for design system governance.
12:00	Geri talks about her journey navigating accessibility in design systems.
12:30	Lunch.
14:00	Richard talks about responsive typography in design systems.
14:30	Samantha talks about getting buy-in for a design system.
15:00	Break.
15:30	Mary talks about transitioning from a single to a multi-brand design system.
16:00	Vitaly delivers the closing keynote.
16:30	Jeremy wraps up the day.
16:45	Have a drink and a geek pub quiz at the Hare And Hounds pub.

I assume you’ve got your ticket already, but if not use the discount code JOINJEREMY to get 10% off the ticket price.

See you there!

Patterns Day is exactly six weeks away—squee!

If you haven’t got your ticket yet, get one now. (And just between you and me, use the discount code JOINJEREMY to get a 10% discount.)

I’ve been talking to the speakers and getting very excited about what they’re going to be covering. It’s shaping up to be the perfect mix of practical case studies and big-picture thinking. You can expect talks on design system governance, accessibility, design tokens, typography, and more.

I’m hoping to have a schedule for the day ready by next week. It’s fun trying to craft the flow of the day. It’s like putting together a set list for a concert. Or maybe I’m just overthinking it and it really doesn’t matter because all the talks are going to be great anyway.

There are sponsors for Patterns Day now too. Thanks to Supernova and Etch you’re going to have bountiful supplies of coffee, tea and pastries throughout the day. Then, when the conference talks are done, we’ll head across the road to the Hare And Hounds for one of Luke Murphy’s famous geek pub quizes, with a bar tab generously provided by Zero Height.

Now, the venue for Patterns Day is beautiful but it doesn’t have enough space to provide everyone with lunch, so you’re going to have an hour and a half to explore some of Brighton’s trendy lunchtime spots. I’ve put together a list of lunch options for you, ordered by proximity to the Duke of York’s. These are all places I can personally vouch for.

Then, after the conference day, and after the pub quiz, there’s Vitaly’s workshop the next day. I will most definitely be there feeding on Vitaly’s knowledge. Get a ticket if you want to join me.

But wait! That’s not all! Even after the conference, and the pub quiz, and the workshop, the nerdy fun continues on the weekend. There’s going to be an Indie Web Camp here in Brighton on the Saturday and Sunday after Patterns Day.

If you’ve been to an Indie Web Camp before, you know how inspiring and fun it is. If you haven’t been to one yet, you should definitely come along. It’s free! If you’ve got your own website, or if you’re even just thinking about having your own website, it’s a great opportunity to meet with like-minded people.

So that’s going to be four days of non-stop good stuff here in Brighton. I’m looking forward to seeing you then!

The line-up for Patterns Day is complete! You’ll be hearing from eight fantastic speakers on March 7th 2024 here in Brighton.

I really like the mix of speakers we’ve got…

Half of the speakers will be sharing what they’ve learned from design systems in their organisations: Débora from LEGO, Mary from the Financial Times, Yolijn from the Dutch government, and Samantha from University College London. That’s a good spread of deep dives.

The other half of the speakers can go broad across design systems in general: Vitaly on design patterns, Rich on typography, Geri on accessibility, and Jina on …well, absolutely everything to do with design systems!

I’m so happy that I could get the line-up to have this mix. If you have any interest in design systems at all—whether it’s as a designer, a developer, a product manager, or anything else—you won’t want to miss this. Early bird tickets are £225.

But wait! That’s not all. If you really want to dive deep into interface design patterns, then stick around. The day after Patterns Day, Vitaly is running a one-day workshop:

In this in-person workshop with Vitaly Friedman, UX consultant and creative lead behind Smashing Magazine, we’ll dive deep into dissecting how to solve complex design problems. Whether you’re working on a complex nested multi-level navigation or creating enterprise grade tables, this workshop will give you the tools you need to excel at your work.

Places are limited. There isn’t room for everyone who’s going to be at Patterns Day, so if you—and your team—want to learn design pattern kung-fu from the master, get your workshop ticket now! Workshop tickets are £445.

It’s like a little mini conference season here in Brighton. Tomorrow is ffconf, which I’m really looking forward to. Last week was UX Brighton, which was thoroughly enjoyable.

Maybe it’s because the theme this year was all around creativity, but all of the UX Brighton speakers gave entertaining presentations. The topics of innovation and creativity were tackled from all kinds of different angles. I was having flashbacks to the Clearleft podcast episode on innovation—have a listen if you haven’t already.

As the day went on though, something was tickling at the back of my brain. Yes, it’s great to hear about ways to be more creative and unlock more innovation. But maybe there was something being left unsaid: finding novel ways of solving problems and meeting user needs should absolutely be done …once you’ve got your basics sorted out.

If your current offering is slow, hard to use, or inaccessible, that’s the place to prioritise time and investment. It doesn’t have to be at the expense of new initiatives: this can happen in parallel. But there’s no point spending all your efforts coming up with the most innovate lipstick for a pig.

On that note, I see that more and more companies are issuing breathless announcements about their new “innovative” “AI” offerings. All the veneer of creativity without any of the substance.

I’ve always associated good design with thoughtfulness. Like, I should be able to point to any element in an interface and the designer should be able to tell me the reasons it’s there. Those reasons may be rooted in user needs or asthetics or some other consideration, but the point is that there’s a justification for it. Justify every pixel!

But I’ve come to realise that this is a bit reductionist. Now when I point at an interface element, I still expect the designer to be able to justify its inclusion, but I’d also like to know the trade-offs that were made.

Suppose there’s a large hero image. I’m sure the designer would have no problem justifying its inclusion on the basis of impact and the emotional heft it delivers. But did they also understand the potential downsides? Were they aware of the performance implications of including a large image?

I hope the answer to both questions is yes. They understood the costs, but they decided that, on balance, the positives outweighed the negatives.

When it comes to the positives, universal principles of design often apply. Colour theory, typography, proximity, and so on. But the downsides tend to be specific to the medium that the design is delivered in.

Let’s say you’re designing for print. You want to include an extra typeface just for footnotes. No problem. There isn’t really a downside. In print, you can use all the typefaces you want. But if this were for the web, then the calculation would be different. Every extra typeface comes with a performance penalty. A decision that might be justified in one medium might not work in another medium.

It works both ways; on the web you can use all the colours you want, without incurring any penalties, but in print—depending on the process you’re using—you might have to weigh up that decision very differently.

From this perspective, every design decision is like a balance sheet. A good web designer understands the benefits and the costs behind each decision they make.

It’s a similar story when it comes to web development. Heck, we even have the term “tech debt” to describe decisions that we know aren’t for the best in the long term.

In fact, I’d say that consideration of the long-term effects is something that should play a bigger part in technical decisions.

When we’re weighing up the pros and cons of using a particular tool, we have a tendency to think in the here and now. How might this help me right now? How might this hinder me right now?

But often a decision that delivers short-term gain may well end up delivering long-term pain.

Alexander Petros describes this succinctly:

Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.

When I wrote about making the Patterns Day website I described my process as doing it “the long hard stupid way”—a term that Frank coined in a talk he gave a few years back. But perhaps my hands-on approach is only long, hard and stupid in the short time. With each passing year, the codebase will retain a degree of readability and accessibility that I would’ve sacrificed had I depended on automated build processes.

Robin Berjon puts this into the historical perspective of Taylorism and Luddism:

Whenever something is automated, you lose some control over it. Sometimes that loss of control improves your life because exerting control is work, and sometimes it worsens your life because it reduces your autonomy.

Or as Marshall McLuhan put it:

Every extension is also an amputation.

…which is fine as long as the benefits of the extension outweigh the costs of the amputation. My worry is that, when it comes to evaluating technology for building on the web, we aren’t considering the longer-term costs.

Maintenance matters. With the passing of time, maintenance matters more and more.

Maybe we avoid thinking about the long-term costs because it would lead to decision paralysis. That’s understandable. But I take comfort from some words of wisdom on the web from the 1990s. Tim Berners-Lee’s style guide for hypertext:

Because hypertext is potentially unconstrained you are a little daunted. Do not be. You can write a document as simply as you like. In many ways, the simpler the better.

I had a lot of fun making the website for Patterns Day.

If you’re interested in the tech stack, here’s what I used:

1. HTML
2. CSS

Actually, technically it’s all HTML because the styles are inside a style element rather than a separate style sheet, but you know what I mean. Also, there is technically some JavaScript but all it does is register a service worker that takes care of caching and going offline.

I didn’t use any build tools. There was no pipeline. There is no node_modules folder filling up my hard drive. Nothing was automated. The website was hand-crafted the long hard stupid way.

I started with the content. I wrote out the words and marked them up with the most appropriate HTML elements.

Time to layer on the presentation.

For the design, I turned to Michelle for help. I gave her a brief, describing the vibe of the conference, and asked her to come up with an appropriate visual language.

Crucially, I asked her not to design a website. Instead I asked her to think about other places where this design language might be used: a poster, social media, anything but a website.

Partly I was doing this for my own benefit. If you give me a pixel-perfect design for a web page and tell me to code it up, either I won’t do it or I won’t enjoy it. I just don’t get any motivation out of that kind of direct one-to-one translation.

But give me guardrails, give me constraints, give me boundary conditions, and off I go!

Michelle was very gracious in dealing with such a finicky client as myself (“Can you try this other direction?”, “Hmm… I think I preferred the first one after all!”) She delivered a colour palette, a type scale, typeface choices, and some wonderful tiling patterns …it is Patterns Day after all!

With just a few extra lines of CSS, the basic typography was in place.

I started layering on the colours. Even though this was a one-page site, I still made liberal use of custom properties in the CSS. It just feels good to be able to update one value and see the results, well …cascade.

I had a lot of fun with the tiling background images. SVG was the perfect format for these. And because the tiles were so small in file size, I just inlined them straight into the CSS.

By this point, I felt like I was truly designing in the browser. Adjusting spacing, playing around with layout, and all that squishy stuff. Some of the best results came from happy accidents—the way that certain elements behaved at certain screen sizes would lead me into little experiments that yielded interesting results.

I’m not sure it’s possible to engineer that kind of serendipity in Figma. Figma was the perfect tool for exploring ideas around the visual vocabulary, and for handing over design decisions around colour, typography, and texture. But when it comes to how the content is going to behave on the World Wide Web, nothing beats a browser for fidelity.

By this point I was really sweating the details, like getting the logo just right and adjusting the type scale for different screen sizes. Needless to say, Utopia was a godsend for that.

I was also checking back in with Michelle to get her take on design decisions I was making.

I could’ve kept tinkering but the diminishing returns were a sign that it was time to put this out into the world.

It felt really good to work on a web page like this. It felt like I was getting my hands into the soil of the web. I don’t think it’s an accident that the result turned out to be very performant.

Getting hands-on like this stops me from getting rusty. And honestly, working with CSS these days is a joy. There’s such power to be had from using var() in combination with functions like calc() and clamp(). Layout is a breeze with flexbox and grid. Browser differences are practically non-existent. We’ve never had it so good.

Here’s something I noticed about my relationship to CSS; my brain has finally made the switch to logical properties. Now if I’m looking at some CSS and I see left, right, top, or bottom, it looks like a bug to me. Those directional properties feel loaded with assumptions whereas logical properties feel much more like working with the grain of the web.

Mark your calendar: Thursday, March 7th, 2024. That’s when Patterns Day will return for its third edition.

Patterns Day is a one-day event focused on design systems. It’s for designers, developers, project managers, writers, and anyone else who’s working with design systems, pattern libraries, style guides, and components. Tickets are on sale now!

Once again, Patterns Day will be in the magnificent Duke of York’s cinema in Brighton, with its historic charm and dangerously comfortable seats.

The first Patterns Day was all the way back in 2017. Then we had the second Patterns Day in 2019. You can watch videos of the talks from both years.

We all know what happened after 2019. Nothing like a global pandemic to stop an event in its tracks.

Now, finally, Patterns Day is returning in 2024.

After all this time, is there still a need for an event focused on design systems?

In my opinion, the answer is “more than ever!”

When Clearleft first ran Patterns Day, we had been doing design systems work for a while, but other organisations were only at the start of their journey. Many of the attendees were from companies that were dabbling in design systems, or planned to put a design system together.

That situation has changed. Now most organisations either have at least some experience with design systems. Many companies have got design systems up and running.

But the challenges haven’t gone away. They’ve just changed. You might no longer need to convince anyone that a design system is a good idea, but you might well be struggling to convince people to use the design system you’ve got.

It can be lonely work. That’s why Patterns Day is so vital. It’s a chance to get together with other people going through the same struggles. You’ll have an opportunity to learn from their successes and failures. Most of all, you’ll have the reassurance that you are not alone.

I know that makes it sound more like therapy than a conference, but honestly, that’s where the true value lies.

We’ve already got some fantastic speakers lined up, but there are just as many still to come!

Can you tell that I’m very excited about this?

It would be lovely to see there. Tickets will cost £255, but you can secure your place now at the super early bird price of just £195. Dither ye not!

Can’t wait to see you in Brighton on March 7th—it’s going to be a day to remember!

Web Summer Camp in Croatia finished with an interesting discussion. It was labelled a town-hall meeting, but it was more like an Oxford debating club.

Two speakers had two minutes each to speak for or against a particular statement. Their stances were assigned to them so they didn’t necessarily believe what they said.

One of the propositions was something like:

In the future, sustainable design will be as important as UX or performance.

That’s a tough one to argue against! But that’s what Sophia had to do.

She actually made a fairly compelling argument. She said that real impact isn’t going to come from individual websites changing their colour schemes. Real impact is going to come from making server farms run on renewable energy. She advocated for political action to change the system rather than having the responsibility heaped on the shoulders of the individuals making websites.

It’s a fair point. Much like the concept of a personal carbon footprint started life at BP to distract from corporate responsibility, perhaps we’re going to end up navel-gazing into our individual websites when we should be collectively lobbying for real change.

It’s akin to clicktivism—thinking you’re taking action by sharing something on social media, when real action requires hassling your political representative.

I’ve definitely seen some examples of performative sustainability on websites.

For example, at the start of this particular debate at Web Summer Camp we were shown a screenshot of a municipal website that has a toggle. The toggle supposedly enables a low-carbon mode. High resolution images are removed and for some reason the colour scheme goes grayscale. But even if those measures genuinely reduced energy consumption, it’s a bit late to enact them only after the toggle has been activated. Those hi-res images have already been downloaded by then.

Defaults matter. To be truly effective, the toggle needs to work the other way. Start in low-carbon mode, and only download the hi-res images when someone specifically requests them. (Hopefully browsers will implement prefers-reduced-data soon so that we can have our sustainable cake and eat it.)

Likewise I’ve seen statistics bandied about around the energy-savings that could be made if we used dark colour schemes. I’m sure the statistics are correct, but I’d like to see them presented side-by-side with, say, the energy impact of Google Tag Manager or React or any other wasteful dependencies that impact performance invisibly.

That’s the crux. Most of the important work around energy usage on websites is invisible. It’s the work done to not add more images, more JavaScript or more web fonts.

And it’s not just performance. I feel like the more important the work, the more likely it is to be invisible: privacy, security, accessibility …those matter enormously but you can’t see when a website is secure, or accessible, or not tracking you.

I suspect this is why those areas are all frustratingly under-resourced. Why pour time and effort into something you can’t point at?

Now that I think about it, this could explain the rise of web accessibility overlays. If you do the real work of actually making a website accessible, your work will be invisible. But if you slap an overlay on your website, it looks like you’re making a statement about how much you care about accessibility (even though the overlay is total shit and does more harm than good).

I suspect there might be a similar mindset at work when it comes to interface toggles for low-carbon mode. It might make you feel good. It might make you look good. But it’s a poor substitute for making your website carbon-neutral by default.