This post is #6 in a series of posts about my UX research about UX Maturity. For all other posts, see my UX Strategy page.
The double diamond
The double diamond is a great model for the design process. This Kayla Heffernan blog post describes it in more detail, but it boils down to two phases:
- First you figure out which problem to solve,
- then you solve it.
In both phases, you first diverge (go broad), then converge (go deep). Hence the diamond shape!
My UX career has really focused on the second diamond (solving problems) as opposed to the first (figuring out which problems to solve). Which is why I’ve focused my work so far on the first diamond (figuring out which problem to solve). It is so valuable to take the time to understand the problem space before diving in and exploring solutions.
Before I jump into the second diamond (fixing the problem), I’m taking the time to recap my progress so far.
My hunt statement
So where did I start this first diamond? With the following hunt statement, which I carefully crafted when I started this research earlier this year.
I want to learn how decision-makers at enterprise software companies understand what UX design is, and how it fits into the success of their business;
So that I might develop more effective approaches for increasing investment in UX and getting the company to move further along the scale of UX maturity.
As I reread this statement, I’m almost embarrassed by it. But that’s a good thing.
“If you’re not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman (source)
The fact that I cringe as I read that means that I’ve learned something since I wrote it!
UX growth doesn’t just come from decision makers
Firstly, I really didn’t focus my research on decision makers. I did have formal interviews with one CEO and a couple of managers, but I balanced that with several chats with “worker bees” like myself.
I did this because as I wrote about in The Three ITs of UX Growth, average employees don’t have to waIT for decision makers to force UX growth; they can commIT to UX growth themselves!
Increasing investment may not be the right choice
Fred Brooks said way back in 1975 that doubling the number of programmers on a development team does not double the speed of that team.
The same goes for designers. As one designer who I spoke with put it:
“We don’t need more funding. We need different funding”
Marcos Lopez, CEO of Solium, put it nicely during my talk with him:
“Things work when they’re not forced… organically start to say this is how we build things.”
Increasing investment isn’t just unnecessary for UX growth, but it might actually be a hindrance. I’ve heard stories of multiple conflicting design systems being developed in parallel by different design teams in the same company. That might not have happened if there were fewer resources available and the team had to run a little more ‘lean’.
There’s more than just one “scale”
As you can see in my UX Maturity Models summary, there are dozens of different “scales” for measuring UX growth, so it’s a little ambiguous to say “move along the scale of UX maturity”. Which scale?!
I niched down
I didn’t end up looking at a broad sample of enterprise software companies. Most people who I spoke with were with “mid-maturity” software companies, meaning companies where UX was accepted and encouraged, but where UX was not involved in the overall strategic direction of the company.
This wasn’t really on purpose but was a bit of a happy accident because I ended up seeing a lot of similarities between the companies that I spoke with.
So what did I do to address that hunt statement? I did both primary and secondary research.
Armed with tips from Steve Portigal’s great book Interviewing Users, I conducted seven different formal interviews and dug up notes from two recent informal conversations about UX maturity. In these 20-45 minute chats I asked questions including
- (Show a summary of Neilsen’s 8-stage UX maturity model) Where on this scale is your company? How about when you first started there? If it has changed, why?
- What would you like to change about UX at your company?
- Other than Development, which departments should UX collaborate with?
I then summarized all notes in one big spreadsheet then did two rounds of Research synthesis to pull out themes and patterns from these talks. Below is an image of one of those synthesis sessions.
There is a lot of work that has already been published on UX growth. Reading that work is what’s called secondary research.
In addition to collecting and analyzing different UX Maturity Models, I read several case studies, including this paper on Applications of Maturity Models and this UXmatters article on IBM. I also read the very actionable book UX Revolution by Paul Boag.
These sources were great for giving me a broader view of the problem space and provided a bit of a sanity check of my own research.
I also recently spoke about my ideas. Signing up for a ten-minute talk at a UX meetup forced me to really distill my thoughts down into something simple (see The Three ITs of UX Growth) and also gave me a few insights and introductions from the audience!
The grand-daddy problem
After clustering and analyzing my notes from this research, the main problem I’ve found is that even with a shared vision, UX growth can be stunted by the lack of a shared “how”. To encourage UX growth, we need to change the default “how”.
Even with a shared vision, UX growth can be stunted by the lack of a shared “how”; to encourage UX growth, we need to change the default “how”
To solve this problem, I’m going to keep in mind the following constraints, which were also based on my research:
- Do TWICE as much with HALF the resources
- Don’t do more; do it differently
- Can’t sacrifice speed
- They’ll think it was their idea (INCEPTION)
- Change can’t be forced
- Should happen organically
- From ANY team to ANY team
- UX might be a pot calling the kettle black
- UX needs to be more self-aware
Specific design prompts
I summarized my findings into three possible design prompts.
Firstly, how might we clearly trigger when one team should involve another team?
Software development can be a messy, disjointed process, which makes it hard to join in and act as a team. It can also be hard to know when the design team should be involved (or when the design team should get help from other teams.
Next, how might we improve the design of products without slowing things down? Design needs to be able to jump in without delaying projects.
Lastly, how might we incentivize teams to be fast and produce well-designed solutions? We need to incentivize the right process as opposed to speed only. The design team must be able to keep pace.
While each of these prompts has tons of potential, I decided to focus on option 3 for the sake of time:
How might we incentivize teams to be fast and produce well-designed solutions?
Yes, more research. My research thus far has only scraped the surface of how teams are incentivized. So before jumping into fixing the problem, I have to loop back to that first diamond to get a little deeper understanding of it.
I love this part. Quantity over quantity. I’ll be sketching at least 25 different ideas for addressing this design prompt. After that, I’ll work with my mentor Meaghan to evaluate the ideas and iterate on them. Eventually, I’ll further explore some of the better ideas. Stay tuned!
So far, this research has been great. It’s always fascinated and frustrated me that for some people and some companies, UX just seems so obvious, whereas for others, users are seen as annoyances. I’ve enjoyed sinking my teeth into this puzzle while learning about research.
Even though the mentorship program that prompted me to start this project ends next month, I could see myself exploring this problem space for years to come.