Journal

Support for view transitions for regular websites (as opposed to single-page apps) will ship in Chrome 126. As someone who’s a big fan—to put it mildly—I am very happy about this!

Hopefully Firefox and Safari won’t be too far behind. But it’s still worth adding view transitions to your website even if not every browser supports them. They’re the perfect example of a progressive enhancement.

The browsers that don’t yet support view transitions won’t be harmed in any way if you give them the CSS for view transitions. They’ll just ignore it. For users of those browsers, nothing changes.

Then when those browsers do ship support for view transitions, your website automatically gets an upgrade for those users. Code you’ve already written starts working from one day to the next.

Don’t wait, is what I’m saying.

I really like the Baseline initiative as a way to track browser support. It’s great to see it in use on MDN and Can I Use. It’s very handy having a glanceable indication of which browser features are newly available and which are widely available.

But…

Not all browser features work the same way. For features that work as progressive enhancements you don’t need to wait for them to be widely available.

Service workers. Preference queries. View transitions.

If a browser doesn’t support one of those features, that’s fine. Your website won’t break in that browser.

Now that’s not true of all browser features, particularly some JavaScript APIs. If a feature is critical for your site to function then you definitely want to wait until it’s widely supported.

Baseline won’t tell you the difference between those two different kinds of features.

I don’t want Baseline to get too complicated. Like I said, I really like how it’s nice and glanceable right now. But it would be nice if there way some indication that a newly-available feature is a progressive enhancement.

For now it’s up to us to make that distinction. So don’t fall into the trap of thinking that just because a feature isn’t listed as widely-available you can’t use it yet.

Really you want to ask two questions:

1. How widely available is this feature?
2. Can this feature be used as a progressive enhancement?

If Baseline tells you that the answer to the first question is “newly-available”, move on to the second question. If the answer to that is “no, it can’t be used as a progressive enhancement”, don’t ship that feature in production just yet.

But if the answer to that second question is “hell yeah, it’s a progressive enhancement!” then go for it, regardless of the answer to the first question.

Y’know, there’s a real irony in a common misunderstanding around progressive enhancement: some people seem to think it’s about not being able to use advanced browser features. In reality it’s the opposite. Progressive enhancement allows you to use advanced browser features even before they’re widely supported.

My colleague Chris has written a terrific post over on the Clearleft blog: Is the planet the missing member of your project team?

Rather than hand-wringing and finger-wagging, it gets down to some practical steps that you—we—can take on every project.

Chris finishes by asking:

Let me know how you design with the environment in mind. What practical advice would you suggest?

Well, here’s something that I keep coming up against…

Chris shows that the environment can be part of project management, specifically the RACI methodology:

We list who is responsible, accountable, consulted, and informed within the project. It’s a simple exercise but the clarity is useful for identifying what expertise and input we should seek from the named individuals.

Having the planet be a proactive partner in your project ensures its needs are considered.

Whenever responsibilities are being assigned there are some things that inevitably fall through the cracks. One I’ve seen over and over again is responsibility for third-party scripts.

On the face of it this seems like another responsibility for developers. We’re talking about code here, right?

But in my experience it is never the developers adding “beacons” and other third-party embedded scripts.

Chris rightly points out:

Development decisions, visual design choices, content approach, and product strategy all contribute to the environmental impact of your website.

But what about sales and marketing? Often they’re the ones who’ll drop in a third-party script to track user journeys. That’s understandable. That’s kind of their job.

Dropping in one line of JavaScript seems like a victimless crime. It’s just one small script, right? But JavaScript can import more JavaScript. Tools like Request Map Generator can show just how much destruction third-party JavaScript can wreak:

You pop in a URL, it fetches the page and maps out all the subsequent requests in a nifty interactive diagram of circles, showing how many requests third-party scripts are themselves generating. I’ve found it to be a very effective way of showing the impact of third-party scripts to people who aren’t interested in looking at waterfall diagrams.

Just to be clear, the people adding third-party scripts to websites usually aren’t doing so maliciously. They often don’t realise the negative effect the scripts will have on performance and the environment.

As is so often the case, this isn’t a technical problem. At root it’s about understanding people’s needs (like “I need a way to see what pages are converting!”) and finding a way to meet those needs without negatively impacting the planet. A good open-minded discussion can go a long way.

So I echo Chris’s call to think about environmental impacts from the very start of a project. Establish early on who will have the ability to add third-party scripts to the site. Do all of those people understand the responsibility that gives them?

I saw this lack of foresight in action on a project recently. The front-end development was going really well and the site was going to be exceptionally performant: green Lighthouse scores across the board. But when the site went live it had tracking scripts. That meant that users needed to consent to being tracked. That meant adding another third-party script to generate a consent banner. It completely tanked the Lighthouse scores.

