think tank training centre
A school's OS, built for any school
One platform for campus and online, built to scale beyond one school.
AI for speed, judgement for direction
AI-assisted design, Human-AI collaboration, Design leadership
takeaway
The tools were the easy part
I redesigned the Think Tank home page with Claude as my working partner, plugged into my Figma design system, Miro and a shared doc. The home page is the backdrop here. The real story is what it's like to do actual work with AI, with real data and real stakeholders.
Short version: the tools were the easy part. The results came down to three things I control. How clearly I briefed the agent, how hard I questioned what came back, and which decisions I kept for myself.
The second one caught me off guard. Claude's wireframes and data analysis came back looking like solid senior work, fast and very sure of themselves. My honest first reaction was "great, let's go." That's exactly the moment to slow down. Output this good calls for extra diligence, and it takes some seniority to look past a polished surface and find what's actually wrong.
context
The project, briefly
The home page had two problems. It was slow: 6.2 seconds on mobile before the main content showed up, which is roughly forever on a phone. And it was out of step with its audience. Most visitors were now first-timers on mobile, arriving from paid social ads, and the page had been designed years earlier, before any of that.
I led the redesign. Claude dug through the analytics with me, drafted jobs to be done, built a mobile wireframe and a high-fidelity draft directly in Figma, and turned our data into editable charts in Miro. I edited every draft before anyone saw it, presented to stakeholders myself, and made the calls.
I did briefly consider having AI ship the code too. But the site is tightly integrated with HubSpot, and our developer knows it far better than either of us. Working closely with him beat routing around him.
learnings
Lesson 1: An agent is only as good as the brief
Hand an agent a loose comment and you'll get a loose result back. Same as with people, honestly. It does its best work when the brief is specific: the goal, the source material, the constraints, and what's out of scope.
The handoffs that went well were the precise ones. For the high-fidelity pass, I pointed Claude at the exact wireframe frame I'd edited, gave it the design system file, and told it what to leave alone. Being that specific meant knowing what I wanted before I asked, which is a polite way of saying the hard thinking is still mine. Next time I'll start with a one-page brief saved in the project, so every conversation starts from the same page.
Lesson 2: Form my own read before asking for Claude's
I get more out of Claude when I've done my own analysis first. With a view already formed, I'm testing my thinking against Claude's instead of nodding along to whatever it hands back. I also know roughly what the data should say, so I notice fast when something looks off.
That instinct paid off with our main metric. Claude had already built charts around it, and the story looked great. Then I looked closer and found the metric had been configured incorrectly in GA4. Tidy, confident, and wrong. I set it aside and rebuilt the case on data I could verify.
Lesson 3: Judgment doesn't get delegated
The insight that reframed the project came from context Claude simply didn't have: our advertising had moved more significantly to paid social, and that changed how they landed on the page. AI can summarize the numbers. Knowing why they moved was my job.
I edited the wireframe before stakeholders saw it, presented it myself, and decided which feedback to act on. Claude generated freely. I kept the decisions and learned that the better the output, the more careful the review needs to be.
Lesson 4: Organize the work so Claude can see it
Where the work lives inside Claude decides what Claude can see. I learned this when the context I needed was in a chat in a different Project, and Claude couldn't access it. Each Project only sees its own chats and files.
Next time: one Project per body of work from day one, with the brief, key files and instructions inside. Focused chats, one thread of work each. And anything I'll come back to, like a project log or this case study, goes in a doc instead of getting buried in a chat.
Lesson 5: Log the process as you go, not just the outcome
From the first conversation, I kept a running log in a shared doc, dictated alongside the work and capturing decisions as they happened. When the data story shifted halfway through, I rewired the narrative instead of starting over.
The log also gave me room to step back. Reading my own decisions with a bit of distance made it easier to see what was working, and to put my best foot forward with more confidence. And it saved me a lot of time writing this case study. You're reading the proof.
Lesson 6: Run a retro with Claude
At the end of a stretch of work, I asked Claude for honest feedback on how I was working with it, the same way I'd run a retro with a team. It did not hold back. My chats had grown long and tangled. I often explored options without writing down which one I picked. And I was building more tracking systems than I was actually using, which is a very designer problem to have.
I also asked how my habits compared to other designers working with AI. Claude thinks I’m ahead on using it as a thinking partner, and a bit behind on hands-on AI prototyping. Useful, slightly humbling, and now a standing habit for every project.
The outcome
Where things stand
We shipped a partial release in late September. Page speed improved, and the other numbers haven’t moved much. The timing muddied things, though: the release landed at the end of our sales cycle, so a simple before-and-after can’t separate the redesign from the usual end-of-cycle swings. The full redesign will launch as a split test against the legacy page, so we can measure the impact directly. We’re also moving to PostHog for cleaner numbers and ease of use.
I'm also taking Claude's retro feedback to heart and getting more hands-on with prototyping. Over the next while, I'll work with our developer to find places where I can contribute directly in the repository. Closer to home, I've already rebuilt this portfolio with Claude. The old site ran on a Squarespace template I made years ago to save time, and its spacing never quite held together on smaller screens. Now it's custom code that I direct and review, the same way I worked on the home page.
The way I work now: write the brief, set up the workspace, form my own read of the data, then generate with AI, edit, review with people, iterate and reflect on my process.
