I really enjoyed this chat with Marc:
I recently sat down with Jeremy Keith for a spontaneous conversation that quickly turned into a deep dive into something we both care a lot about: events, community, and why we keep putting ourselves through the joy and pain of running conferences.
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
How often do we, as frontend engineers, overlook the URL as a state management tool? We reach for all sorts of abstractions to manage state such as global stores, contexts, and caches while ignoring one of the web’s most elegant and oldest features: the humble URL.
UX London will be back in 2026. It’s on June 2nd, 3rd, and 4th:
Each day features a morning packed with inspiring talks followed by an afternoon of practical hands-on workshops. It’s the perfect blend!
As with last year, each day will be themed:
You can come for a single day, but for best value, you should come for all three days.
I’m starting to put the line-up together now—hoping to match the excellence of last year’s event—and I’ll start announcing speakers early in the new year.
But if you trust me, then I highly recommend getting a super-early bird ticket now. They’ll only be available for another couple of weeks. You get a significant discount if you buy now.
Oh, and while I’m in the process of putting the line-up together, you should know that you can submit a talk or workshop proposal:
We always pay ALL our speakers for their time as well as covering the cost of accommodation and economy travel.
Don’t be shy! Pitch early, pitch often.
(That said, I wouldn’t recommend pitching a talk that focuses on “AI”. It’s not just that the bubble will probably have burst by the time UX London rolls around, it’s also that UX London doesn’t tend to focus on tools, whether they’re graphic design tools like Figma or generative tools like whatever people are using to turbo-charge their output of slop. If you’ve got a case study you want to talk about that happened to use some “AI” tool, great! But don’t make that the focus of the talk. Tell me about the problem and the solution.)
England is criss-crossed by routes that were originally laid down by the Romans. When it came time to construct modern roads, it often made sense to use these existing routes rather than trying to designate entirely new ones. So some of the roads in England are like an early kind of desire path.
Desire paths are something of a cliché in the UX world. They’re the perfect metaphor for user-centred design; instead of trying to make people take a pre-defined route, let them take the route that’s easiest for them and then codify that route.
This idea was enshrined into the very design principles of HTML as “pave the cowpaths”:
When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
Ireland never had any Roman roads. But it’s always had plenty of cowpaths.
The Irish word for cow is bó.
The Irish word for road is bóthar, which literally means “cowpath”.
The cowpaths were paved in both the landscape and the language.
When I was talking about monitoring web performance yesterday, I linked to the CrUX data for The Session.
CrUX is a contraction of Chrome User Experience Report. CrUX just sounds better than CEAR.
It’s data gathered from actual Chrome users worldwide. It can be handy as part of a balanced performance-monitoring diet, but it’s always worth remembering that it only shows a subset of your users; those on Chrome.
The actual CrUX data is imprisoned in some hellish Google interface so some kindly people have put more humane interfaces on it. I like Calibre’s CrUX tool as well as Treo’s.
What’s nice is that you can look at the numbers for any reasonably popular website, not just your own. Lest I get too smug about the performance metrics for The Session, I can compare them to the numbers for WikiPedia or the BBC. Both of those sites are made by people who prioritise speed, and it shows.
If you scroll down to the numbers on navigation types, you’ll see something interesting. Across the board, whether it’s The Session, Wikipedia, or the BBC, the BFcache—back/forward cache—is used around 16% to 17% of the time. This is when users use the back button (or forward button).
Unless you do something to stop them, browsers will make sure that those navigations are super speedy. You might inadvertently be sabotaging the BFcache if you’re sending a Cache-Control: no-store header or if you’re using an unload event handler in JavaScript.
I guess it’s unsurprising the BFcache numbers are relatively consistent across three different websites. People are people, whatever website they’re browsing.
Where it gets interesting is in the differences. Take a look at pre-rendering. It’s 4% for the BBC and just 0.4% for Wikipedia. But on The Session it’s a whopping 35%!
That’s because I’m using speculation rules. They’re quite straightforward to implement and they pair beautifully with full-page view transitions for a slick, speedy user experience.
It doesn’t look like WikiPedia or the BBC are using speculation rules at all, which kind of surprises me.
Then again, because they’re a hidden technology I can understand why they’d slip through the cracks.
On any web project, I think it’s worth having a checklist of The Invisibles—things that aren’t displayed directly in the browser, but that can make a big difference to the user experience.
Some examples:
meta elements in the head of documents so they “unroll” nicely when the link is shared.Speculation-Rules header that points to a JSON file.lang attribute on the body of every page.If you’ve got a checklist like that in place, you can at least ask “Whose job is this?” All too often, these things are missing because there’s no clarity on whose responsible for them. They’re sorta back-end and sorta front-end.
There was a time when you needed to make a native app in order to take advantage of specific technologies. That time has passed.
Now you can do all of these things on the web:
Take a look at the home screen on your phone. Looking at the apps you’ve downloaded from an app store, ask yourself how many of them could’ve been web apps.
Social media apps, airline apps, shopping apps …none of them are using technologies that aren’t widely available on the web.
“But”, you might be thinking, “it feels different having a nice icon on my homescreen that launches a standalone app compared to navigating to a bookmark in my web browser.”
I agree! And you can do that with a web app. All it takes the addition of one manifest file that lists which icons and colours to use.
If that file exists for a website, then once the user adds the website to their homescreen it will behave just like native app.
Try it for yourself. Go to instagram.com in your mobile browser and it to your homescreen (on the iPhone, you get to the “add to home screen” option from the sharing icon—scroll down the list of options to find it).
See how it’s now an icon on your home screen just like all your other apps? Tap that icon to see how it launches just like a native app with no browser chrome around it.
This doesn’t just work on mobile. Desktop browsers like Chrome, Edge, and Safari also allow you to install web apps straight from the browser and into your dock.
About half of the icons in my dock are actually web apps and I honestly can’t tell which is which. Mastodon, Instagram, Google Calendar, Google Docs …I’m sure most of those services are available as downloadable desktop apps, but why would I bother doing that when I get exactly the same experience by adding the sites to my dock?
From a business perspective, it makes so much sense to build a web app (or simply turn your existing website into a web app with the addition of a manifest file). No need for separate iOS or Android developer teams. No need to play the waiting game with updates to your app in the app store—on the web, updates are instant.
You can even use an impressive-sounding marketing term for this approach: progressive web apps:
A Progressive Web App (PWA) is a web app that uses progressive enhancement to provide users with a more reliable experience, uses new capabilities to provide a more integrated experience, and can be installed. And, because it’s a web app, it can reach anyone, anywhere, on any device, all with a single codebase. Once installed, a PWA looks like any other app, specifically:
- It has an icon on the home screen, app launcher, launchpad, or start menu.
- It appears when you search for apps on the device.
- It opens in a standalone window, wholly separated from a browser’s user interface.
- It has access to higher levels of integration with the OS, for example, URL handling or title bar customization.
- It works offline.
But there’s still one thing that native apps do better than the web. If you want to be able to monitor and track users to an invasive degree, the web can’t compete with the capabilities of native apps. That’s why you’ll see so many websites on your mobile device that implore to install their app from the app store.
If that’s not a priority for you, then you can differentiate yourself from your competitors by offering your users a progressive web app. Instead of having links to Apple and Google’s app stores, you can link to a page on your own site with installation instructions.
I can guarantee you that users won’t be able to tell the difference between a native app they installed from an app store and a web app they’ve added to their home screen.
Sunday afternoon session in Belfast
A bunch of the UX London speakers have been saying very nice things about the event over on LinkedIn. I’m going to quote a few of them for my future self to look at when I’m freaking out about curating the next event…
Still buzzing … UX London smashed all expectations!
Huge shoutout to Jeremy Keith and the entire Clearleft team for their tireless efforts in making this event truly special. Three days packed with inspiration, insights, and true gems – I left feeling inspired, grateful, and already looking forward to next year’s event!
Huge thanks to my fellow speakers for the inspiring talks, and to the team at Clearleft (Jeremy Keith, Louise Ash, and so many more!) for putting together such a brilliant event.
I’ve loved learning and sharing this week! Feeling super inspired and looking forward to building new friendships!
Last week in UX London I got to witness event planning mastery, I was in awe. Things ran smoothly and people were united under a premise: to share knowledge and build community.
This doesn’t happen by chance, it’s the mastery that pros like Jeremy and Louise bring to the table.
Bold, thought-provoking talks. Hands-on workshops that challenged and stretched thinking. And a real sense of community that reminded me why spaces like this matter so much.
The conference was packed with inspiration, thoughtful conversations, and a strong focus on accessibility and inclusivity. Thank you Luke Hay, Jeremy Keith, Louise Ash, and the whole Clearleft team for creating such a welcoming and inspiring space!
Jeremy Keith, Richard Rutter, Louise Ash, Chris How, Sophie Count, Luke Hay and the rest of Clearleft, take a bow! Hands down one of the best conference experiences I’ve had!
The curation was excellent, the talks complimented each other so well, it was almost like we’d all met up and rehearsed it beforehand!
A huge thank you to Jeremy Keith, Louise Ash and the Clearleft team for the opportunity and the brilliant conference you’ve put together.
It’s been inspiring to experience every moment of it.
Shoutout to the organisers for curating such a rich experience—3 themed days focused on Discovery, Design, and Delivery.
We remember through stories. And this event was full of them. Already looking forward to next year.
And I’m just going to quote Rachel Rosenson’s post in its entirety:
Spoke at UXLondon last week—and while the talks were great, it was something off-stage that really stuck with me.
After the Day 1 talks wrapped, a bunch of us speakers grabbed a drink, and someone pointed out: Every single speaker that day—every one—was a woman. 5 talks. 4 workshops. All women.
And it wasn’t a “Women in Tech” day. It was just… the conference.
No one made a fuss. No banners. No “look at us go!”
Just incredible women, giving incredible talks, like it was the most normal thing in the world. (Spoiler: it should be.)
Jeremy Keith mentioned how frustrating it is that all-male line-ups are still so common—and how important it is to actively design for inclusion. Major props to Jeremy and the Clearleft team for curating a line-up that was intentional without performativity.
It was refreshing. No tokenism. No checkbox energy. Just great voices on great stages. And a big honor to be one of them.
UX London happened last week.
Working on an event is a weird kind of project. You spend all your time and effort on something that is then over in the blink of an eye.
I’d been preparing for this all year. 95% of my work happened before the event—curating the line-up, planning each day. There wasn’t all that much for me to do at the event itself other than introduce the speakers and chat with the attendees.
Maybe it was because there was very little left in my control, but the night before the event I found myself feeling really anxious and nervous. I was pretty sure the line-up was excellent, but anything could happen. I really wanted everyone to have a great time, but at that point, there wasn’t much more I could do.
Then the first day started. Every talk was superb. Everyone got really stuck into their workshops. By the end of the day, people were buzzing about what a great time they’d had.
My nervousness was easing. But that was only one day of three.
The second day was just as good. Again, every talk was superb. I began to suspect that the first day wasn’t just a fluke.
The third day confirmed it. Three days of top-notch talks—nary a dud in the whole line-up!
It was, dare I say it, the best UX London yet. Not just because of the talks and workshops. The attendees were absolutely lovely! There was a really good buzz throughout.
By the end of the event I felt a huge sense of relief.
For this year’s UX London, I put a lot of time and effort into curating the line-up. There were some safe bets. There were some risky bets. They all paid off.
I’m incredibly grateful to all of the fantastic speakers and workshop hosts who really gave it their all. And I’m so, so grateful to everyone who came. It’s a tough time for events right now, and I really appreciate every single person who made it to this year’s UX London. Thank you!
The only downside to pouring my heart and soul into this year’s line-up is that I left nothing in the tank for next year. I’m already starting to worry—how am I going to top UX London 2025?
Why single-page apps are just not worth it:
Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.
Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.
Today is Global Accessibility Awareness Day:
The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.
Awareness is good. It’s necessary. But it’s not sufficient.
Accessibility, like sustainability and equality, is the kind of thing that most businesses will put at the end of sentences that begin “We are committed to…”
It’s what happens next that matters. How does that declared commitment—that awareness—turn into action?
In the worst-case scenario, an organisation might reach for an accessibility overlay. Who can blame them? They care about accessibility. They want to do something. This is something.
Good intentions alone can result in an inaccessible website. That’s why I think there’s another level of awareness that’s equally important. Designers and developers need to be aware of what they can actually do in service of accessibility.
Fortunately that’s not an onerous expectation. It doesn’t take long to grasp the importance of having good colour contrast or using the right HTML elements.
An awareness of HTML is like a superpower when it comes to accessibility. Like I wrote in the foreword to the Web Accessibility Cookbook by O’Reilly:
It’s supposed to be an accessibility cookbook but it’s also one of the best HTML tutorials you’ll ever find. Come for the accessibility recipe; stay for the deep understanding of markup.
The challenge is that HTML is hidden. Like Cassie said in the accessibility episode of The Clearleft Podcast:
You get JavaScript errors if you do that wrong and you can see if your CSS is broken, but you don’t really have that with accessibility. It’s not as obvious when you’ve got something wrong.
We are biased towards what we can see—hierarchy, layout, imagery, widgets. Those are the outputs. When it comes to accessibility, what matters is how those outputs are generated. Is that button actually a button element or is it a div? Is that heading actually an h1 or is it another div?
This isn’t about the semantics of HTML. This is about the UX of HTML:
Instead of explaining the meaning of a certain element, I show them what it does.
That’s the kind of awareness I’m talking about.
One way of gaining this awareness is to get a feel for using a screen reader.
The name is a bit of a misnomer. Reading the text on screen is the least important thing that the software does. The really important thing that a screen reader does is convey the structure of what’s on screen.
Friend of Clearleft, Jamie Knight very generously spent an hour of his time this week showing everyone the basics of using VoiceOver on a Mac (there’s a great short video by Ethan that also covers this).
Using the rotor, everyone was able to explore what’s under the hood of a web page; all the headings, the text of all the links, the different regions of the page.
That’s not going to turn anyone into an accessibility expert overnight, but it gave everyone an awareness of how much the HTML matters.
Mind you, accessibility is a much bigger field than just screen readers.
Fred recently hosted a terrific panel called Is neurodiversity the next frontier of accessibility in UX design?—well worth a watch!
One of those panelists—Craig Abbott—is speaking on day two of UX London next month. His talk has the magnificent title, Accessibility is a design problem:
I spend a bit of time covering some misconceptions about accessibility, who is responsible for it, and why it’s important that we design for it up front. It also includes real-world examples where design has impacted accessibility, before moving onto lots of practical guidance on what to be aware of and how to design for many different accessibility issues.
Get yourself a ticket and get ready for some practical accessibility awareness.
It’s just over one month until UX London. You should grab a ticket if you haven’t already!
The format of UX London is quite special. While the focus of each day is different—discovery, design, and delivery—each day unfolds like this…
There are four talks in the morning. You get your brain filled with ideas and learn from fantastic speakers. It’s a single track—everyone’s getting the same shared experience.
Then after a lunch, you choose from one of four workshops. Whatever you choose, it’s going to be hands-on. You can leave your laptop at home.
A day of listening to talks could get exhausting. A workshop that lasts all day could be even more exhausting. But somehow by splitting the day between both activities, the energy level is just right!
That said, we don’t want the day to end with everyone spread across four different workshop rooms. That’s why there’s one final talk at the end of each day.
These closing talks are a bit different to the morning talks. Whereas the focus of the morning talks is on practical skills that you can apply straight away, the closing talks are an opportunity to sit back and have your mind expanded. They’ll be fun and thought-provoking.
Paula Zuccotti is closing out day one with a talk about two of her projects: Every Thing We Touch and Future Archeology:
This talk invites audiences to reconsider the meaning of the objects they encounter every day and reflect on what their possessions might reveal about who we are and what we value, both now and in the years to come.
Sarah Hyndman will wrap up day two with a fun interactive talk about your senses:
Join a live expedition into our inner world to explore why we see, feel and remember.
Finally, Rachel Coldicutt is going to finish UX London with a rallying cry:
Introducing the Society of Hopeful Technologists and discussing how, in modern technology development, your practice is probably more political than you realise.
I can’t wait! Get yourself a ticket for a day or for all three days.
And as a little thank you for tolerating my excitement, use the discount code JOINJEREMY to get 20% off your ticket.
In exactly six weeks time, UX London is happening!
I am ridiculously excited about this year’s line-up—I can’t wait to see the talks and get hands-on in the workshops.
If you haven’t yet got your ticket, now is the time. There’s a flash sale this week: use the discount code FLASH20 to get a whopping 20% of any ticket. Do it before the end of Friday!
Whether you’re coming for all three days or choosing one focused day, you’re in for a treat.
Head on over to the website to get all the details and then get your discounted ticket.
See you there!
Overall, consistency, user control, and actual UX innovation are in decline. Everything is converging on TikTok—which is basically TV with infinite channels. You don’t control anything except the channel switch. It’s like Carcinisation, a form of convergent evolution where unrelated crustaceans all evolve into something vaguely crab-shaped.
Kicking off St. Patrick’s weekend with a spice bag and Murphy’s!
I’ve been introduced to the most important staff member at this university.
I’ve had my head down for the past six months putting the line-up for UX London together. Following the classic design cliché, the process was first divergent, then convergent.
I spent months casting the net wide, gathering as many possible candidates as I could, as well as accepting talk proposals (of which there were lots). It was fun—this is when the possibility space is wide open.
Then it was crunch time and I had to start zeroing in on the final line-up. It wasn’t easy. There were so many times I agonised over who’d be the right person to deliver the right talk.
But as the line-up came together, I started getting very excited. And now when I step back and look at the line-up, I’m positively vibrating with excitement—roll on June!
I think it was really useful to have a mix of speakers that I reached out to, as well as talk proposals. If I was only relying on my own knowledge and networks, I’m sure I’d miss a lot. But equally, if I was only relying on talk proposals, it would be like searching for my keys under the streetlight.
Putting the line-up on the website wasn’t quite the end of the work. We got over 100 proposals for UX London this year. I made sure to send an email back to each and every one of them once the line-up was complete. And if anyone asked for more details as to why their proposal didn’t make it through, I was happy to provide that feedback.
After they went to the trouble of submitting a proposal, it was the least I could do.
Oh, and don’t forget: early-bird tickets for UX London are only available until Friday. Now’s the time to get yours!
Check it out—here’s the line-up for UX London 2025!
This is going to be so good! Grab a ticket if you haven’t got one yet.
UX London takes place over three days, from June 10th to 12th at a fantastic venue in the heart of the city. To get the full experience, you should come for all three days. But you can also get a ticket for individual days. Each day has a focus, and when you put them all together, the whole event mirrors the design process:
Each day features a morning of talks, followed by an afternoon of workshops. The talks are on a single track; four consecutive half-hour presentations to get you inspired. Then after lunch, you choose from one of four workshops. All the workshops are two and half hours long and very hands-on. No laptop required.
On discovery day you’ll have talks in the morning about research, content design, strategy and evaluating technology, followed by workshops on discovery and definition and behavioural design.
On design day there’ll be talks on interface design, a healthcare case study, inclusive design, and typography, followed by workshops in the afternoon on data visualisation and ethics.
Finally on delivery day you’ll get talks on conversion design, cross-team collaboration, convincing stakeholders, and improving design critiques, followed by workshops on facilitating workshops and getting better at public speaking.
Every workshop is repeated on another day so you’ll definitely get the chance to attend the one you want.
Oh, and at the end of every day there’ll be a closing keynote. Those are yet to be revealed, but I can guarantee they’re going to be top-notch!
Right now you can get early-bird tickets for all three days, or individual days. That changes from March 15th, when the regular pricing kicks in—a three-day ticket will cost £200 more. So I’d advise you to get your ticket now.
If you need to convince your boss, show them this list of reasons to attend.
See you there!
Rich suggests another reason why the UX of websites on mobile is so shit these days:
The path to installing a native app is well trodden. We search the App Store (or ironically follow a link from a website), hit ‘Get’ and the app is downloaded to our phone’s home screen, ready to use any time with a simple tap.
A PWA can also live on your home screen, nicely indistinguishable from a native app. But the journey to getting a PWA – or indeed any web app – onto your home screen remains convoluted to say the least. This is the lack of equivalence I’m driving at. I wonder if the mobile web experience would suck as badly if web apps could be installed just as easily as native apps?