Earlier quoted context omitted.
A variant of the first is the highly imaginative user who keeps coming up with new variations or expansions of their idea. It’s not malicious but it can be exhausting. Especially if you try to address their core need but their imagination doesn’t extend quite far enough to see how your effort would help, because they love their ideas.
I would describe those as a variant of the second, not the first. Those imaginative users may be polite, but they’re not understanding. While not rude, they are their own brand of entitled and high maintenance (I like your description of “exhausting”). One major reason I put them in the second category instead of the first is that the result is the same from my side, i.e. I interact with them as little as a I can. To…
Good software knows when to stop
281–290 of 304 posts
Re: Good software knows when to stop
#282Earlier quoted context omitted.
> And the LFG system. The LFG system basically killed most social interaction in WoW. So if you played for that, you got excluded. They also sort of killed build diversity, but there was no build diversity in classic either, at least if you wanted to raid. The grinding... I don't miss it. That could have used toning down.
> The LFG system basically killed most social interaction in WoW. as someone who has played since 2004 with only a handful of month-long breaks, this is simply not true.
Re: Good software knows when to stop
#283> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…
Do you just explain or do you start by asking a question?
What I usually go with is _asking_ what they want to achieve. Because usually, the user describes features/functions/forms instead of explaining the business case. And while the user describes a business case (a thing that generates him money/...) it becomes obvious how/why to implement the request.
So often, people forget to just ask and listen.
Re: Good software knows when to stop
#284> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…
get paid. Stop this nonsense. You shouldn't work for free it makes you disagreeable (I am the living proof).
> I guess the moral of the story is don’t be a prick to the people you’re asking something from.
This is your salary. That's how you get paid. In power. Power over what? "I am a latex maintainer". I'm not impressed. You're wasting your time. Show me your Ferrari instead.
Re: Good software knows when to stop
#285Earlier quoted context omitted.
Classic represents a different design philosophy. One that still appeals today. It has nothing to do with nostalgia. Or games like Project Gorgon wouldn't be so appealing to people.
So we are back to what I said earlier :p People do not want "classic": people want a "good" game that has some specific characteristics
Re: Good software knows when to stop
#286Earlier quoted context omitted.
Sid Meier has talked about something similar: he likes to tell designers at Firaxis that "feedback is fact". That is, no matter how strongly you (the designer) believe that something is a good design, if the player says "this isn't fun" then that needs to be taken as the gospel truth. The players might not be able to explain why it isn't fun, and you might be able to tweak the design to make it fun, but what you can'…
What I’ve found is key to UI design is to take this a step farther. Users will often try to explain why it isn’t what they want and they will be wrong about the explanation.
Re: Good software knows when to stop
#287Earlier quoted context omitted.
What I’ve found is key to UI design is to take this a step farther. Users will often try to explain why it isn’t what they want and they will be wrong about the explanation.
Some phrase I heard a while back, I think it was from bill hader. "People are ALWAYS right when telling you something doesn't work. They're rarely right when telling you how to fix it."
It’s really questions where I delight the users. They know something is wrong but they cannot articulate it so they assume it’s them and ask how to do something. Which tells you that the feature is missing or not discoverable. If four people ask you the same question it’s a bug not a feature and you should fix it.
Re: Good software knows when to stop
#288We should normalize "finished" software products that stop feature creep and focus strictly on bug fixes and security updates. It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand. Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth of…
Excellent self-owning example: > Dropbox were perfect in 2012 You mean that dumb app that forced you to move files into a single folder instead of adapting to your workflow was prefect? Yeah, no, we shouldn't normalize that, we should push for improvements
> You mean that dumb app that forced you to move files into a single folder instead of adapting to your workflow was prefect?
Users in 2012 were overwhelmingly of the cohort who's metaphor for doing work on a computer was the filesystem. You opened Files with Programs, worked on them, saved them. You wanted your latest Files on all your computers (1), and you wanted to Share them (2).
Unless users were on a system managed by a sysadmin there were only really two solutions for problems (1)&(2): you would Email the File (A), or you would copy it to a Floppy/CD/USB (B) and physically move it.
Note the caveat of "in absence of a sysadmin". So either on a school or corporate work environment, or if you happened to have a geek in your family/social group who did it as a passion project. Or y'know, if _you_ were the geek you could roll your own.
So of course when Dropbox was first introduced to a technical audience they didn't get it. See the infamous thread ;) https://news.ycombinator.com/item?id=8863
While you're there, note the tag line in the title of the post "Throw away your USB key"
Now rereading your comment it is clearly an example of exactly what OP was referring to:
> It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand.
If Dropbox did not "adapt to your workflow", then just _don't use Dropbox_.
Instead you attack it as "dumb" and demand it change...and those users for whom Dropbox _was_ perfectly adapted don't have their solution anymore.
Software doesn't have to be forever changing and chasing user growth; it's not a zero-sum game. The bits don't care if no one uses them. But _people_ care if you take away their bits.
> ...we shouldn't normalize that, we should push for improvements
Agreed, you should create a new solution and put it out there! Just as suggested by the post you've replied to :)
Re: Good software knows when to stop
#289Earlier quoted context omitted.
What backlash against Adobe? I think you are mistaking comment section consensus for reality. People on forums and social media complain, but the comment section consensus is often dead wrong! There was no real backlash against Adobe. They added subscriptions and grew revenue. Some people grumbled online, but they paid, which means they don’t like the old model, they like the new one.
A company abusing monopoly power to screw over consumers doesn't prove that consumers like to be abused.
Re: Good software knows when to stop
#290Earlier quoted context omitted.
I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…
Due to the XY problem what they ask for often isn’t what they need. And what they yell about won’t make them happy. By and large I’ve gotten better feature requests out of looking at patterns of frequently asked questions and turning them into tasks instead of reacting to negative feedback.