Apr 1, 2026
Informed Simplicity
I stared at a prototype for a while. Sports club websites, a system to cover everything from ice hockey teams to rugby clubs to professional soccer organizations. And after days of iteration, I finally looked at one screen and thought: that's it. Everything I need is right there.
No junk drawer navigation. No dashboard crammed with stats nobody asked for. Just the thing, doing the thing.
That moment has a name. Architect Matthew Frederick called it Informed Simplicity, and once you understand the full arc it belongs to, you start seeing it everywhere.
The curve you're already on
Matthew Frederick described three levels of knowing in his book 101 Things I Learned in Architecture School. Designer and author Tommy Geoco mapped the same idea onto product design as the Simplicity Curve. The stages look like this:
Uninformed Simplicity. You're new to a problem. The solution feels obvious because you haven't yet seen what's underneath. The designs look clean because they're incomplete. The designer just doesn't know what they're missing yet. You'll find this stage scattered across Dribbble portfolios.
Informed Complexity. You dig deeper. You talk to users, read documentation, sit with edge cases. And suddenly, everything feels critical. You add a filter for this, a toggle for that, a section for the thing that only 2% of users will ever need. The design balloons. This is where convoluted dashboards are born.
Informed Simplicity. You've earned enough understanding to cut back deliberately. You know what to leave out and why. The result looks obvious, even inevitable. Don Norman called this invisible design. TikTok's content discovery. Airbnb's booking flow. You use these things and don't think about them at all.
I lived every stage of this on one project
When I started building a website system for professional sports clubs, I knew nothing about the domain. Ice hockey clubs have roster management and game-day schedules across multiple arenas. Rugby organizations need match reports, league tables, and injury updates. Soccer clubs at the first-league level carry everything from ticket sales to youth academy info to sponsor sections. I didn't know any of this going in.
My first designs were clean. Almost suspiciously clean. I was in Uninformed Simplicity, confident because I was ignorant.
Then I started learning. I talked to club administrators. I read through existing sites, terrible ones, and started understanding why they looked the way they did. Every cluttered sidebar told a story. Someone had needed all of that.
So I crammed it all in. The pages got heavy. Navigation became a problem to solve rather than something that just existed. I was deep in Informed Complexity, and it felt productive, because at least I understood what I was dealing with.
The shift came gradually. A few days away from a prototype, then coming back and looking at it fresh. Stripping a section. Asking: does this actually need to be here? What breaks if I remove it?
Then one day I looked at a screen and it clicked. Everything was there. Nothing extra. That zen moment. That was Informed Simplicity.
The trap I kept falling into
Here's what I noticed in myself: the temptation to skip the middle stage entirely.
When I was moving fast, I'd jump from gut instinct straight toward something shippable, without ever really sitting in Informed Complexity. The result looked clean, but for the wrong reasons. Incomplete, not refined.
Tommy Geoco calls this the core risk of warp-speed design in his Warp Speed Design course: unintentional product complexity, or its opposite, unintentional product shallowness. I experienced both ends of that on this project.
What "good enough" actually taught me
The thing that helped most was reframing what "good enough" means. Not as settling, but as a deliberate decision. One that gets something testable in front of real users, reduces risk by exposing assumptions early, and stays flexible enough to change without unraveling everything.
Tommy writes about this in his book Making Design Decisions. Good enough as a stepping stone, not a destination.
With my sports club system, I didn't reach that zen moment in one sprint. I got there by shipping versions that were deliberately incomplete, watching where things broke down, and cutting back with intention rather than guessing at what mattered.
What I'm still learning
I don't think Informed Simplicity is somewhere you arrive and stay.
Looking back at the project, I can see moments where I thought I had it, and then a new club type showed up with different requirements, and I was back in complexity. That's fine now. I know what the curve feels like, and I know I'm moving along it rather than stuck.
The cluttered version of a design isn't a failure. It's evidence that you learned something. The question I keep asking myself now isn't "why is this so complicated?" but "do I understand it well enough yet to simplify it?"
That shift in question changed a lot for me.