A typical story of how design goes wrong, and an idea - 2018

I wrote this article after hearing from a friend about the seemingly common design problem - and it’s got to do with a power struggle that we’re all used to!

The other day I got a message from a former colleague — let’s call her Sam. Sam was asking me whether I knew of a resource where she could find user testing results. I told her I wasn’t really sure but asked what the specific problem was (maybe I’d had some personal experience with it and could help).

Sam said that she and her PO were at an impasse about a checkout problem on their online site and she needed ammo.

The problem is as follows:

After adding items to their basket, the user goes to check out. Sam designed it so that there is a “guest checkout” with a prompt to register a profile after the fact, while the PO wants there to be a mandatory registration before checkout can be completed.

Now you can see why Sam had an issue:

• Guest checkout would be the quickest way for the user to complete their task.

• It offers the most relevant path.

• It doesn’t create any extra barriers — ensuring more completed checkouts (guys, this means more sales.)

• There is still an option, post-checkout, to register a profile for future ease — and in fact, it was simpler because the guest checkout information could be reused. The only extra fields would be for the password.

But, you can also see where the PO could be coming from:

• Targets are easier to measure if there is a definite metric like “number of new profiles” rather than sales.

• It could make future purchases easier by saving relevant details, so it could be better for the user anyway.

• The company can use the profile data (read: email addresses) to advertise to the customer base — which increases the likelihood of repeat sales.

• Using the demographics of the current customers, the company could better target potential customers.

Besides any other factors (like whether the store offered a product or service that’s used regularly versus occasionally or even once-off) — the overarching question remained.

Now, a UX designers role isn’t simply to design for the user. Especially at the cost, or sacrifice, of the business goals and objectives. But, in cases like this, it’s difficult to get the right decision over the line.

This is why Sam was asking if I’d come across any research — because as UX designers, we work with 2 rails: principles and research. But as much as Sam could cite great design principles (Don’t make things harder than they need to be!) they weren’t enough to convince her PO to even try guest checkout. And in the absence of users on-tap, she was searching for research that others had done.

Now, there are two problems with this scenario: who makes design decisions, and how to justify them better.

The PO is not the designer… but makes design decisions.

Realistically, Sam will probably not win this battle. Not because she’s wrong — in fact, she’s elegantly addressed the business requirement and user considerations by offering the registration step at the end. But, she’ll lose because the PO or PM sits higher on the food chain than the UX designer.
It’s a problem I’ve been faced with time and time again. I’ve seen good design live or die on the sword of a PO’s decision — and often it’s over an opinion. So here’s the crux:

If the designer has addressed the business concerns as well as put the user at the centre — why should the PO care about the execution?

They shouldn’t. Instead of focusing on the detail, they should be making sure that the right needs are addressed strategically, as part of a larger goal.
PO’s, let your designers do their thing, while you do yours — please?

There’s no single source of truth.

This is the bigger problem. This situation really made me think about the fact that as UX folk, we speak about research and testing a lot — but we don’t share our knowledge enough. Sure, you see articles about micro-interactions, read anecdotal research reports or you buy books with principles that were built on research, but that isn’t enough. It’s also not enough to rely solely on doing our own research for every single problem we face during the design process — there simply isn’t budget (that’s a rant for another day…)

I understand that sometimes research isn’t shared because of contractual obligations, IP or sensitive material — but what if we abstracted it into its purest form, a design problem, and shared that?

What we’re missing is something along the lines of a wiki — where you can search for research about similar problems. It may not be first prize (own research) but it could go a long way to helping UX designers back up their design decisions quickly.
It would also be a way to share your research, no matter how micro or macro.

How does this sound? Do you think you’d use something like this? What kind of credibility measures would we need to put in place?

If we want to stop cringing every time we release something because we know it could/should/would have been better — we need to get better at justifying our decisions, and maybe that means that we need to apply UX thinking to this problem.

https://uxdesign.cc/a-typical-story-of-how-design-goes-wrong-and-an-idea-d9dd3fe465a8