[superice]

This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers.

We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incredibly important when designing new screens and workflows, it's baffling to me that developers aren't taken on-site more often.

[duxup]

I think that's valuable, but depends on the organization. At a company I worked at engineering used to go on customer visits, but the "customers" were the executives and managers who make buying decisions and put forth requirements. However, these were not the folks who actually used the product. Their opinion was important (gotta sell it) but it was NOTHING like what we saw in support.

The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.

But support is where the rubber hits the road and folks actually encounter real issues that they can't solve on their own and create real pain points that will come up.

In my example there were still a lot of issues we'd take back to engineering and they'd say something that amounted to "but they said they don't use it that way" and it was a real chore to get engineering to understand the difference between what an executive asks for / some of the requirements they were given, and what the real user does / needs / asks for. Understandably engineering resources were sometimes irked by this, and support often took the hit politically because of it. It was one of the reasons I got out of support despite getting along with the engineering teams really well.

[hobs]

At the last company I worked at they brought glad handers to take care of the execs while I the "low level tech" went around to people's cubes and spent 2-3 days talking to them, understanding their requirements (usually with NO meetings, just 1-1 after talking with their managers and leads.)

This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave about the product (because their entire staff was so surprised at someone giving a shit.)

I was quite impressed by my head of product's subterfuge, she was incredibly talented.

[WorldMaker]

At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so unhappy with me though for breaking protocol.

That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.

[Aeolun]

Yeah, going directly to the end user is almost certainly best. The amount of times you find people spend 2 hours of their days on what would be literally a 5 minute fix (my favourite being the select with a thousand options that wasn’t alphabetically sorted) is mind blowing.

And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.

[froindt]

I love finding those high impact, straightforward changes! I support dozens of spreadsheets at work and am the person people call when one breaks.

* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.

* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.

* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.

[BostonEnginerd]

Every company needs one person who can make simple changes to inefficient business processes and save a ton of time.

[WorldMaker]

Similar to the "users request crazy stuff", managers of users request crazy stuff based on what they think their users need. Stuff that goes up and down two very different reporting chains (up the users' then back down yours) is almost always going to be some weird telephone game crazily divorced from reality.

"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.

Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)

[HenryBemis]

I remember back in my sys-admin days, when a vendor would come in, we would 'kidnap' the devs/engineers and keep them in our office, while he C-levels/Directors spent time 'discussing business'.

At the same time we were giving the devs/engineers a taste of what the requirements should REALLY be, or what the problems REALLY were. That gave them a far better idea of what our pain-points were.

It happened that devs/engineers, while in the presence of theirs and the customers' C-levels/Directors, they only smiled, nodded and agreed, which is kinda dangerous as they were forced to agree on insane, intangible, and unfeasible requirements.

[superice]

Yeah, absolutely, we see that all the time as well. We have the benefit that usually we only have to do sales at the executive level, and for everything else we deal with the operations people, which means that if we go for an on-site visit we usually won't meet higher management than operational team leads.

We learned that what executives say and what operation does is not the same thing, which is why we sell our software we say: "We'll fix your problems, but be warned: we won't do it your way", and as long as that expectation is maintained we have very happy customers.

[massivecali]

I've worked on several projects where the actual needs would get distorted between the customers and the developers in a perverse game of telephone. Each producer or manager feeling the need to reinterpret as they saw fit.

[duxup]

My most recent job the head of the company had a great comment. One of the first things he told me "Our end users are not smart, no matter what anyone tells you. They can barely use a computer. Remember that."

He wasn't wrong ;)

[MBCook]

I HATE that attitude. It may occasionally be right (depends on your product/intended use) but it was the catch all ‘do as I say’ excuse one of the executives used at a previous job.

Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about.

Of course if THEY want to do the complicated hard to understand thing, it will be fine.

Just one of MANY examples.

Why do the job if you have actual contempt for your users?

[duxup]

>Why do the job if you have actual contempt for your users?

It's not contempt, it's understanding who is at the end of the keyboard.

In this case our customers are fairly capable, but the software is really for their end customers who are in a niche industry that is AMAZINGLY behind the times in terms of technology, and the people they hire who actually end up doing a lot of interacting with the software are honestly barely high school grads and are surprisingly incapable / startled by anything out of a very specific routine.

[ox_cable]

> Why do the job if you have actual contempt for your users?

To... To get paid, isn't that obvious? Sometimes you have to do what you have to do.

[Aeolun]

I mean, yes, in retail or the service industry, but it should be possible to find a job in IT where you can at least tolerate the end users (or just never see them altogether).

[TeMPOraL]

