Aspirologies™ is my term for trendy methodologies that aspire to greatness but miss the mark or actively hurt processes, teams or product. Calling these methodologies lends undeserved credibility. Typically, they aim to reduce or reassign specialized CX/UX tasks and work to non-CX/UX roles or sometimes an entire team working by committee.
Aspirologies are often ego-based or emotional, which leads to non-CX/UX people expressing a desire to design solutions. Yet if someone in marketing were interested in DevOps, you wouldn’t make them a Kubernetes Cluster Administrator.
We most often see aspirologies at work in design thinking, design sprints, “Lean UX,” Lightning Decision Jams, and other methods focused on team design or product workshops. No matter what you name them, design workshops are killing your design. How did companies devolve from investing weeks or months in “Research and Development” to solve serious problems — to only needing a few days with the current team? Does it make sense that the bigger the problem, the less time we should devote to it or the fewer domain experts we should involve in the work?
The Most Common Design Workshop Myths
'Workshops Create Innovation!'
If innovation came from getting a bunch of people sketching in a meeting room, there would be endless innovations weekly at every company. We’d lock teams in virtual or office conference rooms for a week at a time, week after week, and churn out those innovations. Since this is rarely happening, design sprints and similar exercises are innovation theater.
When our customers struggle with our products, they are not thinking, “I wish this was more innovative.” They’re probably thinking, “Who designed this?” There’s nothing wrong with focusing on non-innovative fixes and features. We have not failed if we never innovated.
Related Article: Innovation Can Be Taught. And Measured
Calculating Workshop ROI
Here is how to calculate what your design workshop truly cost the company:
- Cost of workshop hours or days (salaries, facilitator(s), venue, catering, supplies, etc.).
- Plus time spent after the workshop working on the “winning” concept. Calculate or estimate CX/UX, product, BAs, engineers, security, marketing and other people working on getting this out to the public.
- Plus time spent after it was released to support or sell it. Calculate or estimate customer support, social media managers, marketing, and sales dealing with any positive or negative repercussions of this product or feature being publicly available.
- Plus work needed after release. Calculate or estimate CX/UX, product, BAs, engineers, security, marketing, and more working on fixing, removing, or improving this product or feature.
If the idea died, failed or didn’t move forward at any point in the above process, note why. It’s important to see what we’re spending on workshops and where their outputs stall.
That is what the workshop cost you. Compare that to the money the concept made.
Related Article: How to Ensure Your Product Roadmap Embraces Facts, Not Fallacy
'Design Sprints, Design Thinking and Workshops Really Work!'
Define “work.” If your 10-year-old cousin builds your company a website, that website might work. It might even be better than your old website. Version or process “B” being better than “A” doesn’t mean that we’ve found what works best and we should stop trying new things.
There’s a lot at stake. Workshops are so hot that nobody wants to say, “Wow, $50,000 on design thinking this week, and it was meaningless.” Nobody wants to look back at a $200,000 project and realize it was chasing a bad idea. We can’t cherry pick a few winning examples if we’re burning time, money and customer trust on cycles of publicly-released guesses.
Workshops are “protected” by focusing on emotional and intangible outcomes like:
- “We found opportunities for fundamental product changes aiming at our less sophisticated customers.” Why was this company previously ignoring less sophisticated customers? CX/UX would know that customer segment wasn’t “an edge case.”
- “We learned a lot about which of our users wanted more customization.” Are you sure? Was that the answer to, “Would you like more customization?” (a flawed question), or was that an insight from expertly-executed observational research?
- “We had a solid foundation for a tool that would fill one of the company’s most glaring functional gaps.” What’s going on in this company that you missed a glaring functional gap? For how long was this left unaddressed? Why aren’t the right people and processes in place to recognize and act on this way earlier?
- “We had camaraderie with co-workers and appreciated each other’s points of view.” Highly emotional, and is designed to make it hard to calculate ROI.
Related Article: Design Thinking Isn't User Experience
But, But, But … Team Building!
Aspirologies are sold as great ways to do team building. However:
- If team building is best done in workshops, where are all the workshops being run by marketing, product, scrum masters, project managers, developers and QA testers? They all have work we could turn into workshops, yet we’ve been invited to zero day-long or multi-day team workshops in those domains. Using team building as a reason is a lie. If this is how we build teams, we’d do it in all areas and domains at our company, not just CX/UX or design.
- Articles about team building in The New York Times, Forbes, Harvard Business Review and Entrepreneur.com do not suggest workshops for team building. Team building advice included: get to know each other, understand what each role does, value and respect those roles, lay groundwork for work styles and deadlines, improve communication, set measurable team goals, celebrate successes with awards and recognition, and talk about failures and where things could improve.
If you understand what the CX or UX roles do, and you value and respect CX and UX, you will stop holding team design exercises and workshops. This means no design sprints, no co-design working sessions, no group design thinking craft exercises. How will you get ideas from other people? There is collaboration without design by committee.
Workshops Are Lean Waste We Could Cut
A week-long design sprint, various design thinking exercises, and mountains of “Lean UX” everything-by-committee meetings take your co-workers away from their other work, sometimes for days.
Frequent team meetings and exercises disrespect other roles’ velocity, productivity and efficiency. When CX/UX requires a steady diet of “do it by committee” meetings, we appear incompetent, in need of everybody to do our job with or for us. Every workshop we hold or facilitate teaches our teammates how little they need us. They might eventually wonder if anybody can do this work, why can’t anybody facilitate the meetings? Who really needs CX/UX specialists? That’s a slippery slope for our profession.
Mitigating Risk or Creating Risk?
While CX/UX expertise is misunderstood, ignored or never hired in the first place, companies dream of other ways to design products. Established companies with CX, UX and product teams follow advice from books that were written for startups that have nobody working in CX, UX or product. This is broken.
The day-to-day job of CX/UX experts does not require a special workshop or exercise. They mitigate risk — reactively, proactively and predictively. They identify opportunities to fundamentally change PSE. Drop the design workshops, and you’ll find you’re Leaner and more Agile when you let qualified experts perform the tasks and make the decisions in their domain’s realm.
Learn how you can join our contributor community.