The coffee machine set to go off at 5:10 AM, exactly when my alarm would normally go off. I stayed in bed for five more minutes—a small victory in my ongoing battle with mornings.
The psychological trick worked brilliantly: instead of dreading the alarm, I now associated morning wake-up with the promise of that first perfect sip of coffee waiting for me. The thought of my favorite drink made early mornings not just bearable but something I (almost) looked forward to.
As an architect and problem solver by trade, I felt pretty smug about this simple solution. Set the coffee maker to start at alarm time, swap the negative emotion of waking up with the positive anticipation of coffee, and the temptation to hit snooze magically diminishes. Problem solved, right?
Then a colleague said something that stopped me in my tracks: “It is better to be a Systems Thinking person than a Design Thinking person.”
Wait—what? As someone who teaches design students and prides myself on creative problem-solving, this statement bothered me.
Isn’t coming up with ingenious solutions precisely what makes someone valuable in any profession? Even job listings consistently rank problem-solving as a top qualification. How could this not be the ultimate professional skill?
Turns out, I’d been asking the wrong question all along.
What Are Design and Systems Thinking?
As I researched these approaches, I discovered they operate almost as opposites:
Design Thinking
- Individualistic focus
- Creation-oriented
- Execution-driven
- Narrow focus
- Problem-solving
Systems Thinking:
- Pattern/group focus
- Analysis-oriented
- Planning-driven
- Wide consideration
- Problem-finding
I immediately recognized myself in the Design Thinking column. I value focus and execution. But that last contrast—problem-solving versus problem-finding—nagged at me.
When Finding Beats Solving
I once helped a client who wanted to combine two separate buildings to house all employees under one roof. My architect brain immediately started calculating costs and sketching connecting structures. Classic problem-solving mode activated.
The financial reality was stark: joining the buildings would solve his “one building” vision but create an enormous financial burden. The client was caught between wanting unity for his team and managing a reasonable budget.
But after several conversations, I realized his actual concern wasn’t about physical workspace but employee morale. He wanted people to feel connected, not necessarily have to work in the same space.
The lightbulb moment came on. Instead of an expensive building merger, I suggested a rooftop connection between the structures where everyone could gather for special functions and lunch meetings. This solution addressed the real need (employee connection) at a fraction of the cost of a full building combination.
I’d always considered this my problem-solving triumph. Now I wonder if I was actually practicing Systems Thinking—finding the real problem before rushing to solve the apparent one.
My closet dilemma
This distinction hits home every spring cleaning season when I face my disorganized closet.
For years, my approach was purely solution-focused; buy more shelves, discover better folding techniques, and find ways to jam more stuff into the same space. I was solving the organization problem.
But this year, staring at my jam-packed closet (including that lime green mini skirt I bought at an “amazing discount”), I realized I’d been addressing the wrong problem.
The issue wasn’t insufficient organization—it was excessive stuff.
The real solution wasn’t better organizing methods but decluttering clothes I don’t wear. By finding the actual problem (too many clothes), I eliminated the need to solve the perceived one (not enough space).
The Common Thread: Experience and Iteration
While these approaches seem contradictory, they share one crucial element: both require iteration.
In architecture, we joke that design work is finished when you run out of time.
Both problem-solving (figuring out how to expand a building on budget) and problem-finding (questioning whether expansion is actually necessary) improve with experience.
Without going through cycles of trial, error, and refinement, we can’t develop confidence in either approach.
The process matters as much as the framework.
Final Thoughts: Finding Before Solving
I’ve come to realize that solving problems isn’t the ultimate skill—finding the right problems is.
Before diving into solutions, we need to ask: “Is this actually the problem I should be solving?” Without this question, we risk wasting time on unnecessary or entirely wrong problems.
The best approach isn’t Design Thinking versus Systems Thinking, but rather both in sequence: first find, then solve.
As I look once again at that unworn lime green mini skirt taking up space in my closet, I remind myself that lime green is bound to be “color of the year” eventually—it’s been over a decade, after all. Maybe that’s just another problem I’m not ready to find yet.
What problems might you be solving without first making sure they’re the right ones?
Life Outside of Design Studio 