Reflections on UX Brighton 2026

I try to keep abreast of all the different worlds around making software as part of what I do. And I've felt away from the UX world, at least away from some Proper Designer People to keep me honest recently. It's never good if I'm the most knowledgeable person in a room about a topic (apart from British railway fares 😅).

This is not intended to be a run through of the day, the videos will be available for the public about 6 months afterwards so you can live through it that way via https://uxbri.org/2026/.

But I did write a few notes that day, and wanted to tie memories down. So here you go. Thank you to Danny Hope and many others for making this day what it was.

The UX field has properly absorbed the "Atlassian view" of the world.

A decade ago the rockstar designers were still fighting this. We had a talk about atomising and systematising UX debt to help make it trackable (from https://medium.com/@chiara.scara). Developers take note, this was "tech debt with receipts" which is something we should learn from! This used jira concepts extensively, and a different talk from Phil Morton which had this lovely little illustration of "figma island" in a "sea of handovers".

There is no longer questioning about how design teams should work with developers, unless it's packaged with AI. And even a talk of using software inspired processes to gain buy-in for design items.

What's gone? No mention of designer/developer pairing, or some of the more closely integrated types of collaboration. Looking ahead, people are picturing... designer and AI. or developer and AI. Not design and developer with some AI tooling working together.

I'm wondering if this is a byproduct of an industry trying to relearn who it is. But it felt like it lacked confidence so far. As much as the pro-collaboration world is so much better than the "arrogant designer" stereotype, the frequent references to jira felt a little like the attempt to collaborate had detoured instead into corporate-vibed, project manager friendly, rather than developer friendly. Atlassian's products are sort of a figurehead for this phenomenon.

I was also a little sad at the usage of the term "technical" to refer to people, which seems to have been absorbed from the worst parts of the developer world, although to Phil's credit above he's put it in quotes.

The primary focus seems to be how to consume AI to make design better, not how to design AI

One great little snippet I got from someone in the after party was that plugging an LLM into confluence meant that they didn't need to remember about when someone might have said something, or how they said it, or how they thought about it at the time - the semantic matching was done for you when searching, and you could ask it for links.

During the day, most of the focus and buzz right now seems to be "how to design with AI tools" not "how to design AI products". The first talk of the day, from Florian Herrengt, covered that we needed to do this, so I got excited, but we didn't go into how to design great products that use AI for their features in other talks, and asking about in the room during the breaks, very few people had had an opportunity to do this yet. GenAI was coming into their work via tooling, not via AI-type features they need to design.

Back to the future, design style

However, there is hope.

Earlier this year, I shared this slide at a developer conference in reference to cognitive debt, referencing a shared history with railway engineering over time developing shorthand for concepts rather than using first principles all the time:

This was in reference to Margaret Storey's article coining the term "cognitive debt".

Notably, that new skills and knowledge will mean other skills and knowledge are less needed, maybe not even at all, but being intentional about what we're choosing to lose and keep and ensuring we get what we need from that gives us a fighting chance of handling the future. And to do that, you need to know what you have - kinda like a "resource audit"!

Which is why I was so happy to see the pride in UX's heritage and history in Vivek Gopinath's talk, making the case to acknowledge the origins of the tools used in regular UX work, including the ones lost to time. I loved how it acknowledged the sheer volume of fields and disciplines it had used techniques from, especially after hearing "signal vs noise" for ML-processed data for the past 3-4 years 😅

I was astounded at how many of these I see as "product" too. But product is also a pastiche of techniques from marketing, manufacturing, accountancy, management, design and others, and I honestly loved it being laid out there.

And I'm a strong believer that understanding our history is one of the ways we can look forward and shape the future, in many disciplines and frames.

The funny thing is, someone mentioned the "5" user interviews number, and I heard it again in the break from someone discussing comparisons with academic researchers. It's one I've often heard from other UX practitioners but I've been unable to find which study or source it ever came from. It's one of UX's own "number memes" - an easy to share and believe headless number without a source. The work generally to document the sources and origins of UX methods is one of the best ways of fighting that.

You can contribute to this "UX method family tree" here: https://uxbri.org/uxdb/methods/

Back to the future, web style

One of the approaches was to look back to the early web design days, when web designers often also worked with HTML, CSS and others directly. And ask, what does that look like with AI?

Phil Morton's talk took that as "let's prototype in code again", Florian Herrengt's talk took that as "we gotta understand what this is before we can design great experiences with it". I liked elements of both of these, and their pragmatism. This slide was a fantastic little roadmap on how to get the grounding to be comfortable with designing AI features:

I felt deeply embarrassed on behalf of the software world when hearing Chiara Scarabotti, who took the "technical debt" concept, added "experience debt" for UX tradeoffs, and then proposed a method to record these tradeoffs, to allow us to trace them back to commercial or user outcomes. It felt so obvious that we should do this for technical debt, but we are actively encouraged not to spend time recording it and tracking it.

But, this goes both ways. We can't moan about people ignoring experience debt or technical debt if we're not keeping receipts on it or checking the occasional bank statement... and I say that as someone who finds admin consistency naturally difficult. So yep, as Chiara covered, we probably should be allocating time to do this.

But an interesting zoom out here is the underlying assumption was that "technical debt" was taken seriously by organisations now - at least from the designer's table. Is this a grass seems greener situation? I'm not sure, but I'll be paying attention to find out.

Expanding UX beyond the UI - for real this time

Kathy Neuss was covering an area that has felt very close to me working with a lot of software that can cause significant human harm - integrity. What does integrity mean when applied to software design?

At some point I will write about my Monki Gras 2026 talk, which was about how to create trust in complex systems and data. I also want to reflect on the conference more generally, as it's been my little "peek into the keyhole" for devops and dev tooling, and the OSS scene for quite a few years now. When I do that I'll draw in Kathy's stuff in more detail there, when the talk video from UX Brighton is available publicly.

And the wildcard... Pat Jordan covered the "human" part of user experience. Again, an area I've been very close to for the past 3-4 years from a lived practitioner perspective, and notably made me think of the Heathrow cyber breach and watching TAP's response to it at the airport that I covered in this previous post. It turns out, in my world, a well designed human experience can compensate for a lot.

He was proposing some relatively radical ideas like... letting people working in call centres make decisions for their customers. Or adjusting contract KPIs for bus services to stop penalising bus drivers for allowing extra time to let someone with a wheelchair to board (which could make them late...).

This particular slide resonated a lot with me, notably because I've always seen design (products, services, etc) and building as part of an ongoing dialogue between you and the user - and if you start by assuming they're in the wrong by default, you will get nowhere. And I've ranted previously about not listening to people, and you can't listen without an open mind.

So from a practitioner perspective who has always been borrowing from various fields, including UX, and has been observing on the ground how much this stuff matters, notably with people using machine learning based features, it was exciting to see that the idea of designing the human interaction as part of the user experience is getting some research.

I feel however, the juggernaut that is Friedmanism will (as it has always done) be a major challenge - call centre staff aren't allowed to make decisions because the labour market for call centre workers is cheaper if they can't make decisions. We live in a world where we are strongly encouraged to continue saving 10% of the costs every quarter by laying off staff or deskilling staff for shareholders. This is in contrast to investing the saved money to grow the product or business, which is what you'd need for call centre staff to have more agency in their role to support their customers. And the complex setup of the private-public model of bus services in London make enforcing more complex targets fairly extremely difficult to implement. And if you've ever tried to get an Uber refund and get an actual customer service rep... good luck. But we should continue to fight for the user, for people, and for our products to not be janky or shite.

Wrapping up

As of 2026, the UX community seems to be considering AI as something to be integrated or used, as opposed to something that can be designed right now. The first session of the day said we needed to approach this, but I don't think it's known yet exactly how that's going to happen. And there's a wider assumption that designer are at the table to allow that to happen - otherwise the design will be done by the data scientists on their own, often without them realising they're designing. And we're seeing so far what happens with that.

And yeah, go contribute to https://uxbri.org/uxdb/methods/ if you can. I'd love product to do something similar.

I liked the look outwards to integrity and service design, connecting outwards from the software to something more abstract, but paradoxically actually more human than colours and lines on a screen. And as someone who will keep banging the drum that APIs and data need designers just as much as consumer apps or websites, or chairs or lamps, this gave me hope that I might have a more receptive audience to this in the future.