I’m sure the people who added the tracking scripts and consent banners thought they had no choice. But there are alternatives. There are ways to get the data you need without the intrusive surveillance and performance-wrecking JavaScript.

The problem is that it’s not the norm. “Everyone else is doing it” was the justification for Flash intros two decades ago and it’s the justification for enshittification via third-party scripts now.

It doesn’t have to be this way.

I haven’t had this much FOMO since the total solar eclipse across North America last month. Beyond Tellerrand is happening right now in Düsseldorf. Marc always puts on an excellent event.

I can take great comfort in knowing that it’s not too long until an equally excellent event: UX London is happening next month! Three days of design excellence. And if you still haven’t got your ticket, now’s the time to snap one up. There’s a flash sale happening this week. Use the code FLASH20 to get 20% off any ticket. It’s going to be great!

Still, I wish I could’ve made it to Düsseldorf for Beyond Tellerrand.

Ironically, I’ve been in Germany for the past few days. I was down in my old stomping ground of Freiburg in the heart of the Black Forest.

It was kind of like travelling back in time for Jessica and me. We were there to celebrate with our dear friends Birgit and Schorsch who were celebrating 30 years of getting together. When Jessica and I ran the numbers we realised that it was also 30 years since we got together.

It was kind of weird though. There were people there I literally handn’t seen in three decades. On more than one occasion I’d be looking blankly at someone and they’d be looking blankly back at me until someone said our names and we’d both experience instantaneous recognition and time dilation.

But a good time was had by all. There was a party with live bands, beer, and currywurst. Best of all though, people stuck around for a few days to just hang out and experience the delights of the Schwarzwald together. I’m not saying I can’t still party on …but I very much enjoyed the trip up into the hills the next day, and the leisurely wine-tasting in a nearby village the day after that.

And boy, did we eat well. Plenty of pretzels, sausages, and Black Forest cake of course, but Freiburg also has a fantastic market every single morning with the most amazing produce from the local region. Right now it’s the time for strawberries, aspargus, and bountiful lettuces.

Jessica and I finished the trip with a break from all the socialising. While everyone else was watching the Eurovision Song Contest we slipped away for a splendid meal at Restaurant Jacobi. It was the perfect way to wrap up a wonderful few days.

I mentioned that I overhauled the JavaScript on The Session recently. That wasn’t just so that I could mess about with HTML web components. I’d been meaning to consolidate some scripts for a while.

Some of the pages on the site had inline scripts. These were usually one-off bits of functionality. But their presence meant that my content security policy wasn’t as tight as it could’ve been.

Being a community website, The Session accepts input from its users. Literally. I do everything I can to sanitise that input. It would be ideal if I could make sure that any JavaScript that slipped by wouldn’t execute. But as long as I had my own inline scripts, my content security policy had to allow them to be executed with script-src: unsafe-inline.

That’s why I wanted to refactor the JavaScript on my site and move everything to external JavaScript files.

In the end I got close, but there are still one or two pages with internal scripts. But that’s okay. I found a way to have my content security policy cake and eat it.

In my content security policy header I can specifiy that inline scripts are allowed, but only if they have a one-time token specified.

This one-time token is called a nonce. No, really. Stop sniggering. Naming things is hard. And occassionally unintentionally hilarious.

On the server, every time a page is requested it gets sent back with a header like this:

content-security-policy: script-src 'self' 'nonce-Cbb4kxOXIChJ45yXBeaq/w=='

That gobbledegook string is generated randomly every time. I’m using PHP to do this:

base64_encode(openssl_random_pseudo_bytes(16))

Then in the HTML I use the same string in any inline scripts on the page:

<script nonce="Cbb4kxOXIChJ45yXBeaq/w==">
…
</script>

Yes, HTML officially has an attribute called nonce.

It’s working a treat. The security headers for The Session are looking good. I have some more stuff in my content security policy—check out the details if you’re interested.

I initially thought I’d have to make an exception for the custom offline page on The Session. After all, that’s only going to be accessed when there is no server involved so I wouldn’t be able to generate a one-time token. And I definitely needed an inline script on that page in order to generate a list of previously-visited pages stored in a cache.

But then I realised that everything would be okay. When the offline page is cached, its headers are cached too. So the one-time token in the content security policy header still matches the one-time token used in the page.

Most pages on The Session don’t have any inline scripts. For a while, every page had an inline script in the head of the document like this:

<script nonce="Cbb4kxOXIChJ45yXBeaq/w==">
document.documentElement.classList.add('hasJS');
</script>

This is something I’ve been doing for years: using JavaScript to add a class to the HTML. Then I can use the presence or absence of that class to show or hide elements that require JavaScript. I have another class called requiresJS that I put on any elements that need JavaScript to work (like buttons for copying to the clipboard, for example).

