Systems, Not Screens

The career ladder I wrote at BentoBox in week six of my tenure was probably the highest-leverage design work I did in that role. It retained 100% of the design team through a $320M acquisition. It does not fit in a Dribbble shot.

The controlled migration protocol I designed at Verizon let us route traffic from 5% to 100% over six months without taking a $14B revenue channel down once. It does not have a hero image.

The decision to reframe onboarding cycle time as an academic outcome metric at Ignite Reading changed how an entire company prioritized its roadmap. It was not a wireframe.

The screen trap

Designers are trained to think in screens because screens are what we deliver. But screens are artifacts of thinking, not the thinking itself. The most senior design work happens at the layer above the screen: the system layer.

A system is the set of rules, relationships, and constraints that determine how a product behaves. Information architecture is a system. A design language is a system. A career ladder is a system. A migration protocol is a system. A pricing model is a system.

When you design at the system layer, the screens take care of themselves. When you design at the screen layer, you are perpetually reacting to system-level problems you cannot see.

What changes when you think in systems

You stop asking "what should this page look like?" and start asking "what decision does this page need to support, and what information does the user need to make that decision?" The layout becomes obvious once you answer the real question.

You stop designing features in isolation and start mapping how each feature affects every other feature. At BentoBox, restaurant operators were using one or two modules out of six because each module had its own mental model. Collapsing them into a workflow-first information architecture drove a 484% increase in multi-feature adoption. That was a system change, not a UI change.

You start seeing organizational design as product design. The team structure, the decision-making process, the communication patterns — these are all systems that directly shape the product. A team organized by module will produce a product that feels modular. A team organized by workflow will produce a product that feels integrated.

The portfolio problem

This creates a real tension for designers building portfolios. The most impactful work is often the hardest to show. A career framework is not a wireframe. A migration protocol is not a mockup. A pricing transparency decision is not a prototype.

But the ability to articulate system-level thinking is exactly what separates senior designers from mid-level ones in every interview I have conducted or participated in. The question is never "show me a beautiful screen." It is "tell me about a decision you made that changed how the product worked, not just how it looked."

If your portfolio only shows screens, you are signaling that you only think in screens. The work behind the work is the work.