Story From the Frontlines: Don't Call My Baby Ugly

Audio Version

Here's an audio version of the article:

Story From the Frontlines Dont Call My Baby Ugly

0:00

/496.087506

1×

What is This?

Stories from the front lines are anecdotes about how to apply ProblemOps in real life scenarios. Hear different examples from different authors sharing how they've lived ProblemOps in the world.

How it Started

Work environments can have cultures of positivity. People talk about the positives “publicly”, and the negatives “privately”. This is meant to keep up the morale, or the appearance of forward movement. And in those environments, you have to be careful about the Language of Change you describe. People may misrepresent issues with an overwhelming “positive spin”. They may not want you to say the word "Problem".

One can only guess why this happens. People could be afraid of the judgment they project on themselves or the business. People could see problems as negative.

It's hard to navigate this as a person who's been trained to problem-solve. UX and product management people "solve problems". We don't look at problems as negatives. We look at them as opportunities for better experiences. And now we get back to the essence of ProblemOps: words.

Words words words! It's all words. It's all about the meaning of the words. "Problem" may mean something negative to some people based on their lived experience. It may be exciting to others (like UX people). When two people say "problem" and one reacts negatively, it's time to build a shared language.

Stop pushing "problem-first" mentalities. Start focusing on "What's happening today that you want to change?" and "What are the outcomes we want to achieve?". This can be hard for teams. There may be glaring underlying issues or assumptions that no one is addressing. The business takes a stance that you shouldn’t “call my baby (the product) ugly”.

Remember the principles of ProblemOps: everyone can get on the same page around common outcomes. Define the common outcome and then measure change.

But! If you use language that people avoid, you will not make allies. You will likely create more rift while working with humans.

UX people are trained to problem-solve. We live in the world of problems. How can we not “call the baby ugly?”

The "ugly baby" IS our work focus.

I was working on a team where business leadership wanted to only hear about the good things in presentations. And there we were, faced with complete misunderstandings about what words we said and why we were saying them. They certainly did not want us to “call their baby ugly” when we pointed out glaring experience issues.

One time we got reprimanded when we publicly presented usability data.

Here's how it went, and what I learned about building influence.

How It Proceeded

The business was on its second launch. The first one didn't go so well. Teams moved forward with something for two years, only to start over. Our team, the UX team, joined in this mission later in the second project. This was the first time the team was getting involved with such large work efforts. The goal was to combine a lot of different systems into new ways of work. To innovate for the future.

The UX team addressed underlying problems through analytics. We used a metric called "rage clicks", where users reacted to poor experiences in the product by clicking hard.

We started working with product teams to address the issues, and quickly faced resistance. People were defensive. "Don't call my baby ugly!" We pushed harder for "problem-solving". We focused on "stopping the rage clicks". Teams stopped bringing us into conversations.

I noticed a pattern. People on other teams saw our team as the "dreamers" who weren't focused on reality. We talked about nothing but the problems or exploring potential problems. They, as product leaders, talked about nothing but delivering the work within release timelines. In hindsight I think our team fought the wrong battles. We were advocating for user-centered design when the business wanted progress.

And here's the thing: UX people can progress quickly and identify problems quickly. The one key issue was we didn't build the Language of Change. We could have been speaking the language of "progress" and not "problems".

So there we were, struggling to work with people, talking about "changing the rage clicks", and struggling to build allies. One day, the leader of this effort wanted  us to present current analytics of software.

Our team presented the problems in the systems today according to analytics. We showed them the rate of "rage clicks". They stopped us in the middle of the presentation.

"What do you mean, 'rage clicks'?"

We explained what the metric meant. It was pretty clear that they were reacting negatively to the word "Rage". At the time, our team had trouble seeing what the leader saw.

Our first reaction to rage clicks was "Better experience on the way".

Their first reaction to rage clicks was "People are angry? What does that mean for my job? I'm going to be in so much trouble. They better stop saying 'rage clicks' around my boss."

So we got reprimanded. "You called my baby ugly in front of others!" they basically told our team. We were told never to "call the baby ugly" again.

The team put in a lot of work and nothing was going to change.

We felt defeated. We had worked hard on those recommendations. Rather than stick with our own perspective, we changed our approach.

We started to define the outcomes the business want to achieve. We connected all metrics to business outcomes. We changed the word "Problem", and we changed the word "Rage". We waited for the right opportunities to measure change. Sometimes this meant proceeding with the positivity talk. Sometimes we waited to address usability issues. We quietly worked to progress and show results.

How To NOT Call An Ugly Baby "Ugly"

Here's how to avoid calling an "ugly baby" "ugly". We had a formula: 

1. Build a shared language
2. Acknowledge the positives
3. Collect business outcomes
4. Measure results
5. Present the positives aligned to outcomes 
6. Present the opportunities aligned to outcomes 
7. Recommend next steps

This worked far better than calling their baby “ugly”. The business listened. We spoke in terms we both understood. We didn’t use the words “usability” or “UX”. We communicated how to fill the gaps and achieve the outcomes when the time was right. Most importantly, we waited. Waited for the right moment to bring up opportunities. Until then, we built trust by listening and understanding the business perspective. We operated in support. We sought to understand, not to be understood. Our products improved more. Our cohesion grew with other teams. 

But it didn’t happen on the timeline that the UX team wanted. It happened at the speed of alignment across all departments. 

The Moral of the Story

1. Learn how to speak others' language. If we come into the room speaking our own language, we create misunderstanding. We shouldn't be worried about how others understand us. We need to understand others. What really matters is that people work alongside us in the change. If we make change alone it's bound to end in a poor result.
2. Don’t call the business’s “baby” ugly. We all have to build trust with each other who have a stake in the outcome. You can lose trust quickly when decisions are challenged. It’s best not to start with issues you find from research before you can be sure people will hear them. Learn how to speak the stakeholders' language. Recommend opportunities and the evidence that leads you to that thought. Use their terms.
3. Influence comes after other people are willing to listen. To do this, you need to ensure you build trust with others first. Show them results. Don't talk about plans. Help them see what happens. Help them make conclusions on their own terms. 
4. Problem-solving can be performed without calling it “problems”. ProblemOps specialists don't always call it "Problem". Nor should we. We must align in the current state and goals with the Language of Change. Beyond that, words matter less.