3. Categorisation

Three days on one concept changed everything: from a flashy but pointless feature to a game where every choice had a reason. Same objects, different groupings — and she finally saw that categorisation depends on what you’re trying to find.

We spent three days on this one.

Not three sessions but three full days: coming back to the same concept, rebuilding the same game, until it was actually good enough to move on. I’d made a decision at the start of this series: I wasn’t going to let us jump topics superficially. If something hadn’t landed properly, we weren’t moving forward just to keep pace.

Categorisation nearly broke that rule. And then it produced the most sophisticated game she’d built so far.

Same things. Different groups. Both are correct.

Categorisation, I told her, is the act of grouping things based on a shared attribute or trait. It sounds simple. It is, at the surface. But the interesting question is this: who decided the categories, and why those ones?

I started with something immediate. Vasuda’s toys scattered across the living room floor.

“How would you sort these?”

She looked at them. “By type. Soft toys there, rattles there, books there.”

“Could you sort them a different way?”

She thought about it. “By colour. Or by which ones she actually plays with versus which ones are just there.”

“Right. Same toys. Completely different groupings. Which one is correct?”

She paused. “All of them?”

“All of them. The category you choose depends on what you’re trying to find out. That’s the whole point of categorisation.”

We talked about libraries next: how the same book could be filed under the author’s name, or the subject, or the reading level, or the year it was published. Each system serves a different person trying to find a different thing. There is no neutral way to categorise. Every system reflects a decision about what matters.

She’d been reading an animal encyclopaedia recently, deep into reptiles and amphibians, the kind of reading she does when something catches her interest and she can’t put it down. The categories were already there, waiting to become a game.

How she chose what to build

She knew immediately what she wanted to build. A sorting game around animals — reptiles, amphibians, the creatures she’d just spent a week reading about. 

The first version came back on day one with something I hadn’t asked for: a customisation button. The player could add their own categories to the game.

It looked impressive. It felt like a feature.I asked her three questions.

“What does the button do, exactly?” She explained, the player could add a new category name.

“What kind of category would someone add?” She paused. “Why would someone add it?” She didn’t have an answer. 

She’d built it because it seemed like a cool thing to offer, without thinking through whether anyone would actually use it, or what they would do with it if they did. It was a feature built for the builder, not the player.

She got defensive when I pushed. She’d worked hard on it. It looked good. She wanted it to be there.

I didn’t argue with her. I just kept asking the questions. What does it do? Who is it for? What happens when someone clicks it?

The answers weren’t coming. And slowly, without me saying it directly, she arrived at the conclusion herself: the button didn’t belong there. She removed it.

But there was a second problem. The game started immediately: before a player who might want to add a category could even make that choice. The flow was broken before the feature could have worked, even in theory.

Flawed thinking had produced flawed software. She could see it now that she was looking.

She rebuilt it with two categories, clean options and no customisation button.

I looked at what she had and felt something was still missing. The game worked. But categorisation is one of the richest concepts in the series — it sits at the foundation of every database, every filing system, every way humans have ever organised knowledge. A simple two-bucket sorting game didn’t do justice to that.

I asked her to think more.

Staying with the problem for 3 days

Day two, she came back with the same game — but with more complex creature names like Gharials. Axolotls, Caecilians. The categories were still the same. The thinking was still the same. She’d made it harder without making it deeper.

This was the gap I was struggling to name. She was adding complexity — more pieces, harder words, more to manage — but not sophistication. The game was more difficult to play. It wasn’t more interesting to think about.

Day three, she came back with Venn diagrams.

I hesitated. I asked her: would she want to play a game in Venn diagram format?

She thought about it for a moment. “It might be too boring,” she said.

She’d felt it herself but she was confused about why I’d pushed back, and what exactly I was looking for. She’d tried simple, I’d said go deeper. She’d tried complex, I’d said not quite. She’d tried Venn diagrams and instinctively rejected them herself. She didn’t have the language for what the difference was.

So I sat down and explained it.

Complexity, I told her, is how confusing or messy something is because it has many parts and rules that make it harder to understand or fix. Like a toy with too many pieces and a ten-page instruction manual. It’s hard to play with. It breaks easily. When something goes wrong, you can’t find where.

Sophistication is how clever or smart something is because it uses good ideas to work better or do more. Like a simple toy that does something really cool. You understand it immediately. But the more you play with it, the more you discover.

We don’t want to make a game that is hard to play. We want to make a game that makes you think harder.

She was quiet for a moment.

Then she looked at the Venn diagram idea and shook her head. “That’s complex. Not sophisticated.”

And then she rebuilt the game from scratch.

The design doc

What came back was the Sort-a-thon.

Three levels. Robots competing in real time. A Venn diagram question embedded inside Level 2 — not as the whole game, but as one question among many, where it made sense. Edge cases handled: if an option belongs in more than one bucket, a pop-up appears asking the player to think again. Items that could go in multiple places. A “baby sister” filed under Living Things in Level 3 — because of course she put Vasuda in the game.

Here is exactly what she wrote:

The Sort-a-thon

Mission: Sort everything before the robots do. You have to beat your robot competitors by being fast and accurate.

There are three levels: Easy, Medium, Hard. If you succeed in all of them you become the Sort-a-thon champion and win a trophy.

Level 1 — Easy

1. Sort the following animals into groups. Animals: Snakes, Crocodiles, Frogs, Newts, Lizards, Salamanders Buckets: Reptiles / Amphibians

2. Sort the numbers into buckets. Numbers: 3, 6, 6, 9, 3000, 15111, 18, 18, 3000 Buckets: Multiples of 2 / Multiples of 3

3. Sort the birds into buckets. Birds: Myna, Pond Heron, Indian Robin, Red Whiskered Bulbul, Cattle Egret, Common Iora Buckets: Short birds / Tall birds

