One of my favourite concepts is organized complexity. Some problems are simple. Some are chaotic. But many of the problems product designers work on every day sit somewhere in between: hundreds of people, systems, rules, edge cases, business goals, technical constraints, and human behaviours, all interacting with one another.
You do not solve those problems by removing complexity. You organize it.
The term dates back to 1948, when mathematician Warren Weaver described a category of problems that could not be understood by isolating individual variables. The parts mattered, but so did the relationships between them.
You do not solve those problems by removing complexity. You organize it.
Human behaviour presents the same challenge.
Traditional economics assumed people made rational decisions. Psychology showed us they do not. We are influenced by habits, cognitive biases, uncertainty, mental shortcuts, and emotion. Behavioural economics emerged somewhere in the middle, explaining how people actually make decisions rather than how we wish they would.
Product design, in many ways, is applied behavioural economics.
A product does not simply present information and wait for a perfectly rational person to use it. Its structure affects what people notice, what they understand, where they hesitate, and which decisions feel possible.
The goal is not fewer buttons. It is fewer moments where someone has to stop and think, What am I supposed to do next?
This is why I think AI conversations often miss the point.
AI is an extraordinary computational capability. It can search, generate, classify, predict, and synthesize information at a scale no human can. But capability is not the same thing as intelligence.
To me, intelligence is making a hard problem feel easy.
That is true whether you are explaining a scientific theory, writing elegant code, or designing enterprise software. The intelligence is not in adding more. It is in recognizing what matters, organizing complexity, and helping others move through it with confidence.
The same applies to products.
AI can identify patterns, apply rules, generate recommendations, and act across more information than a person could process alone. AI can scale decisions. But it does not decide which decisions are worth scaling, what the system should prioritize, or what a useful outcome should feel like for the person using it.
That is still the designer’s work.
AI can scale decisions. But it does not decide which decisions are worth scaling.
The most challenging part of designing enterprise software has never been drawing screens. It is understanding how people think inside complex systems. Every workflow, permission, report, integration, exception, and business rule exists for a reason. The designer’s job is not to erase that complexity. It is to give it structure.
When a product feels intuitive, it usually is not because the problem was simple.
It is because someone did the hard work of organizing the complexity so you did not have to.
My work on Diagnostic Learning Analytics explores this idea in practice: not by removing complexity from reporting, but by organizing it around the questions people were actually trying to answer.