Hacker News Reader

Comment by unityByFreedom | Hacker News Reader

> A trap I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about.

That's odd. The point of focusing on users is to discover what users want. If you're not doing then you're not really focused on users.

View on HN

But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.

Also, +1 to the parent comment. I worked at a startup where we made exactly that mistake - we delayed releases until it met a high standard of UX - took us more than couple of years. By this time, competitors that built a _much_ crappier product got userbase, and hence funding, and then used that to get their UX up to par (sometimes they wouldn't even have the features, they just faked it). We realized our mistake, adapted and stayed in business - but it was a difficult and painful process.

So basically - first get things up and running FAST, then worry about polish and laser-cut UX.

> But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.

If these two things are not equal then you're doing it wrong.

I think the point is you can easily get so focused on making the experience "delightful" that you work on things that would delight you, but that your users actually don't care about so much. And you need to take a step back, build something functional but not necessarily completely "delightful" & then figure out what your initial users actually do care about and iterate from there

I think of it like listen to your users, but don’t do everything they ask. Use your judgement to make sure it aligns with your goals, and hopefully you have a goal beyond ‘make monies’.

Additionally, think about why they're asking for a certain thing, and whether their request is really the best way to solve the underlying problem they want solved

“Treat your users as you would a class of pre-school children. If they’re all screaming for a snack you don’t necessarily give them one, perhaps a healthy lunch would be better for the underlying need.”

I don't think pre-school children are the only people who are poor at recognising or expressing what they really want, I think that's a fairly universal thing. It's very easy to get an idea about what the solution should be & make a request based on that rather than basing the request on the problem you're facing.

A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:

* I need a better lawnmower

* I need a better way to cut grass

The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.

Reply on news.ycombinator.com