This post is #7 in a series of posts about my UX research about UX Maturity. For all other posts, see my UX Strategy page.
Last week I wrote a long post summarizing my progress so far. At the end, I discussed some of my constraints, including the following:
Do TWICE as much with HALF the resources
- Don’t do more; do it differently
- Can’t sacrifice speed
Which came from numerous quotes in my research, such as:
- “We [designers] slow things down because we think about them longer. “
- “Can’t slow down velocity on getting features done”
- “Product owners need to demonstrate progress. If feels like we’re interfering with their status updates. “
But now I’m starting to have my doubts.
Maybe you can sacrifice speed
I recently realized that while it would be great to speed up design, that might not be the best approach to increasing an organization’s UX maturity.
The reality is that good design does slow things down.
But isn’t it better to walk in the right direction than to run in the wrong direction?
Yes, well-designed solutions take longer than just getting features done, but they make your users happy, they are less buggy, more maintainable and extensible, and they differentiate you from your competitors.
My research was focused on mid-maturity companies, where people told me that design has to be fast. But I’m now learning that high-maturity companies don’t think that way. As UX Designer Barbara Shain told me about a past employer:
“There isn’t just a perception that design slows down development– we all accept it as a fact.”
In other words, yes UX is slow, but no that’s not a problem.
But speed is still important
As I was writing this post, I decided to look up some transcripts of the podcast that first introduced me to User Research 3 years ago: Dollars to Donuts. Turns out that many of the mature companies featured in this podcast do still have speed pressures.
I think if we double the size of the research team, I’m not sure that would be in the best interest of the company. I think that might actually slow things down.
[The research team] got our foot in the door with some product teams and showed what kind of impact we could have and how… rapidly we could do this work… How it could speed up development in some cases.
But again, speed isn’t everything.
You can go too fast if you skip especially those early important steps of focusing on ‘Okay, let’s clarify, what are we doing?’ … if you cut the wrong corners, there’s a “gotcha” at the end.
Like many things in life, this is a very delicate balancing act.
What do I do now?
I’m so confused. But that’s normal in research.
Going forward, I’ll continue exploring ways to incentivize teams to care about design while keeping up the speed. However, I’ll also look into ways of embracing the slowness!