Then in my CSS I’d write:

:not(.hasJS) .requiresJS {
 display: none;
}

If the hasJS class isn’t set, hide any elements with the requiresJS class.

I decided to switch over to using a scripting media query:

@media (scripting: none) {
  .requiresJS {
   display: none;
  }
}

This isn’t bulletproof by any means. It doesn’t account for browser extensions that disable JavaScript and it won’t get executed at all in older browsers. But I’m okay with that. I’ve put the destructive action in the more modern CSS:

I feel that the more risky action (hiding content) should belong to the more complex selector.

This means that there are situations where elements that require JavaScript will be visible, even if JavaScript isn’t available. But I’d rather that than the other way around: if those elements were hidden from browsers that could execute JavaScript, that would be worse.

Gregory Bennett chronicles the enshittification of everything online in his piece Heat Death of the Internet. It makes for grim reading.

There’s a note of hope at the end. It’s the same note of hope that Charles Digges amplifies in his great piece, Viva la Library!:

Rebel against The Algorithm. Get a library card.

Molly White has also chronicled the decline of everything good on the web, but her piece has hope threaded throughout. We can have a different web:

Though we now face a new challenge as the dominance of the massive walled gardens has become overwhelming, we have tools in our arsenal: the memories of once was, and the creativity of far more people than ever before, who entered the digital expanse but have grown disillusioned with the business moguls controlling life within the walls.

And if anything, it is easier now to do all of this than it ever was.

Like I’ve repeatedly said, having your own website has gone being something uncontroversial to being downright transgressive.

Still, the barrier to entry remains too high for my liking. I wish more smart minds were working on making publishing on the web easier instead of just working on getting people to consume.

But even if you don’t have your own website, Andrew Stephens says you can still Save the Web by Being Nice:

The very best thing to keep the web partly alive is to maintain some content yourself - start a blog, join a forum and contribute to the conversation, even podcast if that is your thing. But that takes a lot of time and not everyone has the energy or the knowhow to create like this.

The second best thing to do is to show your support for pages you enjoy by being nice and making a slight effort.

To paraphrase Shakespeare, being nice “is twice blest; It blesseth him that gives and him that takes.” Tell someone that you liked something they put on the web. You’ll feel good. They’ll feel even better.

Alright, so last week I gave you the low-down on each day of this year’s UX London:

1. Tuesday, June 18th focuses on UX research,
2. Wednesday, June 19th focuses on product design, and
3. Thursday, June 20th focuses on design ops and design systems

But the line-up for each day wasn’t quite complete. There was a mystery slot at the end of each day for a closing keynote.

Well, I’m very happy to unveil the trio of fantastic speakers who will be closing out each day…

Rama Gheerawo is the closing speaker on day one. Rama will show you how to frame inclusive design in the context of UX.

I’ve been trying to get Rama for UX London for the past few years but the timings never worked out. I’m absolutely delighted that I’ve finally managed to nab him! His talk is guaranteed to be the perfect inspirational ending for day one.

Matt Webb is giving the closing keynote on day two. Matt will show what it’s like to live and work with AI. You know my scepticism on this topic but even I have to hand it to Matt; he’s finding ways to use these tools to create true delight.

Honestly it feels like a bit of a cheat getting Matt to wrap up the day—his talks are always incredibly entertaining so I feel like I’m taking the easy route. If you’ve seen his appearances at dConstruct you’ll know what I mean.

Maggie Appleton is the final speaker on the final day of UX London. Maggie will show you how to explore designing with large language models. Again, even a sceptic like me has a lot to learn from Maggie’s level-headed humanistic approach to AI.

I’m so happy to have Maggie speaking at UX London. Not only am I a huge fan of her website, but I also love her presentation style. She’s going to entertain and educate in equal measure, and she’s certain to leave us with some fascinating questions to ponder.

With that, the line-up for UX London 2024 is complete …and what a stellar line-up it is!

Grab your ticket if you haven’t already, either for the full full three days or if you can’t manage that, day tickets are available too.

Use this discount code to 20% of the ticket price: JOINJEREMY. I’d love to see you there!

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.

I’ve been deep-diving into HTML web components over the past few weeks. I decided to refactor the JavaScript on The Session to use custom elements wherever it made sense.

I really enjoyed doing this, even though the end result for users is exactly the same as before. This was one of those refactors that was for me, and also for future me. The front-end codebase looks a lot more understandable and therefore maintainable.

Most of the JavaScript on The Session is good ol’ DOM scripting. Listen for events; when an event happens, make some update to some element. It’s the kind of stuff we might have used jQuery for in the past.

