If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for. They might even clob several different tools together in an unholy abomination to get it to do what they actually want instead of having a tool built to do precisely what they want (and once that tool has been built - people will inevitably misuse it to do things other than what it was designed for and then complain about its poor UX for doing those things).

▲

uberduper 4 days ago | parent | next [-]

> If a user holds an ice cream cone upside-down and their ice cream falls to the floor, do you blame the user for not holding their ice cream cone upright or the creator of the ice cream cone for a stupid design that allows the ice cream to so easily fall out of the ice cream holding device and onto the floor?

Playing along with this analogy, what I think we see a lot of in product development is the customer going to the PM and saying they need the cone to have a cover. The PM and the customer iterate over the specifics of the cover. PM goes to the engineer and tells them the cone needs a cover that meets x, y, and z requirements. Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

▲

dgfitz 4 days ago | parent [-]

> Engineer, knowing how you're supposed to use the ice cream cone, objects. PM, knowing what the customer needs, insists.

That’s the kicker. They know what the customer _wants_ not what they _need_

The number of times a Jr engineer has asked me “how do I accomplish task X in technology Y, it’s really important!”

I always, always ask “what problem are you trying to solve. Not once in over 15 YoE has the solution been to use X.

A good PM doesn’t say “this is what the customer needs” because most of the time the fucking customer doesn’t actually understand what they need.

The engineer knows that holding the ice cream cone upside down means they’re trying to use the product in a way it was never intended, so they push back.

A good PM would ask “why do you want to hold the ice cream cone upside down, customer?”

“Oh well we don’t actually want to hold it upside down, we just get frustrated that sometimes when we put too much ice cream on/in the cone it falls out. So if you can make the cone hold the ice cream while upside down, the problem is solved!”

“Oh, so what you actually need is a bigger cone that can hold more ice cream?”

“Oh, yeah that would work too”

meme about Spider-Man facepalming, where Spider-Man is the engineer

▲

uberduper 4 days ago | parent [-]

My point is that by letting the customer define the solution rather than explain the problem, nobody knows they're even trying to hold it upside down. The why of it all is lost in some PM / Engineer power struggle that usually results in ice cream cones having covers (and a happy customer).

	▲	dgfitz 4 days ago \| parent [-]
		As a sw engineer, I’m going to tell our customer that the thing they claim they want they do not need. Because I’ve done this enough times, they’ll listen to me and we won’t waste time on it. You should try it, instead of designing soggy ice cream cone caps.

▲

boticello 3 days ago | parent | prev | next [-]

And thus the tub was conceived. By someone who was watching people wrangling with cones.

▲

selbyk 3 days ago | parent [-]

Unfortunately tho, it also suffers the same huge design flaw: hold it upside down, ice cream hits floor. =(

	▲	fuzzy_biscuit 3 days ago \| parent [-]
		And thus, the milkshake was born. And it was good.

▲

wahern 4 days ago | parent | prev [-]

> I find far more often that bad UX is the result of someone trying to use a tool for something it wasn't designed for.

Isn't that the point? In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head. In the open source world it's more reasonable and common to design a tool not predicated on the predominant models and workflows. And every once in a awhile those experiments result in something very valuable that helps to break predominant paradigms. But in the commercial space solving customer's immediate problems in a manner that is intuitive for them is paramount.

▲

Nadya 4 days ago | parent [-]

> In the story the engineers weren't designing a tool well-suited for the customers, but for whatever abstract scenarios they had in their head.

A joke exists about how developers will never be displaced by AI because that would require clients and/or project managers to accurately describe what they want the AI to build. On one hand that is extremely egotistical of developers. On the other it is also factual.

To my understanding of the story the developers had designed what was being communicated to them by someone who described what customers asked for and not what the customers actually wanted or needed. Nothing to do with what the engineers thought customers wanted and everything to do with what project managers had expressed to the engineers about what customers wanted. Speaking with the customers directly gave them a better idea of what was actually being asked for. So they built that instead.

My takeaway from the story is to fire the project manager. Not to make devs call clients.

	▲	wahern 4 days ago \| parent [-]
		Product and project managers can have similar issues of perspective as engineers, chasing trends in the industry or losing the forest for the trees (feature checklists, etc). But, yeah, having devs talk directly to customers can be problematic. If you give a customer a direct line to an engineer, sometimes they can monopolize the engineer's time (they feel they can leverage an "inside" contact) or skew their priorities. Having engineers work closely with tech support is a good middle ground, such as by fostering 1:1 relationships with support or even fielding tech support tickets themselves (tech support tickets have more finality than, e.g. sales support issues). That way they can get a broader perspective on pain points and potential new directions. It can really help refine a product beyond what can be achieved by lobbing feature and bug tickets over a fence or through formal group meetings (which often can be either too structured or too chaotic).