4 ms·
Having worked almost exclusively in customer-facing roles for software companies for the last six years, it doesn't surprise me at all that a developer would be
by smeej 3y ago
Having worked almost exclusively in customer-facing roles for software companies for the last six years, it doesn't surprise me at all that a developer would be surprised by this story.
As far as I can tell, the number one rule of being a UX or UI specialist is that one must never, under any circumstances, actually talk with a U, nor consult the team whose job it is to assist U's with the X the designers and developers swear up and down is so intuitive it should never require explanation.
Most applications are still horrible and unintuitive to the people expected to use them, especially when they're built for niche users. This is the normal experience of using software as a non-developer.
Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback in a way that anyone in the company will care about, but support agents "aren't technical," so the developers don't think they could possibly have anything useful to say about their work.
It's a vicious circle. It doesn't have to be this way. But I'm all put of ideas about how to change it.
- oezi 3y ago> But I'm all out of ideas about how to change it. Instead of stand-ups let developers spend 15 minutes each day in a call with a customer who has a problem or feature request.
- loa_in_ 3y agoI would absolutely very much appreciate it as a developer, because nowadays,the motivational structures put in place rarely do anything for me but this would be a great: problem -> effort -> feedback -> closure -> motivation; loop element
- hgomersall 3y agoIsn't this sort of the theory behind scrum - having rapid feedback loops with the product owner that is (supposedly) the one that has the deep necessary insight into the problem?
- oezi 3y agoProduct owners are not real customers. Extreme Programming got that part covered much better.
- smeej 3y agoI've tried pushing for that idea to my manager at least quarterly at each of the last three companies I've worked for. Manager always agrees it would be a great idea. Engineers are never willing to do it.
- oezi 3y agoEngineers wouldn't never be willing to do standups or interviews if given a chance.
- Thlom 3y agoIn a previous job I did support in a very niche business with very niche software. The job sucked in most ways, but the positive thing was that if we discovered a bug or noticed users didn't understand the workflow or whatever we could send an e-mail directly to the sole developer of the software. As long as we explained the problem it would be fixed or changed within reasonable time.
- smeej 3y agoThis does sound nice. My experience in startups has been that improvements or bug fixes are often ignored in favor of projects that have some long-shot possibility of increasing revenue, even if the existing customers threaten to and do leave over the bugs and hate the new features.
- matkoniecz 3y ago> But I'm all put of ideas about how to change it. At least occasionally look at how actual users are using software?
- smeej 3y agoIf you can come up with a way to make the developers actually do that, by all means, please suggest it.
- matkoniecz 3y agoAs developer on one of open source projects I simply decided to spend time on it. In case of paying for software system I would require it as part of a contract. If I would be decision maker on software project I would also demand it.
- fphhotchips 3y ago"We have replaced the old UI with a new UI. You're going to love the new UI, we promise! But, just in case, you can still have the old UI." "We notice you're all still using the old UI and talking about how bad the new UI is when it's actually great! You don't need those features that aren't accessible from the new UI anyway. We're going to default everyone to the new UI now and you'll have to manually change the setting back if you want to." "Ok you're all still using the old UI, even though the new UI is obviously better, so we're going to turn off the old UI at the end of the month" "Oooooops! A bunch of people said they'd stop paying us if we turned off the old UI so we will now keep the old UI on until the end of the year" "The Old UI is gone now. Where did all our customers go?"
- SAI_Peregrinus 3y agoThe UI is an API to the user. UI changes are almost always breaking changes and should be considered new major versions of the software.
- friend_and_foe 3y agoThis is the best I've heard it put. People dismiss complaints about UI changes wity the argument that the UI isn't better, people are just used to the old, worse way of doing things. And when that's true, which it isn't usually but sometimes it is, what you said is of paramount importance.
- pif 3y ago> Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback In my personal experience, this only happens after the development. We have found no way to obtain useful feedback during the design phase.
- smeej 3y agoGive your support agents access to a functioning dev version. They'll happily tell you dozens of things they're going to have to explain to the customers, and find dozens more ways to break things.
- pif 3y ago> Give your support agents access to a functioning dev version. Exactly as I said, it's already too late. For it to be most effective, such advice must arrive before I start coding.
- hgomersall 3y agoSpeaking from my personal position, I spend most of my time writing software and firmware for a product that we designed to satisfy our internal needs and which we have now developed a product. This is in a deeply domain specific area. I make decisions daily that have quite far reaching UX/UI consequences and even with about as deep a knowledge of the user domain as its possible to have (or perhaps because of that), I agonise over those decisions. I pity anyone trying to work on this kind of software without that direct first hand domain specific knowledge. You either implement the spec as-is, filling in the gaps by guessing or you get super stressed by the lack of insight - neither is a good place to be. Probably the solution is to have the developers get as deep an insight as possible into the problem area they are trying to solve, and work very closely with users at every stage.
- croes 3y agoCould be because the Us have contracting and sometimes oxymoronic requirements. Some even expect magical abilities from software to turn bad user data in correct data without any work by U. Address data comes to my mind. Or I want to see all data at once but why does it take so long and doesn't fit on one page and is incomprehensible?