Thinking versus doing

Thinking versus doing is a constant balancing act for me.

I got a bachelor’s degree in psychology before I went to design school – at that point, I could have applied for masters’ programs, but instead I intentionally applied for undergraduate design programs because I wanted to hone my craft rather than focus mostly on theory. When I was starting in my second undergraduate degree in design, I talked with my advisor about whether I should switch to the masters’ program. Her answer was a simple “no”. There may have been some other motives at play, but I think the rigorous focus on craft that the undergraduate program offered truly drove her response.

Later in my career, I’ve focused more on the underlying building blocks behind good design: a sustainable business model, culture, solving the right problems, teamwork and process. If I’m only focused on craft and ignoring these things, it can be like pushing against a strong headwind. If I design the feature someone asked for rather than stepping back to ask why that feature is important, I won’t really solve the problem.

Culture eats strategy for breakfast.

Peter Drucker

But also digging deep can have diminishing returns and cost valuable time. One place I’ve worked had job descriptions that said something to the effect of “don’t overthink it – it’s just a website.” Of course, the ethos of both design thinking and agile software development is about prototyping and testing or launching something, learning from it, and adjusting. Part of this drive to get something out there can be a forcing factor to stay out of rabbit holes. Once I was sketching a project in an industrial design class, and a professor came around and said, “sketch out here” while waving his hands in three-dimensional space. Prototyping with the materials got me and the rest of my classmates to learn what wasn’t going to work.

How do I know I’m getting the balance right? This is where I wish I had some pithy insight to share, but honestly, usually it isn’t clear until I look back with a team in retrospect. And then it’s a gut feeling of “we should have thought this through / stepped back more” or “we should have done more iterations and moved ahead more quickly” based on how things turned out. This is design thinking at a meta level.