Things I build.

I kept noticing that researching AI products isn't quite like researching normal software, but most research planning still treats it the same way. A few things nagged at me: users blame themselves when the model fails, the same prompt gives two participants completely different experiences, think-aloud falls apart when people have no idea what to expect, and “trust” stops being something you want to maximise and becomes something you want users to calibrate. I'd been collecting these for a while, and eventually wanted to see if I could turn them into something a researcher could actually use.

You describe your study, the AI product, your goal and questions, the stage, the methods you're weighing up, who you're researching, and it acts like a senior researcher reviewing your plan. It sharpens your research questions, re-prioritises your methods (and tells you when the ones you picked won't get you to your goal), flags the methodological tensions specific to your study, and suggests what to actually measure. The part I cared most about getting right was the critique: it tries to predict where your particular study will get harder than you expect, and what to do about it.

It runs on nine principles I developed for how AI research diverges from classic product research, mapped against eleven common study types (first-time usability tests, post-launch satisfaction, generative interviews, brand health, and so on). Each study type pulls the principles most likely to bite, with conditional logic for the ones that only matter when something like trust or usability testing is in play. A lot of it comes straight out of my own work, the mental-model principle, for instance, comes from watching users treat a conversational shopping assistant like a search box, because that was the only model they had for “type into a box on a shopping site.”

The ideas, the principles, the logic, the way it critiques a plan, are mine, from my own research experience. I used AI tooling to help polish the language and assemble the app itself. That feels right for a project like this: it's the kind of “could I build this myself, quickly, with AI?” experiment that the planner is, in a way, about.

This came out of my work on Metacore's DEI committee. It's something I took on because I care about it. Inclusive design tends to live in good intentions and vague principles which makes it easy to nod along to and hard to actually use. I wanted something a team could pick up in a real decision, a feature, a story beat, an event, and use to ask better questions early before assumptions harden into something shipped.

A checklist built around a simple idea: inclusive design is about being honest and intentional about who an experience works for, who it might leave out, and who has to work harder to get the same experience. It's organised around three questions: who are we designing for, how does the experience actually work, and how do we check ourselves – each opening into more specific prompts about assumptions, friction, accessibility, representation, language, and evidence. It comes with a set of red flags, the phrases that should make a team pause like “it's for everyone” when only one audience was considered, and a worked example showing the lens applied to a typical feature decision.

Early. And by anyone. There's a full version for deeper work and a three-question quick version for faster conversations – because a lens only helps if people actually reach for it. It's designed to make trade-offs visible: who a choice rewards, who it quietly excludes, and what the team should watch for.

It's the practical companion to one of my research principles: ask who it works for and who it leaves out. It grew out of something I care about well beyond any single role: designing for the people a product usually overlooks.