User Needs vs. Business Needs – Striking a Balance Between the Two

There’s a comic, called The UX Designer Paradox, that’s been making the rounds since 2015 — have you seen seen it?

It pretty much describes every UX project, ever.

UX Designer Paradox by Brady Bonus

We have rocket ship like dreams for our beloved digital product, yet in reality, all the user really needs are a bike and a ramp.

Trouble is, you can’t sell a bike and a ramp.

Well, you can to innovators and early adopters. But once you open your doors to the majority, or pitch to larger organizations, things can get tricky.

You know the majority will love it, but you gotta get them to try it (they can be a harder sell).

Larger organizations will love it, too, but their decision makers (who base their yeses on different criteria) must give the green light before you can ship.

And marketing wants X because they need it to be more marketable. Your UX-ers argue it will do more harm than good. And the devs? They’re overloaded, silly.

Business, users, users, business, gah!

As I mentioned last month, this back and forth is normal.

Okay, deep breath… and let’s talk about how to resolve this dilemma.

If your team is small enough, see if you can come to an agreement on which ideas to test, design and build during your next meeting.

If you can’t, or your team won’t (we’ve all been there), then try this 3-step process:

1. Filter
Although there’s no such thing as a bad idea, some ideas are, well, not that good. They do little for the user, and even less for the business. Set those aside.

A few more will be completely infeasible at this time. I hate to say that, but it is what it is. Set those aside, too.

2. Review
Sort the remaining ideas by business criteria. For example, improves revenue, increases retention, speeds on-boarding… Or have your team rate each item against each criteria. “On a scale of 1 to 5, how likely will X idea yield Y result?”

Then, determine the amount of effort required to execute every idea.

3. Invalidate
By now, some ideas will stand out as hell yeahs ‐ yielding maximum result with minimum effort. Others will require more effort, yet worth the hassle. Promote them to “features” to design and build.

The rest will fall somewhere in between. Make a plan to invalidate them as soon as possible, using your testing methods of choice.

Once you’ve completed your testing, promote any remaining ideas to “features” and place them in the next available cycles.

And there you have it. User needs and business needs, balanced.

Please note that this was an overgeneralization. I couldn’t go into detail without knowing your specific situation, though it should be enough for you to move forward. Adjust and customize as you see fit.

Until next time,
K