Live data from Hacker News

When users never use the features they asked for

web.eecs.utk.edu

11–20 of 228 posts

Re: When users never use the features they asked for

#11
When you ask people to imagine a feature, they're going to imagine the absolute perfect version of the feature, for them personally. A feature that requires no effort to set up or use, provides exactly the information or functionality they want, and never gets in the way of anything else.

Everyone takes for granted how smooth their own workflow is to them, both because they're already used to it, and because they sunk effort into it to make it smooth (via learning or planning), which has probably been forgotten. So, people just take for granted that new features will maintain that acquired smoothness --- unfortunately, they usually don't.

As the author found out, most of the work in building features is often not in the "raw functionality" of the feature, but rather in making something that performs its functions while also not costing the user significant extra mental or physical effort to use.

Re: When users never use the features they asked for

#12

Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…

Your comment is more true today than it was back then, not that I disagree with you posting it. Back then linters were a twinkle in the hopeful eye of software devs. Now they're battle hardened.

Re: When users never use the features they asked for

#13
Nice post. I liked this take away. "Users say things for a reason, but there may be more to it than face value."

Theres often more to what a human says than face value. The key is to always be asking questions, always ask why, multiple times. Ask questions until you feel like you're on the edge of pissing someone off.

Often, a good bit of time up front can get to a few outcomes which save you a massive headache.

1) You understand the feature so well, you're ready to go and know it will be used. 2) The REAL ask was something totally different, and now you know what you need to do (nor not in some cases, sometimes its training, using the product properly/as intended etc).

You're also going to be giving the requester the space to fully explain themselves, and sometimes they can talk themselves round as well. At the end of the day everyones a winner when we ask more questions and listen.

Re: When users never use the features they asked for

#14
A metaphor for this situation (building exactly what customers ask for) could be the car Homer Simpson designed ("The Homer").

https://simpsons.fandom.com/wiki/The_Homer

Not that all users are equal to Homer, but what they think they want and what they actually need are very different.

It's better to get more detail on the problem, then present a series of possible solutions to evaluate and iterate on.

Re: When users never use the features they asked for

#16
post #14

A metaphor for this situation (building exactly what customers ask for) could be the car Homer Simpson designed ("The Homer"). https://simpsons.fandom.com/wiki/The_Homer Not that all users are equal to Homer, but what they think they want and what they actually need are very different. It's better to get more detail on the problem, then present a series of possible solutions to evaluate and iterate on.

Not just that. If the feature is given in an usable or other poor form. They won't use it even when they have it right there. May be its not very obvious, or complicated, or too time consuming. Design makes all the difference.

If you give them something they never needed or asked for, but it's so obvious and simple to use, they will use the hell out if it.

Re: When users never use the features they asked for

#18

Nice post. I liked this take away. "Users say things for a reason, but there may be more to it than face value." Theres often more to what a human says than face value. The key is to always be asking questions, always ask why, multiple times. Ask questions until you feel like you're on the edge of pissing someone off. Often, a good bit of time up front can get to a few outcomes which save you a massive headache. 1) Y…

The 5 whys https://en.wikipedia.org/wiki/Five_whys

Re: When users never use the features they asked for

#19
post #9

One of many things I learned from writing software just for myself is that I'm just about as bad as anybody at figuring out what I really want, even when I'm talking to myself. I've even had one or two cases where I ignored a feature I asked myself for, and much later realized: Hey, I could actually use that. The worst is asking myself, "How many times do I have to ask for this before you quit procrastinating and jus…

Oh hey its me. I've done some painstaking work to add a feature (hell, even just an excel macro that at the time seemed useful) and realize like 9 months later I've used the feature a whopping 3 times.

Re: When users never use the features they asked for

#20

Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…

There's nothing more frustrating than a stupid machine telling me it knows better when it doesn't. I used to work on a team where the build defaulted to fail if something wasn't used and debugging was a fucking nightmare because the moment you comment out a block of code there's a cascade of warnings into errors that is just never ending (it was typescript so it leaked all the way back to module definition). I had to piss away some time to write a script to turn a bunch of the rules off and then remember to re-enable them later or I'd break the build by breaking someone's OCD.
Post reply on HN