61–70 of 228 posts
Earlier quoted context omitted.
How subtle was the update message letting the users know about the new feature?
I mean, they stopped demanding the feature every day. Clearly they were aware that something changed.
Nobody was yelling at anyone to actually use it.
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.
Is there a book(s) you could recommend for product design methodology?
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.
It's so nice to be able to write a compiler/lint rule with a quick fix and then see it catch both my own mistakes, and potentially remove a concern/checkbox from the code review template
Earlier quoted context omitted.
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.
But I did get a lot out of the few years I worked there, even though a lot of it sucked. It was my first proper job and they’d basically let me work on anything I wanted to, even though I was incredibly green and was just figuring it all out as I went. I definitely fit a lot more experience and learning into those years than you’d reasonably expect a person to. I think a lot of my success today came from turning their incompetence into opportunities.
I 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…
Automating a workflow is the best optimization from the users point of view.
I run an email forwarding services(https://hanami.run) basically you add your domains in and add some records.
We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure.
All good.
They are paid our highest tier ($30 per month) so we prioritize the requests and work on it.
2 days later that same user downgrade to the lowest plan and delete all of their hundred of domains...
That complicated features remain unused to nowadays...
Earlier quoted context omitted.
How subtle was the update message letting the users know about the new feature?
I mean, they stopped demanding the feature every day. Clearly they were aware that something changed.
I recently started working in design after being a developer for more than a decade. Back then, planning how things should work for users felt frivolous compared to coding. Beyond that, getting working code in the editor just felt so good that I never wanted to put it off. These are the excuses I'd make to avoid really thinking about the users:
- I can clean up the interface later
- I'll figure out what features I can support when I figure out how it's going to work
- I've got a good intuitive sense of what would be most useful and how people want things to work
Obviously, solo intern projects are an edge case, but this case study perfectly illustrates the necessity of user-focused design is in software projects. All the better if you can find someone who specializes in it.
UX expertise brings:
- deep experience reasoning about the way people use things
- knowledge of many workflows, working styles, and personalities
- understanding of how much deviation users will tolerate
- familiarity with user research techniques and their shortcomings
- ability to distinguish between research signal and noise
- knowing where to dig deeper or seek more data
- understanding what needs to be prototyped vs. mocked up vs. textually described for tests, and ideally the ability to do all three
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…
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.