Level 2 — Medium

1. Sort the plants into buckets. Plants: Chrysanthemum, Ashoka, Tomato, Mango, Money plant, Aloe vera Buckets: (player names their own groups)

2. Sort the following games and activities in a Venn diagram. Games: Chess, Battleship, Cricket, Javelin throwing, Scrabble, Badminton, Football Circle 1: Indoor games only / Overlap: Games you can play indoors and outdoors / Circle 2: Outdoor games only

3. Sort the following numbers. Numbers: 2, 4, 3, 5, 7, 21, 18, 11 Buckets: Prime Numbers / Composite Numbers

Level 3 — Hard

1. Find the group it belongs to. Items: Dog, Plant, Apple, Bird, Robot, Airplane, Eraser, Notebook, Pen, Baby sister, Laptop, Car, Bus, Auto, Shovel, Bottle, Black Kite, the Sun, the Moon Buckets: Living Things / Vehicles / None of the above

2. Find the correct rule. Items: Airplane, Bird, Helicopter, Jet, Sunbird

3. Find the group it belongs to. Items: Bowl, Robot, Turtle, Laptop, Mountain, Farm, Hospital, School, Mango grove, Birds, Amphibians Buckets: Man-made things / Natural things / Places

Instructions for ChatGPT: 
- Make this a single HTML file.
- There should be a black background.
- Shuffle the questions every time you play
- Everytime a player makes a mistake, the game ends
- There should be a working Play Again button
- Make all the options in a box. They should be clearly visible.
- Don’t change any of my questions
- Whenever you have clicked something and it is right, turn that option grey
- After the player completes one question, the next question should be visible.
- It doesn’t matter in which order the player drops the options into boxes.
- The buckets should remain as is
- The game should only start with Level 1
- The Level should be written on the top in the middle
- There should be a continue game button next to the pause game button.
- Whenever the user clicks and adds something in the bucket, the item should appear there so that the user can see it
- The user should be able to drag and drop the item
- The Play again button should be in large font and should be under the questions in the middle
- All options should be able to be in two or more buckets
- Once the user finishes the questions in one level, he/she should immediately go to the next Level
- If the user puts an option which goes in both of the buckets, a pop up should turn up. The pop up should say “ Hmmm, don’t you think that the option goes in more than one place?
- The pop up should come only once in every option that goes in two places
- Only if the user completes everything, the question should be completed.
- Once a question is completed and is valid, should the next question appear.

Look at Question 2, Level 2. She took the concept she’d rejected as a standalone game — Venn diagrams — and placed it exactly where it belonged: as one question inside a larger game, where the overlap mechanic added genuine thinking without dominating the experience. That’s the sophistication vs complexity distinction applied in practice. She didn’t explain it that way. She just built it that way.

And “baby sister” under Living Things in Level 3. She put Vasuda in the game. Of course she did.

Design → Build → Ship

With the design doc done, she opened ChatGPT.

Her prompt this time runs to more than thirty specific instructions — interaction details, edge cases, visual specifications, robot behaviour, level transitions, pop-up logic for items that belong in multiple buckets. And she got the output she wanted in one attempt.

She put it in her own words afterwards: “This time, I was better at prompt writing. I didn’t have to send 12 whole messages to ChatGPT at one go. I thought, wrote and then got the output I had wanted at once.”

Then she tested it herself before anyone else could. Five fixes in the second commit:

The customisation button was gone. The Play Again button — actually working this time, with the Game Over screen clearing properly when clicked. The robots — starting immediately instead of waiting. The options — moved above the buckets where a player’s eye naturally goes before deciding where to drop something. Small change. Obvious once you see it.

Each fix came from her playing her own game as a player, not as the person who built it. Looking at things from builder’s eye instead of player’s eye.

Three sessions in, the thinking was clean enough that the build almost took care of itself.

What this is actually building

The customisation button is what I keep coming back to.

She built it because it seemed cool. She defended it when I questioned it. And then, without me telling her to remove it, she arrived at the conclusion herself through three questions she couldn’t answer: what does it do, who is it for, why would someone use it.

That moment — a feature removed not because someone said it was wrong but because she couldn’t justify its existence — is one of the most professional instincts in product design. Features get built because they seem impressive. They get removed when no one can explain who they serve. Most people spend years in professional environments before they internalise that discipline. She encountered it on day one of a three-day struggle with a concept that refused to be rushed.

The three days matter too. I could have let her move on after the simple two-bucket game. It worked. It demonstrated categorisation. We could have ticked the box and gone to concept four.

But the box wasn’t the point. The depth was the point. And depth took three days of her coming back, rebuilding, getting pushed back on, getting confused, getting a new framework to think with, and then arriving at a game that was genuinely more sophisticated than anything she’d built before.

The Sort-a-thon has a Venn diagram in Level 2. Not because I suggested it — because she understood, after the complexity vs sophistication conversation, that a Venn diagram as one question inside a larger game is sophisticated. A Venn diagram as the whole game is just complex.

She made that call herself. On day three, after two days of not quite getting there.

Categorisation is where she learned that good thinking takes time. ⚡️

What’s next

The Sort-a-thon is sitting on her laptop. She hasn’t asked a friend to test it yet — which means the bugs are still hiding, waiting for someone who doesn’t know the rules to find them.

The Sherlock Holmes game is still in the backlog. She stopped asking about it after day two of this concept. I think she understood, somewhere in the three days, that the tools she’s building are real and the backlog is not just a way of saying no.

Next up is cause and effect — if this happens, then that follows, and the moment she traced a chain of consequences so far forward that she surprised herself with where it ended.

New here? Start with the series introduction. Parent’s Guide: Computational Thinking for Pre-Teens