Getting back to Design basics
A few months ago, shortly before the pandemic shut down our world, I participated in two days of workshops with one of our product teams and I’m exhausted but not in the usual feel good, mission accomplished kind of way. I’m exhausted because we spent two day collaborating but never reached alignment or clear agreement on next steps. And I think our design vocabulary combined with corporate jargon is core to that failure. Words walled us off from one another. It muddied the path. All the hot air fogged the windows so we couldn’t see each other clearly from opposite sides of those steamed up windows.
When we planned these meetings, we agreed that face-to-face, in-person workshops would be most effective for collaboration and alignment-building. In hindsight there were troubled waters from the outset and so much of that turbulence comes from our obsession with buzzwords meant to make us each seem special, and better, in our own way. The design team’s goal was to identify clear user needs (or problems, or pain points – starting to see where this is going?). Or maybe we were focusing on customer needs or customer requests, also known as blackmail - if we can’t get feature X this calendar year, we’ll have to consider other vendors when the contract is up for renewal. Some of us wanted to discuss High Value Questions (HVQs), which might be similar to user needs (or problems or pain points) restated as questions?
On Day 1 of the workshops, we decided that the Jobs To Be Done (JTBD) framework would work best for these sessions and allow us to get all of the needs out on the table. We could then use those Jobs To Be Done to identify the underlying user needs which could then be converted into High Value Questions (HVQs). Those HVQs could then be prioritized with a 2x2 grid (or is it a rubric?) and converted into hypotheses that could be tested with experiments and validated/invalidated (or would that actually be falsified?). Now we’re using Lean UX. Cool. Unless it’s actually Lean Startup.
Each experiment would use an appropriate user research (UX/user/customer?) research method. Unless we’re doing a survey. Then we might need to bring in Market Research which no one likes because their questions tend toward a clear confirmation bias (If we build Amazing Product/Feature X and it solves all your problems, would you buy it? If yes, how much would you pay for it?). All of this would, of course, fit into our Scrum Agile cadence even though the designers will use a Kanban board to track their work.
If it isn’t clear yet, here’s why I’m exhausted. The team spent a week, including prep and post-workshop documentation time to build buzzword bullshit soup. We ended up with a list of customer demands, second-hand ‘Users Don’t Likes’ and a business wishlist written in a Jobs To Be Done format. We ran out of time to convert to HVQs that could be converted to hypotheses. We didn’t prioritize anything. Oh and we found out a couple days later that senior leadership decided to ignore the workshop outcomes and has prioritized the work based on an unbiased ;-) calculation.
So why did we fail so completely? There was no alignment on the meaning of words and frameworks, no agreement on the outcomes we needed by the end of Day 2. There were clear failures throughout the process and plenty of blame to go around but marketing-driven design vocabulary, business jargon and frameworks that sound great in a vacuum killed our ability to communicate. They bogged us down and prevented us from even truly getting started.
Anyone who knows me has heard me preach about the benefits and value of Lean UX and human-centered design for years but maybe all of that noise is hurting more than helping. I’ve honestly had enough and I’m going to try something different. I’m going to shut down my own jargon machine in exchange for straight talk and clear language. As a Designer leader, I am going to:
Help the people on my team (Product Managers, Engineers, Designers, Project and Program Mangers) better understand the people for whom we design and the people who buy those things that we create.
Help the team learn about those people by talking to them directly and regularly. Ideally, when the time is right, we’ll meet them in person where they work, on the phone, or even in a coffee shop.
We’ll ask them questions about what they do so we understand their jobs better. And so that we might see where the things we make don’t work for them. Or maybe we’ll see them do something they didn’t even realize they were doing – a shortcut or a workaround.
The goal is simple. To learn. To learn what we don’t know. To learn where our solutions went wrong. To learn where we made things harder instead of easier. To learn what those people really need to do their job better.
I will help my teams do all of that so that we can design better things that help people do better, work better, and be more satisfied in their work.
Simple. Really.
