Across seven events at Hippocampus, the most useful conversations weren’t really about tools. They were about who gets included, what we automate, what we test and how we know whether something works.
We kicked off the festival bright and early with a Monday morning event talking about the difference between accessible and inclusive design. By Thursday evening, a room full of testers used their phones in tandem to create a light show.
In between, we explored digital identity, AI, organisational maturity and the different routes people take into design. Each conversation came back to a similar challenge: technology can help us move faster, but it cannot make the difficult decisions for us.
Compliance is where the work starts

A service can meet a standard and still not meet everyone’s needs. That insight was the starting point for What compliance misses: Moving from accessible to truly inclusive design, led by Naomi Busuttil and Hannah Atkinson.
Accessibility standards such as the Web Content Accessibility Guidelines give teams an essential foundation. But passing an accessibility check does not necessarily mean that someone will feel safe, understood or included.
Sometimes exclusion begins with a small field on a form. A person’s name might not fit the format the service expects. Someone might be required to provide irrelevant information for their use of the service. A venue’s website might be digitally accessible but fail to explain where its accessible entrance is.
These design decisions shape whether someone can use a service with confidence.
Naomi and Hannah also introduced trauma-informed design and asked attendees to think about:
- Helping people understand what will happen by guiding them predictably through a service and avoiding experiences that leave them feeling surprised, trapped or misled.
- Consider what information needs to be collected and explain clearly why it is needed.
- Use direct, transparent language that helps people understand the service and the choices available to them.
- Give people more control over their own, customised experience, including options such as a low-sensory mode.
This includes the language used by customer service teams, the sensory impact of a physical space and whether people can understand what will happen next.
The session left us with a useful question: who isn’t in the room when a design is made?
Designing for a broad group of people means including those people in the design process. Engaging directly with users does more than help a team identify accessibility barriers. It gives the service a voice grounded in real experiences.
The same issue appeared from a different angle on Tuesday in Nobody wants to prove who they are: Designing identity UX that people don’t hate.
Andy Turner explored one of the most frustrating moments in many digital journeys, proving you are who you say you are.
Identity verification is absolutely necessary, but it is also a point where services can quickly exclude people. When the process depends on documents someone cannot find, technology they do not have or instructions they cannot follow, the effect is bigger than an abandoned form. It can prevent someone from accessing healthcare, banking or another essential service.
Andy’s session ended with attendees redesigning a page themselves. It moved the conversation from identifying friction to doing something about it.
The real AI skill is knowing when to use it

Back on Monday afternoon, the conversation had moved from inclusion to delivery.
In More than AI-dministrators: The future of delivery in the age of AI, Alex Leppert, Jade Cosgrove, Olli Drury and Stew Livingstone explored where AI can help delivery professionals and where it cannot.
AI adoption across teams can be jagged. Some people are using it to improve Jira tickets, prepare status reports or bring information together. Others are cautious, unconvinced or still trying to understand where it belongs in their work.
A status report deals largely in facts. AI can help organise those facts and make risks more visible. A conversation with someone who is having a difficult time is different. A summary might capture the words spoken in a one-to-one, but not the look on someone’s face, the hesitation before an answer or the stress they do not express verbally.
The most valuable skill may not be knowing how to use AI. It may be knowing what to delegate to it.
The panel also considered transparency. Teams need to be able to explain how work was produced, how it was checked and whether somebody else could repeat the process. If people quietly use AI without sharing the context or governance around it, they may be inadvertently introducing risk for the team.
That conversation continued on Tuesday evening when we welcomed PyData Leeds: Leeds Digital Festival ’26 to Hippocampus.
The talk explored the performance of local language models. Each model was assessed against the same task, with the results considered alongside the cost of running it. Setting an acceptance criterion gave the comparison a practical focus and helped show how teams can select a model that is appropriate for the work they need to do.
The discussion also covered measurement and trust boundaries. Teams need to understand where a model runs, who controls the infrastructure and what happens to the information it processes. They also need a reliable way to judge whether introducing AI has improved the outcome.
This kind of practical exchange is central to community meetups such as PyData Leeds. People can compare what they have tried, discuss where things have gone wrong and learn from evidence gathered outside their own teams. The event added a useful data and engineering perspective to the wider conversations about AI taking place throughout the week.
How design capability develops