Chris invoked Betteridge’s law of headlines recently by asking Will Web Components replace React and Vue? I agree with his assessment. The reactivity you get with full-on frameworks isn’t something that web components offer. But I do think web components can replace jQuery and other approaches to scripting the DOM.

I’ve written about my preferred way to do DOM scripting: element.target.closest. One of the advantages to that approach is that even if the DOM gets updated—perhaps via Ajax—the event listening will still work.

Well, this is exactly the kind of thing that custom elements take care of for you. The connectedCallback method gets fired whenever an instance of the custom element is added to the document, regardless of whether that’s in the initial page load or later in an Ajax update.

So my client-side scripting style has updated over time:

1. Adding event handlers directly to elements.
2. Adding event handlers to the document and using event.target.closest.
3. Wrapping elements in a web component that handles the event listening.

None of these progressions were particularly ground-breaking or allowed me to do anything I couldn’t do previously. But each progression improved the resilience and maintainability of my code.

Like Chris, I’m using web components to progressively enhance what’s already in the markup. In fact, looking at the code that Chris is sharing, I think we may be writing some very similar web components!

A few patterns have emerged for me…

Naming custom elements

Naming things is famously hard. Every time you make a new custom element you have to give it a name that includes a hyphen. I settled on the convention of using the first part of the name to echo the element being enhanced.

If I’m adding an enhancement to a button element, I’ll wrap it in a custom element that starts with button-. I’ve now got custom elements like button-geolocate, button-confirm, button-clipboard and so on.

Likewise if the custom element is enhancing a link, it will begin with a-. If it’s enhancing a form, it will begin with form-.

The name of the custom element tells me how it’s expected to be used. If I find myself wrapping a div with button-geolocate I shouldn’t be surprised when it doesn’t work.

Naming attributes

You can use any attributes you want on a web component. You made up the name of the custom element and you can make up the names of the attributes too.

I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.

So I use data- attributes. I’ve already got a hyphen in the name of my custom element, so it makes sense to have hyphens in my attributes too. And by using data- attributes, the browser gives me automatic reflection of the value in the dataset property.

Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.

The single responsibility principle

My favourite web components aren’t all-singing, all-dancing powerhouses. Rather they do one thing, often a very simple thing.

Here are some examples:

• Jason’s aria-collapsable for toggling the display of one element when you click on another.
• David’s play-button for adding a play button to an audio or video element.
• Chris’s ajax-form for sending a form via Ajax instead of a full page refresh.
• Jim’s user-avatar for adding a tooltip to an image.
• Zach’s table-saw for making tables responsive.

All of those are HTML web components in that they extend your existing markup rather than JavaScript web components that are used to replace HTML. All of those are also unambitious by design. They each do one thing and one thing only.

But what if my web component needs to do two things?

I make two web components.

The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.

What if you’ve got some text that you want to be a level-three heading and also a link? You don’t bemoan the lack of an element that does both things. You wrap an a element in an h3 element.

The same goes for custom elements. If I find myself adding multiple behaviours to a single custom element, I stop and ask myself if this should be multiple custom elements instead.

Take some of those button- elements I mentioned earlier. One of them copies text to the clipboard, button-clipboard. Another throws up a confirmation dialog to complete an action, button-confirm. Suppose I want users to confirm when they’re copying something to their clipboard (not a realistic example, I admit). I don’t have to create a new hybrid web component. Instead I wrap the button in the two existing custom elements.

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. And it has the added benefit of stopping my code getting too complex and hard to understand.

Communicating across components

Okay, so I’ve broken all of my behavioural enhancements down into single-responsibility web components. But what if one web component needs to have awareness of something that happens in another web component?

Here’s an example from The Session: the results page when you search for sessions in London.

There’s a map. That’s one web component. There’s a list of locations. That’s another web component. There are links for traversing backwards and forwards through the locations via Ajax. Those links are in web components too.

I want the map to update when the list of locations changes. Where should that logic live? How do I get the list of locations to communicate with the map?

Events!

When a list of locations is added to the document, it emits a custom event that bubbles all the way up. In fact, that’s all this component does.

You can call the event anything you want. It could be a newLocations event. That event is dispatched in the connectedCallback of the component.

Meanwhile in the map component, an event listener listens for any newLocations events on the document. When that event handler is triggered, the map updates.

The web component that lists locations has no idea that there’s a map on the same page. It doesn’t need to. It just needs to dispatch its event, no questions asked.

There’s nothing specific to web components here. Event-driven programming is a tried and tested approach. It’s just a little easier to do thanks to the connectedCallback method.

I’m documenting all this here as a snapshot of my current thinking on HTML web components when it comes to:

• naming custom elements,
• naming attributes,
• the single responsibility principle, and
• communicating across components.

I may well end up changing my approach again in the future. For now though, these ideas are serving me well.

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.