TreeTestAi.com · Case study · 2026
A free UX research platform, built by the students who needed it.
Research tools cost more than students could pay, so our information architecture class built its own just to finish a tree test. Kate Besel and I grew ours into TreeTestAi: a free research platform with card sorts, tree tests, usability tests, surveys and interviews, plus synthesis and site maps, built for students first.
01
What it is
TreeTestAi is a free UX research platform, built for students first and open to anyone. It has five study methods and two workspace tools, and you can start with any of them:
- Card sorts and tree tests: open, closed or hybrid sorts, and a text-only menu to see whether people can find things.
- Usability tests on a live URL, a Figma file, or an uploaded coded or vibe-coded prototype.
- Surveys with branching and standard instruments: SUS, UMUX-Lite and SEQ.
- Moderated interviews, transcribed on the researcher’s own device, with the audio thrown away afterwards.
- Synthesis and site maps: quotes from any method coded into themes, and card-sort groups turned into a menu you can tree-test.
Every study opens with plain-language consent, and the AI features run on the researcher’s own key, or not at all.
It started in our Winter 2026 information architecture class at SCAD. Students got the methods without full access to the tools, so our team of five built a tree-test tool just to finish the project, and two other teams did the same. The data was good. The tool wasn’t repeatable.
02
My part
It’s a team process from end to end. There isn’t a part of TreeTestAi that Kate and I haven’t both touched. Kate led more of the design, the brand and the logos, and she works in the code too. I led more of the research tools: synthesis and affinity mapping, interviews, surveys and card sorting.
Everything we build starts from a real user pain point.
Those pain points come from our own experience as UX research students and from our peers’. We kept seeing people jump between tools for a single study: record an interview on a phone, take notes somewhere else, transcribe it in another app, then move it all into FigJam or Figma so the team can see it. We’re bringing that into one place, and making the synthesis afterwards easy, with AI or without it.
We’re both constantly pushing updates, almost every week, and evaluating them against student feedback and our own research expertise. I test it end to end myself, from building a study to taking it as a participant to reading the results. I also did the method research behind its rules, so a small sample reads as a direction, not a verdict.
Before we shaped the AI that helps code interview transcripts, I went back to my own coding: 432 rows from 13 participants in one past study, 297 from 8 in another. My real practice didn’t match the textbook guardrails we’d drafted. So the AI proposes a code list, a person approves it before anything is applied, and its examples come from my coding. Or leave the AI off and code it all by hand.
03
What we found
-
Observation · IA class, Winter 2026
Our team and two others each built their own tree-test tool just to get through the project.
The demand was real. What was broken was access, not the students.
-
Meeting · an industry professional, at UX360 · his suggested reframe
Give students industry-grade experience at school.
His harder point was the “so what”: data has to become an insight, and the insight a decision.
-
Dogfood · my own walkthrough
The results page said “AI can make mistakes. Please verify insights with collected data.” above an empty Key Insights section.
A solo student is the analyst most likely to over-read a small sample. They need guardrails, not an apology.
04
What changed
- Who it’s for. We dropped the pitch of “a tool with a bunch of test types” for research that people who aren’t researchers can run, and we ruled out building a recruitment platform.
- Usability results without an AI layer. Key Insights reads usability tests against published norms (Sauro & Lewis, MeasuringU), with adjusted-Wald intervals and a plain warning when a sample is “a pilot, not a measurement”.
- Rounds, not edits. A live study’s build locks to protect what it’s already collecting. A change starts a new round, and rounds can be compared.
- Themes that need more than one voice. In synthesis, each theme shows how many separate interviews it came from, and the AI isn’t allowed to declare themes on its own.
It isn’t finished. We keep shipping updates, new tools and features, shaped by our own development and by student feedback, including the bug and error reports built into the product.
- Sept 16
- Live on treetestai.com, 2026, after a ground-up rebuild.
- 5 + 2
- Study methods (card sort, tree test, usability test, survey, interview) plus synthesis and site maps.
- $0
- A free tier for everyone, built for students first. Try it at treetestai.com.
05
Inside the product
One demo study, followed through the product: a fictional online store whose customers can’t work out where to change a delivery address. First the structure, then the evidence, then the why.
1 of 3 · Structure · card sort → site map → tree test
From piles to a menu worth testing.
Only 67% found it. The results page shows what the other third did.
2 of 3 · Evidence · the results, drilled down
Every number has evidence underneath.
The paths show where people went. Conversations show why.
3 of 3 · Why · interviews + a usability test → synthesis → version 2
From conversations to a fix.
Demo data. The card sort and tree test ran in the live product as “Portfolio demo” studies with six scripted test participants each; the interview and usability quotes are fictional. The numbers show what the product does, not a research finding.