Systems Thinking Changed How I Design Products
Early in my career, I measured my output in screens. Then I designed a beautiful solution that assumed a data model that didn't exist. That failure changed everything.
Early in my career, I measured my output in screens. A good week meant a polished Figma file with every state accounted for, pixel-perfect and ready for handoff. But as I grew into leadership, I realized the best design work often doesn't look like design at all.
The Failure That Changed My Thinking
It happened during a project at Keela where I was redesigning the transaction workflow. I'd designed what I thought was an elegant solution: cleaner UI, better hierarchy, smarter defaults. Then engineering started building, and we hit a wall: the design assumed a data model that didn't exist.
The screen was "right." The system it lived in made it impossible to build.
That failure taught me something I now consider fundamental: zoom out before you zoom in. Before I open Figma, I ask:
- What data flows into and out of this feature?
- What other features share the same data?
- What happens at 10× the current usage?
- Who else is building in this space, and how do our decisions compound?
- What organizational constraints shape what's actually shippable?
Maps Over Mockups
Since that project, I've started every major initiative with a system map — a visual representation of how data, users, and features relate. These maps are ugly. Whiteboard sketches and FigJam files full of arrows and question marks. But they surface hard questions early, when changing direction is cheap.
For the automation feature I later led at Keela, the system map revealed in week one that our notification system couldn't handle the event volume automations would generate. We caught a twelve-week problem in the first week. That's the value of thinking in systems.
What Changes at the Staff Level
Systems thinking is what separates senior designers from Staff designers. Senior designers solve the problem in front of them exceptionally well. Staff designers see how that problem connects to every other problem the product is trying to solve, then design solutions that improve the whole, not just one surface.
But it extends beyond the product:
- Organizational systems: How does team structure shape what gets built? Where do handoffs fail?
- Decision systems: How are priorities set? Where does design have (or lack) influence?
- Knowledge systems: How does the team learn? How do research insights reach decision-makers?
The designers I've mentored who made the biggest leaps in impact weren't the ones who leveled up their Figma craft. They were the ones who started seeing the systems around the pixels.
How to Practice This
For designers who want to develop systems thinking:
- Read the data model. You don't need to write SQL, but understanding how your product stores and relates data transforms your design instincts.
- Sit in engineering standups. Not to manage, but to learn. Engineers discuss trade-offs and dependencies that are a masterclass in systems thinking.
- Draw the arrows. Before any project, sketch the flow of data and actions through the system. The exercise matters more than the artifact.
- Ask "who else?" For every design decision, ask who else in the org is affected. Product, engineering, support, sales — design ripples outward.
- Build something end-to-end. A side project that goes from design to deployment gives you visceral understanding of the constraints your engineering partners navigate. It's why I still code.
The best design work I've done didn't look like design. It looked like asking the right question at the right time, in the right room, to the right people.