This is relevant perhaps 10% of the time. The other 90%, the devs have absolutely no idea how to actually perform the task the user of the software is trying to do, don't talk to customers, don't dogfood it, often don't even understand the industry, and the result is a horrible UI which forces people to severely adjust their existing processes to fit the software. Then if course the devs complain about "the stupid users." To this day 99% of address forms expect me to find my state from a drop down list of 50 entries plus DC, Puerto Rico, Guam, etc. instead of simply typing in the two letter abbreviation.
When users never use the features they asked for
51–60 of 228 posts
Re: When users never use the features they asked for
#52Earlier quoted context omitted.
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…
Had an issue like that. The workaround snippet that fixed it was aptly named stfu.js by the author.
I went with the commands:
> implaying
and
> srsbsns
to toggle it off/on.
Re: When users never use the features they asked for
#53I moved from engineering to product management precisely because I realized that the problem of "what should be built" is often harder than building the thing.
Asking users what features they want is pretty much not fair - because most people don't have the skills to think through and answer that question, nor is it their job to do it. It's like asking a novel reader what they'd like to see in the next chapter. It's a cop-out with guaranteed suboptimal outcome.
Obviously product management is half art half science but in a nutshell, much better than asking an individual what features they want would be asking them - especially on a senior level - what problems they have and what keeps them up at night. Getting an understanding of that and then thinking about how those problems/risks can be addressed by your system is a much better starting point.
The reason I say that it's important to partner with your users on the senior level is the difference in perspective on the class of problems they want to tackle.
For example I used to work on a trading platform. If I went to my heaviest users and asked them what their problems were, they would probably say "I do 1000 trades a day, and I have to tweak each one manually - can you make that process faster" and maybe even have an idea of what that could look like. So let's say I did that and shaved a second off each trade handling so my user is happy cuz I saved them 16 minutes a day. Sounds like a job well done.
But if instead (or in addition) I talked to their boss, I might hear a very different story. Eg: "we do 1000 trades here every day, but 900 of them are straight forward. I wish I could automate those so trader can focus on the 100 complicated ones. But instead, he's so busy doing the 1000 trades that a lot of them get fucked up especially the complex ones."
That's a major change of perspective, from optimizing an existing workflow to optimizing the entire operation. The implementation is quite different - one is a UI optimization and the other is establishing some sort of automation capability that can be extended to all my clients over time. One may be doable with the team you have, one may require standing up a new group, etc.
At the end, the end user is happy (they get to do 10% of their previous load but this is the high value 10% they really want to focus on.) The key point is that neither the user nor their boss could tell me exactly what to build, but the high level perspective allowed me to understand their problem in a deep way and figure out a scalable solution for them and other clients.
Anyway that's just an example but yeah, your users can't tell you what to build and yeah you need a good product manager - or someone who can play that role well.
Re: When users never use the features they asked for
#54Microsoft didn't run automatic code analysis tools as part of their code review process until 2017? What on earth was wrong?
Re: When users never use the features they asked for
#55Slightly 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.
Is there a book(s) you could recommend for product design methodology?
For this specific case (product discovery interviews) take a look at Interviewing Users by Steve Portigal, and Validating Product Ideas by Tomer Sharon.
Re: When users never use the features they asked for
#56Before 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 t…
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 (y…
That's brutal. You were right to quit.
There's a certain personality type that will never appreciate or reward hard work.
Re: When users never use the features they asked for
#57Earlier quoted context omitted.
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.
Back then was 2018. Lint dates from the seventies. I doubt it was the first static analysis tool, either.
It seems like autofixing linters got popular about 10 years ago? That was when it hit my radar at least, but before that I wasn't really a software dev. Whenever it happened that was a quantum jump in usability.
Re: When users never use the features they asked for
#58I 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…
This is why changelogs and release notes are not optional or tucked away in a dark corner. And users who request features need to be notified (actively, specifically) that something they requested or a bug they hit was resolved or addressed.
I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.
Re: When users never use the features they asked for
#59I find it's usually release with the minimum necessary features first. Once they digest those, then add on the next set based on feedback. The more incremental the better. But do keep likely future features in mind, such as leaving space in the tool-bar etc. Certain things are hard to retrofit after the fact.
Re: When users never use the features they asked for
#60[deleted]