When Developers Dismiss Users
Photo by Kyler Nixon on Unsplash
Software Engineers, like it or not, are dependent on users.
So, when our front-end developers got together with customer service to create a “stupid customers” Slack channel it really got me thinking. Why do we disdain those who (ultimately) pay our salaries, what damage is this doing to our culture and what can be done about it?
The Importance of Delivery
If you don’t deliver both a great product and great service, you’ll get found out. This is as true of companies as it is of individual software developers as great software is a team activity.
Let me make this clear. Delivery of both product and service is essential to make great products.
My experience
I went shopping for a shirt recently. One of my favorite signs in a clothing store had the following:
No refunds
No returns
No trying
If you can’t try on clothes before buying, how would you know if they might fit? If a clothes store doesn’t care whether their clothes fit customers, they don’t care about their customers.
I think this is much like software development. If the software doesn’t fit the user, it will not be worth a dime, much like the clothes in that awful store.
User Dismissal
How Software Developers Dismiss Users
It’s quite unfortunate that there seems to be so many ways that software developers dismiss users' opinions.
Here are some I’ve seen in my experience:
Ignoring Social Media Feedback
Some key functionality isn’t working on our product. For a year. Our customer service team recommends that users clear their cookies — it’s not going to do much good as this functionality is simply broken.
We “didn’t know” about this broken feature, but there are hundreds of instances of users complaining about it. Go figure.
Seeing the World from Our Perspective, and Our Perspective Only
When we design features, we look at our technical capability and intention rather than what the user might require from a feature. That means our software doesn’t support minimum accessibility requirements (despite a failed accessibility audit), customer journeys are illogical and basic functionality is either broken or entirely missing.
Our customers are at the bottom of the food chain and boy don’t they know it.
Why Software Developers Dismiss Users
For both software development and my store example above, I feel there is a level of disrespect for customers.
At the heart of this (I’m sorry to say) I feel there is a spirit of superiority within the software development community. Software engineers often feel that they are somehow better than colleagues, this goes double for the end user.
Damaging Software
Culture, what Culture?
“You’re doing it wrong” is unfortunately (and tragically) still a thing in software development, and we all suffer as a result.
I don’t think it started with Steve Jobs, but the arrogance of software developers thinking that they are a class above users is a longstanding issue.
In my experience users are often spoken of as “not getting it”, or our development team expresses surprise about the way that the software is used in real life. We push back that things are being used in the wrong way.
Weakness? What Weakness?
It’s difficult for software developers to express weakness. This pressure comes partly from the adversarial interview process
Software developers seldom admit weakness, as the pressure to be smart and a 10x developer leaves little room for learning or development. Admitting customers might have the answers puts software developers in a vulnerable position in many organizational cultures.
This is a problem because customers generally have the answers to the problems we face as software developers. Problem solvers should look for solutions from anywhere they can, rather than thinking that they automatically have all of the answers themselves.
The Solutions
Listen to Your Users
There are many channels where a user can get in touch with developers. So, are you checking those social media feeds? Listening to reports from your support lines.
Even better (and more obvious) are you dogfooding your own software, which means using it yourself? If you’re actually using your product in-house, you’re more likely to be able to surface issues that you might have and then importantly — resolve them
Get Involved
If you are logging your FE crashes, do you blame the device the user has? Or their weird behavior?
Or do you take these signals that something needs to change as sign to, well, change something?
As a software developer we can get to the heart of issues and actually solve them for our users.
Conclusion
Come on people. We can do better.
Listening to your users gives us signals about how we might make things better. Why would you turn that down?