I've been doing this design thing for a long time. Long enough to remember when being a designer meant someone hired you to solve a problem, and you went off and, well, designed something. There was research, sketching, experimentation, and the occasional client who insisted their logo needed to be bigger. Some things never change.
But somewhere along the way, the process became a product unto itself. We started having workshops to prepare for workshops, creating frameworks to organize our frameworks, and documenting meetings about meetings. And we bought a staggering number of sticky notes. At some point, you have to wonder whether we're solving problems or just keeping 3M in business.
The Rise of Design Theater
Design thinking is a perfectly reasonable concept: understand the problem, explore solutions, test them, and improve what doesn't work. Good designers have been doing variations of this for decades, long before someone packaged it into a five-stage diagram suitable for a keynote presentation.
The trouble started when organizations discovered they could perform design thinking without necessarily doing much designing. Suddenly, every challenge required a workshop, every project needed a journey map, and every meeting involved colored dots and someone enthusiastically reminding everyone there were no bad ideas. There are bad ideas, by the way. Lots of them. Recognizing that is part of the job.
I've sat through enough workshops to recognize the pattern. A room full of intelligent people spends hours identifying problems that anyone familiar with the business could have explained in fifteen minutes. Those problems are written on sticky notes, arranged into clusters, photographed, digitized, and presented back to the same people who identified them. Someone declares "great alignment," while a designer quietly wonders when they'll be allowed to open Figma.
These exercises aren't inherently useless. But when they become mandatory rituals rather than tools chosen for a purpose, we're not practicing design thinking. We're performing design theater.
When Process Becomes the Deliverable
There's something comforting about process. It creates structure, gives people a sense of progress, and produces impressive artifacts for leadership. Here are our personas, empathy maps, and a beautifully illustrated diagram explaining why customers hate filling out a twelve-field registration form. Fantastic. Can we remove six of those fields now?
The uncomfortable truth is that process is easier to measure than good design. You can count workshops, interviews, and deliverables. It's harder to quantify an experienced designer recognizing a problem, sketching a solution, and validating it with actual users. One approach creates an impressive paper trail. The other creates progress.
Research and collaboration matter, but they should support the work rather than replace it. A journey map that never influences a decision is decoration. A persona nobody references after kickoff is fiction with a headshot. And a workshop that produces no meaningful change is just an expensive meeting with better office supplies.
Consensus Is Where Good Ideas Go to Die
One of the stranger developments in corporate design is the assumption that everyone needs to participate in every decision. Collaboration is valuable, but somewhere along the way, we started treating design expertise as just another opinion in the room.
A number of years ago, I was interviewing for a senior UX position with a logistics company in Kansas City. I'd already made it through two interviews and was feeling pretty good about my chances. Now I was sitting across from no fewer than six people, apparently the final hurdle.
Someone asked about my design philosophy and process. I explained that I preferred working roughly one sprint ahead of development, giving design enough room to explore solutions before developers started building. Nothing revolutionary.
That's when one of the developers explained that they didn't really have design tasks because everyone participated in the design process.
Fair enough. I'm all for collaboration. But I pointed out that somebody still had to do the actual design work. Call it whatever you like, but researching, sketching, prototyping, and refining an interface is still a design task. Renaming it doesn't make the work disappear.
I don't remember exactly what followed, but I remember the feeling. The temperature in the room seemed to drop a few degrees. I was fairly certain I wasn't getting the job, and frankly, I was fine with that.
Maybe I misunderstood their approach, but the exchange stuck with me. It captured something I've encountered repeatedly: organizations enthusiastically embracing collaborative design while struggling to recognize design as its own discipline, with its own expertise and responsibilities.
I've learned plenty from developers, marketers, and people who wouldn't know a wireframe from a waffle iron. Good ideas can come from anywhere. But involving everyone doesn't mean every opinion carries equal weight, nor does it eliminate the need for someone to own the work.
When every decision is workshopped, debated, and approved by committee, responsibility becomes conveniently distributed. The result is often a design that offends absolutely nobody and excites even fewer.
Sometimes the Answer Is Just Obvious
Not every problem requires a six-week discovery phase. Sometimes navigation is confusing because the navigation is confusing. Sometimes people can't find the checkout button because someone decided it would look more elegant if it were barely visible.
This isn't an argument against research. A complex healthcare application may require extensive discovery and validation. A twelve-page small business website probably doesn't need a three-day empathy workshop to determine that customers would appreciate finding the phone number. Knowing the difference is part of what experience brings to the table.
I've seen projects spend more time debating how something should work than it would have taken to build a prototype and let people try it. We can spend days discussing hypothetical behavior or a few hours gathering actual evidence. Yet speculation frequently wins because it fits so neatly into the calendar invite.
Less Theater. More Designing.
Experience teaches you to recognize patterns, anticipate problems, and know when your instincts are reliable and when you need more information. That judgment comes from years of making things, watching them succeed or fail, and occasionally discovering your brilliant idea was actually terrible. You can't manufacture it with colored dots or replace it with a framework.
Design thinking isn't the enemy. It's a useful approach that encourages empathy, experimentation, and collaboration. But a framework is a tool, not a religion. A room covered in sticky notes isn't evidence of innovation, and the number of workshops held has little bearing on whether anyone ends up with a better experience.
At some point, someone has to stop facilitating and start making things. Sketch something, build a prototype, put it in front of a real person, and see what happens. Learn from it, improve it, and repeat. The process should serve the outcome, not become the outcome.
And if we absolutely must have another workshop, could someone at least bring donuts?