Are your design ideas bad?

publishedabout 1 year ago
3 min read

Dear Reader,

Today's advice is on a very personal question:

Q: What if people say my idea is bad?

"I don't think that's a good idea," says the project manager, dismissing your work with a wave of her hand.

You suspect she's only saying the idea is bad so that she can hit her project deadlines. But it's her opinion against yours.

You know you shouldn't take it personally, but you do.

Your body reacts for you as a tear forms in the bottom of your eye.

Remind yourself of this:

  • Feedback on screens isn't feedback on people.
  • Stakeholders don't determine the goodness of an idea...that is up to the user.
  • Ideas themselves aren't "good" or "bad." They're bets on human behavior.

When we make bets on human behavior, we're often wrong. There have been studies that show most ideas are bad.

72% of new products and services fail. (Kucher 2014)

If most ideas will fail, how do you know which ones will succeed?

It's impossible to predict the future, but it is possible to de-risk an idea.

Today, I want to talk about a culture of experimentation that can help you avoid personal judgments of ideas on your team.

It's a way to do user-centered idea evaluation.

1.) Challenge assumptions, not ideas.

An assumption is something that you accept as true without question or proof. (Cambridge Dictionary)

Instead of arguing about which idea to build, find assumptions hidden within the idea. It's the assumptions that will kill an idea so find them.

Try these questions on stakeholders:

Q: Are we making assumptions that could cause this idea to fail?

Q: What's the riskiest assumption here? How sure are we that this assumption is true? 10%? 90%?

Q: What would it take to test this assumption?

Questions like this help us see the risk in our ideas. It helps avoid a binary "right" or "wrong" mentality.

It's less combative to talk about assumptions rather than ideas.

If you take it personally when your ideas get shot down, the CEO does, too. Listen for the difference in these two examples.

Example without assumptions:
"Hey CEO, can we test your idea to see if it's good or not?"

Example with assumptions:
"Hey CEO, can we run some tests on the riskiest assumptions in your idea?"

Hear the difference?

2.) Seek evidence for risky assumptions

Assumption Maps are a great place to think about the priority and evidence of assumptions.

If we have an important idea without much evidence, it’s good to find evidence before you build anything.

You might realize you have pretty weak evidence on most of your ideas.

That's where a product experiment like a concept test or a hypothesis-driven design prototype could help.

People sometimes call this approach “data-driven,” “lean,” or “experimental,” but those words don’t do the concept justice.

It's a way to reduce bias and judge ideas objectively with small, scrappy, user-centered evaluations.

You don't need to be a data scientist to design based on user data.

If it’s early in the product design process, an experiment might look like an interview, a card sort, or a survey.

Once you know how to set up a proper experiment, you can stop relying on subjective feelings and let customer behavior decide.

3.) Process every idea

I've noticed that when ideas come from the intern or the junior, they're assumed to be bad and shot down immediately.

But if they come from a CEO or a VP, we grumble and build them anyway.

That's a problem.

It's a problem because users don't care who has the idea. They only want it to work for their lives.

A process is how you save good ideas and ensure you're not biased.

In my career, I've designed dozens of features that were a "good idea" for the company, but the customer didn't find them desirable.

We were so clueless that we didn't even know they were unwanted features until we checked the analytics months after launch. Checking the analytics is a pretty slow, blunt way to check if users like an idea.

You need a process for testing ideas as they come. And instinct or salary is not a good test.

Here's what a process could look like:

  1. Pull out assumptions on the idea
  2. Prioritize the assumptions
  3. Research & experiment on assumptions with weak evidence
  4. Glean insights from the research
  5. Integrate your learnings into the idea
  6. Design the MVP (ideally, this is also an experiment)
  7. Keep iterating and de-risking

A process like this flattens the org and encourages learning from the customer.

And I think that can be a pretty good thing for you.

If ideas evolve from research and experiments, they become something more than "your idea."

They become user-centered ideas.

Learn More

Read this guide on testing assumptions→

Watch this masterclass on assumption testing→​

Take a free course on product experiments→

Until next week!

Jeff Humble
Designer & Co-Founder
The Fountain Institute

P.S. We just announced the next LIVE masterclass: How to Lead with Facilitation. Here's the poster:

The Fountain Institute

The Fountain Institute is an independent online school that teaches advanced UX & product skills.

Read more from The Fountain Institute