What do Lego and information architecture (IA) have in common? Yes, I’m doing one of those ‘what can we learn from a totally unrelated thing?’ posts. But I really do think there’s a parallel to explore.
The 7,500-piece Lego Millennium Falcon kit was a fixture on our kitchen table for months while Thom, my husband, built it. I didn’t take much interest until it had been disassembled and it was time to put the blocks back in the box. Organising the pieces was a task that my order-loving brain could get behind.
Undeterred by my total lack of knowledge about Lego or Star Wars, I started off by grouping the blocks by colour:
- Dark grey blocks
- Light grey blocks
But as we proceeded, it became clear that a big group of blocks of the same colour was unhelpful; it’s harder to find what you’re looking for when you don’t have colour to help with recognition. So from there, I moved on to picking out the biggest pieces, and them grouping the smaller pieces:
- Dark grey blocks:
- Big flat square bit
- Big flat rectangle bit
- Small brick
- Small flat bit
Still not that helpful. I realised I needed to learn a bit about the Lego itself, so I could understand the function of the pieces and group them that way, making it easier for the next person to build it. I even found a taxonomy of Lego that names and classifies all the elements:
- 1×2 Brick, dark grey
- 2×4 Plate, dark grey
But what has this got to do with IA?
I’m working on an IA at the moment, and as I started trying to organise the 900 tasks I gathered in the discovery, the Lego came back into my mind: it felt like the same kind of challenge: creating structure, meaning, and utility from a big formless mess of stuff. When I reflected on it, I thought of three things that I wish I’d known before I started on the Lego AND before I did my first IA project. And I thought maybe someone else might find them useful too:
1. Start with research
If I’d started the Lego process with some knowledge of what I was dealing with, I could have found the right way to group the pieces a lot faster.
When it comes to IA, you always need to start with research in two areas:
- Subject matter
- User needs
For the site I’m working on right now, I’ve been through a long discovery process: lots of user and stakeholder interviews, a content audit, data analysis, desk research, and more. I’ve worked with the client before too, so I’m coming into things with a good grounding in both areas. This means I’ve got a much better chance of getting to a solid IA in a shorter time.
2. Don’t assume: experiment, test, and iterate
With the Lego, I thought I knew what the right approach for organising the pieces was. But when I started using it, I realised I was wrong (repeatedly). Colour made sense initially, but if I’d stopped to think about the experience for the user, I never would’ve taken that approach. The IA equivalent might be organising things by internal departments: it makes sense to you, but it probably won’t to your users.
With my current IA, I have a hypothesis about what the right solution might be. But ‘hypothesis’ is the key word. It’s an educated guess, and now I’ve got to prove it. And the process of proving it is going to be a bit like the Lego. I’m going to spend the next week or two sketching out a bunch of different options, seeing how they work in practice, learning from each one, until I have something I’m ready to test with users in a tree test.
3. Don’t be intimated by the task.
With so many pieces, it was tempting to just throw all the Lego in the box for speed and make sorting it out a problem for future me to deal with. And that’s how a lot of people treat their IA: it’s too big a problem to solve, so they just ignore it.
Don’t be that person. You’re creating a mess for your users that will make your site harder for them to use. You’re also creating a big problem for future you – or future employer – to sort out later on. Take a deep breath, take a step back, break the task down into small steps, and get started.