Hacker News Reader

Comment by wahern | Hacker News Reader

> 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.

View on HN

> 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.

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).

Reply on news.ycombinator.com