Practical UX Research for Development Teams

Understanding your users - whether through interviews, surveys, analytics, or more structured UX research methods - is key to building good products. Did you know that conducting well-structured usability tests with just five users can uncover over 85% of your product’s usability issues?

In this workshop, we'll cover everything you need to know to:
- choose the right research method
- recruit the right participants
- use best practice Information Architecture techniques (such as card sorting and tree testing) to uncover mental models
- prepare and facilitate usability tests to help improve your products

We'll also dive into how AI can be used in UX research (and whether it should) to reduce costs and time associated with conduction 'proper' research.

Whether you’re a developer, designer, content strategist, or product owner, this workshop will help you confidently plan, conduct, and apply user research findings to your work.

Tested, Typed and Completely Unusable

As good developers* we test components, types, APIs, accessibility rules, and end to end journeys... and then we ship them. Unfortunately, most of the time the interfaces we ship never meet actual humans until they make it to production.

There’s a lot automated testing can’t tell us. Do users understand the language we’ve chosen? Does our information architecture match their mental models? Can they work out what to do next? Do they even notice the shiny new feature we’ve built?

Playwright is great, but completing a Playwright script isn't the same as completing a task - and just five lightweight usability testing sessions can uncover problems that thousands of automated assertions would miss.

Let's explore where automated testing ends and usability testing begins, how to run useful sessions without a research team or enormous budget, and how to turn what you observe into better interfaces—and better tests.

.Net is proprietary, PHP is dead, and everything you know is wrong.

As developers it is easy to get trapped in our comfort bubbles and assume that our 'knowledge' is informed. After all, many of us have spent years around or adjacent to programming technologies, and if we can't formulate educated opinions of those technologies... who can?

The problem is that at least *some* of your opinions are likely based on outdated information, personal experiences that don't reflect the whole, or learned bias.

Why should you care? Because you might be avoiding technologies (or sticking with others) because of those biases, even when they aren't the best fit for you, your employer, or your clients.

Together, let's dive into some of the most popular fallacies about web programming languages and approach them with fresh eyes - most importantly, acknowledging that our biases do exist, and that it is healthy to challenge them (even if we don't act on them).

You probably don't need JavaScript for that (anymore)

CSS is often overlooked by full-stack developers as 'not real code', but it's a critical part of crafting a beautiful, functional digital product. Also, you're probably doing it wrong.

The last few years have introduced some major improvements to CSS that allow for us to do more than ever using *only* HTML and CSS - improving front-end performance, accessibility and code maintainability.

Let's look at some code examples of new CSS features that will let savvy developers ditch the bloated JavaScript, for everything from select fields to dynamic popups, automatic light/dark mode adaptation, accordions, and of course - better animations than ever before!

From Mess to Success: Embracing Full-Stack Architecture

How many times in your career have you thought to yourself - "You probably should have mentioned that before"? For most people, the answer to that question is TOO MANY.

Too often, there is a disconnect between what users need, what clients ask for, what designers design, what developers build, and what systems can support. Product architecture is not the responsibility (or the fault!) of any one person or team, but it is up to everyone to make sure it doesn't happen!

This talk takes experiences from all over the spectrum, from customer liaison, to UX consultant, to database architect, to software developer - to share a blueprint for how you can avoid common communication pitfalls, and make sure your next project is less mess, more success.

I bring a unique perspective to this talk, given that I have such a strong background in data and database design, as well as a globally recognised certification in UX research. I'm also a full-stack developer and have worked throughout almost all of the product development process. This talk is equally relevant for one-man-bands, or large silo’d teams and has something for everyone, whether they’re a software architect, a developer, or a UX designer. While there will be a bit of technical stuff (mainly database and UX research related), the fundamental thing this talk is really about is communication, and why it’s so important in any software development journey. This talk can be delivered as a keynote.

The UX Research AI Frontier

It's unlikely that AI will ever truly replace UX researchers, but as LLMs come along in leaps and bounds, we'd be pretty silly not to consider whether we can use these tools to 'research' more effectively and save ourselves time and money.

The real trick that we need to discover is... what can we offload to an agent? When do we need real live humans to make sure we're not ending up in AI bubbles? Is there anything AI can do better than humans? And what are the repercussions if we get it wrong?

Nielsen Norman certified UX consultant Jo Minney looks at some of the most common UX research practices and how AI can be integrated into them ethically - and whether or not the trade off is worth it.

Engineering Constraint: What F1 and Grass-Roots Charities Have in Common

Formula One teams operate under some of the strictest constraints in engineering - fixed budgets, rigid rules, and razor‑thin margins for failure. But rather than being a handicap, these are a key factor behind F1 driving decades of breakthrough innovation.

Grass‑roots charities work under constraints just as severe, but far less glamorous: Minimal budgets. Tiny teams. Users in crisis, accessing life‑saving services on decade‑old devices over unreliable connections. In this world, the usual assumptions about tooling, risk, and process collapse - and failure doesn’t mean churn or complaints, it means real harm.

When options disappear, creativity stops being optional. Drawing on real charity projects (and lessons from F1), this talk explores the uncomfortable trade‑offs, ugly workarounds, and unexpectedly elegant solutions that emerge when constraints are absolute.

You’ll leave with practical ways to apply constraint‑driven problem-solving to your own work, even when your day job looks nothing like Formula One or solving global poverty.

UX for developers: Why you shouldn't listen to users

Users will happily tell you what they want. That doesn’t mean you should build it! The first rule of usability is to pay attention to what users do, not what they say.

This talk introduces practical UX research techniques that engineering teams can use to take products from good to great - from structured usability testing, to lightweight behavioural analytics.

We’ll explore what each method is good for, where it can mislead you, what tools, costs and tradeoffs are involved, and how to combine qualitative and quantitative signals to make better decisions about what to build next.