[HN Gopher] When users never use the features they asked for
___________________________________________________________________
When users never use the features they asked for
Author : jermaustin1
Score : 150 points
Date : 2021-09-29 20:41 UTC (2 hours ago)
(HTM) web link (web.eecs.utk.edu)
(TXT) w3m dump (web.eecs.utk.edu)
| ipaddr wrote:
| People will buy products because if features they will never use.
| Not building costs money.
| 542458 wrote:
| This is particularly true if the "users" aren't the ones who
| are signing the cheques. Sometimes shiny stuff that looks good
| in a product demo or on the trade show floor is what it takes
| to actually move units.
| adamm255 wrote:
| 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.
| new_guy wrote:
| The 5 whys https://en.wikipedia.org/wiki/Five_whys
| strict9 wrote:
| 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.
| smusamashah wrote:
| 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.
| KirillPanov wrote:
| ... and this is how we got WebUSB.
| everdrive wrote:
| Sometimes I wonder if software is becoming worse because logging
| is coming better. We have so much data about problems that users
| are having, feedback they're providing, etc. Perhaps following
| the mass of people is the root cause of software's constant and
| worse UI changes.
| quickthrower2 wrote:
| Jira takes the biscuit with their text editor. Always changing
| and hard to make sense of. Recently ctrl-enter and enter
| actions were swapped!
| Minor49er wrote:
| My favorite thing about their text editor is that it will
| delete all of your changes with no option for recovery if you
| accidentally hit the escape key. I also like how this has
| been an open issue for many years on Jira, but they refuse to
| change it for some reason (or at least that's the state of it
| the last I checked about a year ago. Thankfully, I don't have
| to use any Atlassian products anymore.)
| valparaiso wrote:
| Ha. Title is right about Android fanatics and Apple.
| [deleted]
| protomyth wrote:
| The funner one is unique to enterprise developers. Begged to
| implement a feature to the enterprise software, the development
| team puts in a hell of a lot of hours to get this time sensitive
| feature into the production. Then, out of nowhere, a manager of
| some import informs everyone that they cannot use that feature as
| its "against best practices" or some other language to that
| effect. Bonus points if said manager was on the email chain about
| the feature and its progress.
| datavirtue wrote:
| I was hoping for a good old fashioned, negative developer rant.
| rightbyte wrote:
| The author is atleast referring to those rants as "angry mails"
| he got.
|
| I think these automated CI systems is a losing battle. It makes
| the build chain to complex. There is too much corner cases that
| gives false positives unless you keep it dead simple, like eg.
| enabling all warnings are errors or something in gcc.
| macando wrote:
| > _Turns out there were a few hiccups: everyone involved in that
| project we wanted to use had left the company, we had no idea how
| to build the source code, it had something like 500,000 lines of
| code, and the one person we found that knew anything about the
| project was 13 hours ahead and stopped replying to our emails._
|
| When you don't talk to users this is what you end up with.
| [deleted]
| [deleted]
| commandlinefan wrote:
| I once spent a week working on a fairly complex feature for a
| product that the users were demanding almost daily updates on. I
| delivered it and, by coincidence, happened to be where the users
| were a couple of weeks later and I stopped by to say hello and
| saw that the user who had been asking for the feature every day
| was still using the product the "old way". I asked why and he
| didn't seem to follow what I meant, so I reached over and showed
| him the _feature that he had been demanding I add_ and he said,
| "oh, wow, that's awesome, that's going to be such a huge
| timesaver for us!"
| jsemrau wrote:
| The wonders of digital transformation. One of my biggest
| insights here was that digital transformation is not only the
| technical upgrade or simplicity of implementation but rather
| the cultural implementation i.e., process re-development and
| re-training.
| quickthrower2 wrote:
| You did the customer success role.
| DrammBA wrote:
| How subtle was the update message letting the users know about
| the new feature?
| garmaine wrote:
| Yeah sounds like the lesson here is that nobody reads the
| update messages.
| Semiapies wrote:
| Couldn't have anything to do with how app update screens
| share the exact ergonomics that subscribe-to-the-newsletter
| nags and other ad popups have.
| Aeolun wrote:
| I mean, they stopped demanding the feature every day. Clearly
| they were aware that _something_ changed.
| oceanghost wrote:
| Before the launch of the XBOX 360, the company I worked for was
| one of their suppliers, and without going into enough detail to
| make me identifiable, the management of our two companies had
| arrived at sort of a stalemate: We didn't want to tell them
| exactly how our algorithms worked, and they didn't want to tell
| us exactly what they were doing with them-- think of it like a
| data compressor where, we don't want them to know the exact
| compression algo, and they don't want us to have their data.
|
| So, somehow, It is arrived at that a website will be created that
| encodes MS's proprietary data, but doesn't store it, but also our
| algorithm is implemented server side, so there's no leakage of
| proprietary stuff.
|
| A month later, the app is done and tested and I'm decoding data
| from the website on real hardware. I move on to the next project.
|
| Three years later, the Xbox 360 is out, I decide I'm tired of
| filling out reimbursement forms for Heroku and its got to be a
| security risk with no updates in 3 years... so I take a look at
| the apps stats to see if its feasible to shut it down--exactly
| zero users. Nobody ever attempted to use it, not even once.
|
| Ironically and unknown to me, the source code had been lost in a
| freak accident and when I deleted the Heroku account that was the
| only copy of the source left.
|
| Even worse, a year later someone claimed to have a use for the
| app and where was it please? And I had to explain we no longer
| had the source. I remember a very long e-mail about how
| irresponsible we were.
| arthurcolle wrote:
| Cool story thanks for sharing - so how did they get around the
| issue for three years without the app?
| AmericanChopper wrote:
| The worst programming experience of my life related to lost
| source code.
|
| I was working for a place that had a service running from a
| Java app that was customized for each customer, about 200
| copies of roughly the same app. There was source control at
| some point, and when a new customer was being on boarded they'd
| just make the customizations they required, compile the app,
| and deploy it.
|
| By the time I worked there (years later), all source code had
| been lost, and I was tasked with creating a CI/CD system that
| included managing these apps (they'd now decided they needed to
| be maintained).
|
| For each one I had to decompile the whole thing, rewrite the
| code into a human readable format, redeploy and test it. They
| were filled with all sorts of horrible anti-patterns too, like
| hard coded file paths, and some of them were only used once a
| year (but for an absolutely business critical process).
|
| About half way through we had a major data center failure that
| meant we had to do a failover, which of course broke most of
| these apps with all their hard coded configuration. So instead
| of having months to work through all of this garbage, I was
| asked to get them all working immediately.
|
| I got them all working in 3 days, which I thought was quite a
| monumental accomplishment. But my CEO was very dissatisfied
| that it took so long. I quit a couple weeks later, and still
| almost regret putting so much effort in to saving them. A
| friend of mine still works there and apparently all of these
| applications are in exactly the same state as I left them.
| karaterobot wrote:
| Slightly frustrated to read this, because this is user research
| 101! It's really impressive when someone independently discovers
| practices from an outside discipline, just by observation and
| inference. However, somebody could have saved this poor guy a lot
| of frustration by not forcing him to develop a product design
| methodology from first principles.
| huang47 wrote:
| thanks for this great write up and I wish I could read this 10
| years ago :).
| kerblang wrote:
| 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 just get it done???" I'm not
| sure which of me is the bigger jerk.
| Arrath wrote:
| 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.
| austincheney wrote:
| The challenge there is when people start using your personal
| project. Yes, you remain in control and you remain the primary
| user. But... now regression and features become a much greater
| concern because the last thing you want to do is harm other
| people even if they are only a secondary audience. As the
| project grows this becomes the most pressing concern regardless
| of who is the primary user.
|
| That begs the question: Why bother growing the application
| beyond the smallest set of explicit use cases? When you are the
| primary user AND the only use environment or input samples are
| written by you life is simple. The moment you must analyze
| something not written by you, even if this usage is only for
| you, the problem cases blossom. If your application refuses to
| solve for those cases then you need to add more features or use
| a different application.
|
| Those two scenarios seem to feed each other which becomes
| evident by traffic or usage numbers as you pull your hair out
| keeping up with some hobby application.
| yupper32 wrote:
| A fine post and I'm sure a fine tool, but why is an internal
| linter tool the subject of a proper academic paper?
|
| I can't imagine writing an academic paper for any of the projects
| of similar complexity and general interest that I've worked on.
| endisneigh wrote:
| This was a nice article, but I'm not sure the title is
| representative of its contents. I think the first (Keep your
| users in the loop, always. Do not go build in isolation) or
| second to last (A user's workflow is everything ) bullet the
| author uses for their summary is findings to be more enlightening
| and representative.
|
| Internal tools definitely require a close relationship with some
| set of users to really validate what's being worked on. It's just
| too easy for teams to make unused internal tools. The feedback
| loop is generally just not there initially. You really have to go
| and find some users. In this way it's similar to pre-seed stage
| startup life.
| david_allison wrote:
| 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 streamlines the reviews for reviewers, and
| gives new contributors a much better experience as they have less
| feedback to address, and more confidence that their code is
| correct.
| Quarrelsome wrote:
| 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.
| macando wrote:
| Had an issue like that. The workaround snippet that fixed it
| was aptly named stfu.js by the author.
| marcosdumay wrote:
| Well, don't turn warnings into errors. Doubly so on your
| development environment. That's not a good reason for not
| running a linter while developing.
|
| But, of course, if the decision was out of your hands, people
| that do that are usually the same that enable all linter
| rules. Neither decision makes for a good development
| practice.
| 3pt14159 wrote:
| 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.
| buescher wrote:
| Back then was 2018. Lint dates from the seventies. I doubt it
| was the first static analysis tool, either.
| 3pt14159 wrote:
| You're right. I read 2008 in the post and thought the
| writer was talking about a time shortly after then. By the
| late 2010s linters were prevalent.
| caseyross wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-29 23:00 UTC)