Approach
I work across the people making, working with and experiencing AI, moving between research, strategy, learning and hands-on prototyping, and back again.
Where I work
The people building AI, the people expected to work with it, and the people on the receiving end are connected. Decisions made in one group show up as problems in another.
Product teams, developers, designers, managers and governance teams building or introducing AI systems.
Employees, managers and teams suddenly expected to bring AI into their everyday work.
Customers, citizens and users of products and services that increasingly contain AI.
Making AI, working with AI and experiencing AI are one system. I work across all three.
Why that mattersHow I work
A method for moving from AI ambition to changed behaviour. Each stage produces something people can react to, and testing always feeds back into the next round of understanding.
And back again. What we learn when scaling becomes the next audit.
Before recommending another tool, course or AI initiative, investigate the system around it.
Turn research into practical pathways for change. Different people need different pathways: a developer, an administrator, a product manager, a manager and a senior leader shouldn't receive identical AI enablement.
Don't spend months debating abstract AI possibilities. Build enough of the future that people can experience it. I use AI-assisted development tools such as Cursor, and generative AI, to shorten the distance between idea and evidence. I'm not limited to describing an AI-enabled experience: I can make it tangible enough to test.
Research how people actually respond to what the AI does.
The question isn't “Does the AI work?” It's “Can humans work with what the AI does?”
The goal isn't endless pilots. Use evidence from research and experimentation so the organisation becomes better at adopting AI, rather than simply deploying another tool.
What makes this practice different
These activities are deeply connected, but organisations usually run them as separate workstreams. My strength isn't knowing several disciplines. It's being able to move between them.
Research, strategy, learning,prototyping, testing,adoption.And back again.
In one day I can interview employees about why an AI rollout is stalling, map the adoption problem, run a workshop on possible use cases, turn the findings into a learning pathway or workflow, prototype an AI-enabled interaction, and take that prototype back to people to find out whether it actually works.
That movement between understanding, strategy and making is the defining characteristic of the work.
Research, AI adoption, organisational learning, service design, responsible AI, accessibility and hands-on prototyping let me hold all of these in view at the same time.
What does this person need to understand, trust, learn or do differently?
Where does AI actually fit into their work?
How should a human interact with the AI?
What should we build or prototype?
What has to change for adoption to happen?
What boundaries, oversight and decisions are necessary?
Which opportunities are worth pursuing, and how do we move from experimentation to capability?
Most AI programmes start with the technology. Human-centred transformation can also start with the problem. I connect the two.
Connecting both directions avoids two expensive extremes: building AI simply because the technology exists, and discussing human needs without understanding what emerging AI can actually make possible.
What this changes
These are the mechanisms through which the work creates value. Specific results depend on the organisation and are documented in individual case studies.
Current questions
With traditional software, people see each step. With agents, they express an intent and much of what follows happens out of sight. The experience challenge moves from designing screens to designing oversight.
Planning, automated actions, other systems, decisions and further autonomous action are often invisible to the person. The human checkpoint is where they come back in.
AI could translate what people need into the actions an organisation requires, instead of making people learn its departments, forms and categories first.
“I need to do this.”
But automation brings its own problems:
Remove complexity without removing agency.