Seconding MBCook here; I believe this advice is nonsense.

Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job.

Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're worrying your product could make the wrong first impression (and probably not on users, but the managers), and thus not get bought. It's a valid priority for business, but it would serve everyone better if people were up-front about it.

[duxup]

>Truth is, most people are smart enough

I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.

[flukus]

> It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should

That's a managerial problem not a technical one, so any technical solution like dumbing down the user interface will almost certainly fail.

[zerkten]

Is this a question of redesigning your visits to incorporate your real stakeholders? There are many companies with management and workers at polar opposites like this. I've seen this tackled by proposing that you offer some on-site support sessions and bring support and engineering along for the event.

Focus on making management at the company feel like they are doing something for their deployment and get more forthright feedback because they can't be in as much control. Establish some direct follow ups, if needed, to primarily tackle the support issues, but ensure the folks who were on-site are part of that conversation. Present a summary of the event back, including action items which you take from the event alongside their pet problems/requests.

[acrooks]

I work at a company where most of our contracts are for larger enterprise businesses and, as a result, we have a training component to our launches.

As much as possible we try to bring a person from Product (dev + design + PM) to be involved in the launch project. The benefit here is that the product team gets direct access to the users. And they get "early access" to the challenges our customers face: in the early days of using a new product, the issues shine very bright compared to later when the users have found a suitable workaround. This has and will certainly continue to be essential to building empathy between the people who build the product and those who use it.

[onion2k]

At a company I worked at engineering used to go on customer visits, but the "customers" were the executives and managers who make buying decisions and put forth requirements.

Developers should meet the customer organisation to talk to users. If you're not talking to users you're not getting the most useful feedback.

Where I work we often supply software to other software companies, and our UX team goes and visits their customers to get insights about how our products are used.

[Spooky23]

Agreed.

I've seen many a time where the customer interface contacts believed whatever bullshit that they were peddling internally, and the information we had was essentially completely wrong.

Vendors walk a fine line with these issues. You have to keep the bullshitters happy as they control the money, but you need to get shit done to keep the golden goose producing when sponsors get promoted/fired/held accountable.

[blablabla123]

> The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.

Actually I worked over 2 years at a company developing in-house tools. For almost all tools/projects I talked directly to the end-users. 2 observations:

1) users become greedy when it comes to features (especially those users in supervisor/manager positions)

2) there's a tipping point with amount of desired features when users actually start preferring to use the newly developed software instead of a previous solutions

[hello_tyler]

I think when you say users become "greedy" it's that they don't truly understand the depth of the problem they want to solve. It's not that they are in a true definition sense of "greedy", but ignorant about the cost vs benefit analysis. If if was explained to them it would take 20,000 man hours to solve their issue, and then it would put them out of a job, most of them would clam up.

[systemtest]

I worked at a first-response call-center company where after each shift, they would go through the records that they processed that shift and manually count the number of high-priority incidents and various other metrics. They did this after each shift, taking about 15 minutes. For the last three years.

After my field visit I took it to the PO and we implemented these metrics in one sprint. With a single click they could print all import metrics about the last shift.

[paulcole]

Sometimes when you automate this stuff away, you lose the value of manually reviewing the data. Just seeing a metric isn't the same as reading through the logs and seeing what actually happened.

[arendtio]

Once I got two developers to use their software on the live system. As a result, they fixed a few bugs which didn't appear on the dev systems as those were being run with much smaller data sets.

When normal users had to wait 20 seconds for a page, they didn't like it, but it was completely possible that the system just was that slow. But when the developers had to wait 20 seconds they used the time to look up what took so long and found minor bugs which caused the slowdown and fixed them right away.

As a result, the developers asked to be given more opportunities to work with the live system.

[AlexTWithBeard]

shaky 90 metric tons weighing machine, handling 30 metric ton containers

Also gives an immediate answer to all these "should we fail gracefully or crash loudly?" arguments.

[Aeolun]

Yeah, that sounds like the most fun place to crash loudly ever.

Just a small failsafe to ensure nobody is nearby.

[taurath]

It took me quite a while to unbind the commonly used abstraction of containers with the real objects :P

[fatnoah]

I think one of the ways working at a startup benefited me the most was having to cover the support lines when our support guy was out. I got to interact directly with many customers and learn how they _really_ used the product, what was confusing, what wasn't, etc.

[barbecue_sauce]

This is what UX Researchers are for.

[tracker1]

Agreed, as a developer, I'm often asking to see the production environment for the users I'm building for. Even if it's a new application it's usually replacing something existing and understanding that is huge.

[8note]

sounds like you make apps to help logistical actors to drop their phones.