Wednesday’s programme turned to how design capability develops within organisations and throughout people’s careers.
During Building a user-first culture: Mapping your design, Ben Childs, Alison Whitehouse and Matt Lund introduced several user-centred design maturity models, including approaches used by Jisc, the NHS and Nielsen Norman Group.
A maturity model can give an organisation a clearer picture of how design is understood and supported. It can also produce a daunting list of areas to improve, particularly for someone trying to influence change without control over the wider organisation.
The session gave attendees a way to make that process more manageable. People selected a specific context, interviewed each other and worked through the assessment in pairs before sharing their results. The assessment could then be taken away and used again with colleagues.
This allowed people to focus on an area where they could begin building support. Evidence gathered from a smaller part of an organisation can help people explain the value of user-centred design and involve more stakeholders in the work.
The conversation also covered AI in design roles. People and organisations are moving at different speeds, which creates uncertainty around what is acceptable and where a baseline should sit. Starting with a defined task gives teams a practical way to explore its value while keeping the risks visible.
Later that day, Squiggly Design Careers looked at how individuals build their capability over time.
Andy Long, Jenni McGeachan, Zoe Slater, Manny Jhutty and Mark Portnell had all reached design through different roles and industries.
Jenni brought experience from music and digital marketing, where she learned the importance of listening to audiences as well as internal stakeholders. Zoe’s background in teaching helped her become comfortable facilitating rooms of people, while her studies in social anthropology encouraged an interest in how people behave and experience the world around them.
Manny moved from graphic design into UX, building on his visual skills and experience of investigating how people move through a journey. Mark combined experience from computer science, project management, theatre and cyber security. Andy’s route through marketing, government and the civil service gave him a grounding in content, governance and stakeholder management.
The discussion made space for the parts of career changes that are often left out of job descriptions. Several panellists had reached a point where they knew they wanted to do something different, even if the next step was not yet clear.
Their advice included:
- Contact people who are already doing the role and ask about opportunities.
- Apply design principles to the work you currently do.
- Find a real problem, client or group of users to work with.
- Explain the evidence and thinking behind your decisions, rather than relying on polished designs alone.
Previous experience gives people something useful to bring into design. It shapes how they facilitate, investigate, communicate and make sense of complicated situations.
Previous experience gives people something useful to bring into design. It shapes how they facilitate, investigate, communicate and make sense of complicated situations.
Testing what you can’t control
The week finished with Ministry of Testing Leeds: Testing What You Can’t Control, led by Adam Davis.
Adam talked through the challenges of building and testing a system that depends on phones, cameras and the physical environment. His creation, Pixelmesh, connects a group of phone screens so they can show a light display.
For that to work, the system needs to identify each phone, understand where it is and send it the correct information. Adam initially experimented with AprilTags, visual markers similar to barcodes, before augmenting that and testing other ways to detect devices at a greater distance.
The project generated hundreds of commits across its controller, server, phone interface, documentation and detection work. Detection represented the smallest part of the code, despite being the most difficult part of the problem.
Adam used an AI coding agent throughout the project to suggest approaches and produce code. It helped him work through ideas quickly, although repeated prompts could not explain why the camera was failing to find a phone. Answering that question required testing the physical setup, changing individual variables and collecting evidence from each attempt.
The talk encouraged testers to recreate more of the physical environment surrounding a product. Code can behave correctly while the wider system still fails because of a device, network, camera or condition that the team could not fully control.
The live demonstration ended with audience member’s phones lighting up in different colours and patterns as they would at a concert. It was a fitting end to a week that had moved between design principles, organisational change and practical experimentation.
Continuing into week two
The programme continues at Hippocampus with sessions on language, responsible AI, product strategy, collaboration between design and engineering, and brand growth.
Week two includes No such thing as a synonym, An introduction to using AI responsibly in Human-Centred Design, Beyond the interface: Applying design thinking to product strategy, Using AI to build better services across role boundaries and CIM × MET Marketing.
Explore the full week-two programme and book your place at Hippocampus.
Hippo
Hippo is a trusted digital transformation partner, putting people first in design, data and delivery



