How To Know Which Ideas Suck

As a general principle, there are two ways you can brainstorm ideas, and it all depends on where you start: with possibilities or limitations. However, one of those methods will often lead you down the wrong path, and the other prevents that risk.


When it comes to “creativity” most people tend to start with inspiration and work toward something useful. 

Anyone who has a process that starts with “inspiration”… isn’t actually solving problems. Not very often, anyway.

One curious thing you will notice if you talk to a lot of experienced designers (in any type of design) is that most of them don’t start with inspiration. In fact, they kind of hate working like that.

Instead, they seem to love limitations.

As an inexperienced designer, this might seem like the worst thing ever. 

Doesn’t that, like, kill all the cool ideas, man?

Yes. Yes it does. And that is exactly why the experienced designers like to start there.


Limitations RAISE your standards by KILLING weak ideas.

The funny thing with “inspiration” is that it only has to achieve one thing: it has to inspire you.

It doesn’t have to make users more effective.

It doesn’t have to make money.

It doesn’t have to win the A/B test. 

… it doesn’t even have to inspire anyone else! Just you.

Last time I checked it was called UX, not YouX. 

On the other hand, limitations define the “minimum quality” that will “work” in your situation. And as soon as you do that, a lot of your ideas suddenly don’t qualify as “good” anymore.

That’s valuable.

Therefore, adding limitations raises the level of what you can consider “good”.


To find your first requirements: start with a problem, not an idea.

Many companies are obsessed with “ideas” but — oddly enough — that is not a very productive mindset. You should be obsessed with problems.

When you work with products and things that people have to use, the best place to start is often by defining the problem you’re trying to solve. That isn’t always easy — but it’s always valuable.

Why? Because problems have built-in requirements. If your solution doesn’t solve the problem, you ain’t done shit. And that makes you smarter during the brainstorming part.

When you understand the problem well, you can brainstorm a lot of different ways to solve that problem, and by default — since they all solve the damn thing — you’re only talking about productive ideas. 

All the ideas that don’t solve the problem aren’t even part of the conversation. That’s good!

For example, let’s say you have a restaurant with a long waiting line, but not in a good way. It’s too long. You don’t have room for the people, and they are annoyed. You need a way to reduce the length of the line, and make it less annoying to wait. Hmmm… tricky problem.

You sit down with your team to brainstorm some possible solutions.

Maybe you can have a big guy outside who only lets people in when there is room for more. Maybe you can use a “take a number” system. Maybe you can add two hosts so guests can be seated faster. Maybe you can make people eat faster, by serving smaller portions or by collecting payments faster. Or maybe you can give people one of those “buzzer” things so they know when their table is ready.

On the surface, all of those might seem reasonable enough. Your team really likes the “two hosts” idea, since they would get to work together which is more fun. (The idea that is best for the team is often the favorite in UX design too, careful!) 

If you just stopped there, their favorite idea would win and you would start having two hosts. But how do you know if that is really the best idea?


Add limitations!

Wait, what?! Doesn’t that make it harder?!


That’s exactly why it works. By making it harder to meet all the requirements of the problem, you will start understanding which solutions have the most value.

And we’re not just adding random details… we are adding requirements that would be “even better” than “just” solving the problem. Ask yourself: what would the “perfect” solution look like in real life? What’s the dream scenario?

For example… in this case, your kitchen is already working at full capacity, so serving more customers is not reasonable. That’s a good requirement.

You do a bit of research and learn that customers are not ok with paying the same price for less food, and you can’t afford to charge less, so that’s a new requirement. (See how “solving” a long line could have caused you to lose money if you didn’t do research?! Ideas can be dangerous!)

Seating people faster and taking payments faster would be a small improvement, but since you can’t make the food faster, you decide that it won’t be enough. Speed is not the answer!

A “take a number” system sounds good at first, until you realize that those people still have to wait and watch the “now serving” sign, and the whole problem is that you don’t have room for the line, so taking a number could actually make it worse. No good.

The big guy outside would fix the problem with too many people waiting, but it would still make people stand in line, so it’s equally annoying, and now everybody is outside… that might be worse. (Let’s pretend that you’re not an exclusive club in LA that wants to use the long line as advertising…)


So we started with one problem: too many people are waiting in line and it’s annoying.

And we have added a few more requirements:

1) We can’t increase the load on the kitchen.

2) Prices must remain the same.

3) Portions must stay the same size.

4) The solution must allow people to wait somewhere else.


These requirements eliminate all of our ideas except one: the “buzzer”. A buzzer would allow people to wait anywhere they want and come back when they get the signal. Shorter line, less annoying wait. Perfect!

Sometimes you will eliminate all of your ideas by adding requirements. That doesn’t mean there is no solution, it just means you need to work on it more.


Now… if you had just brainstormed to get new ideas for the restaurant, you might have ignored the problem of the long line, so your ideas might have been totally useless.

If you had only tried to solve the long line problem by itself, you might have gone with the “two hosts” idea, which would not have made a big difference (but you would get lots of positive feedback from the staff! Uh oh!).

But by making the problem harder you made the solution better. 

Holy shitballs, Batman!

The reason lots of people start with inspiration is because inspiration feels good. Nobody likes limitations because limitations are hard and they ruin our feel-good inspiration. Boo. Our big dumb monkey brains are wired to like things that feel good and avoid things that are hard.

And that is why starting with “inspiration” or “ideas” can be a big problem for you and your team. Over time, you might spend so much time exploring trivial — but awesome — ideas, that you won’t actually achieve very much.

But a little hard thinking can lead you to solutions you would never have tried otherwise. Real innovations. Rockstar-level thinking. 

Ideas that will inspire other people.



The most valuable time to invest your patience is at the beginning. Smart requirements will raise your UX game.