[undoware]

[pulls up chair, sits backwards]

OK so this is a question I'm arguably qualified to talk about -- I focus on usability and promoting it within a large tech company.

The problem that I see a lot is that engineers are not well-versed in what I will call 'imaginative empathy'[1], which, as I define it, is the ability to creatively conceive of end-user needs by reflecting at length on who those people are, what they desire, and what they expect, _even when the end user is a very different kind of person than the developer_, with different strengths, weaknesses, and expectations.

I'm at this moment setting up an internal programme to try to beef up imaginative empathy among engineers. My premise is that imaginative empathy is actually not hard to train for -- people in helping professions (counsellors, therapists, social workers) get pretty good at it, as do novelists; but, like any muscle, it can atrophy, and it is emphatically not something that is tested for in most interviews. Therefore, since it is not selected for, it is often not in abundance on any particular engineering team.

A book that inspired me in this approach is _Anthro-vision_, by Gillian Tett, which is a gift to anyone who makes anything for another human being, and wants them to enjoy it.

1. Empathy on its own isn't enough -- people tend to empathize most with people who are most like them. Sometimes this is enough on its own -- if you're a neovim obsessive (like me :D) and you're making an extension for other neovim obsessives, you can run on just regular empathy. But most of the code I write is not written for 'people like me', it's written for people in the general case, and that means a cognitive stretch. Imagining the Other and attempting to be of service to them requires imagination. I'm inspired in this observation by Buddhist 'metta' practice, and the ways in which the Buddhist conception of 'compassion' differs markedly from what is often called empathy by contemporary professional psychologists.

[analog31]

These are some good insights, and I'm glad you're doing this work. And part of putting yourself in the mindset of the user is understanding that in many cases they are not using your software by choice, but because it stands between them and something that they need, such as a job, health care, personal finances, use of their car, and so forth. Often these things happen under moderately stressful circumstances.

[mbrodersen]

The problem seems to be the product managers. Not the software developers. It is the product managers that prioritise the features to be implemented and the UI to go with it.

[undoware]

On paper, yes, this is how the business works.

In practice, I've seen lots of situations where, for want of time and designers, engineers received vague instructions and were mostly left to their own devices.

Engineers were making significant contributions to the design process without noticing; and many of them were, as you might expect, not thoughtful. After all, the coder was being paid to code, right? Not their job.

You might argue that we could fix this by hiring more designers (you should anyway, but not for this reason). But without engineer understanding, you may wind up with a design team micro-managing a team of engineers.

To me, this appears to be a recapitulation of the 'architect-vs-tradesman' dichotomy seen in the building construction industry, with UX experts playing architect, and the engineers playing extremely-well-paid plumber.

Under these circumstances, no engineer wants to build anything unless it's been signed off in quadruplicate, complies with all extant regulations and guidelines, and is exactly like the last 10,000 ones like that we did. At this point, more or less, engineers and designers begin to resent one another.

It's a full-on zugzwang: The engineers begin to think of the designers as dictatorial and unrealistic dreamers who don't know enough about code, and the designers begin to think the engineers are callous boors who, yes, are hostile (or at least indifferent) to the expectable experience of the user. Which is what I take the OP was pointing to.

While other industries may be able to tolerate this kind of vibe, none of the habits of mind and culture that I just described are conducive to anything like a good UX outcome in software development.

Far better is to have engineers who are trained to make good empathic common-sense decisions. This is important for three reasons: First, it frees up design and PM cycles; second, it generates a culture where the engineer is respected as a conceptual contributor to the user's experience, and, thirdly -- and most importantly -- it creates a person who has both design and technical expertise, and can adjudicate tradeoffs between these two things without calling a meeting.

And this third point is important for some relatively deep socioeconomic reasons -- I disagree with Hayek about a lot of things, but he was right about the value of local knowledge. (https://en.wikipedia.org/wiki/Local_knowledge_problem)

An engineer who is in the code every day may well have a better sense of what is possible (and what the tradeoffs may be) than a designer who is not on the front line. That honey-mustard combination is lost entirely on teams where engineers are not also a little bit designers, and designers are not also a little bit engineers. Think of this strategem as a 'local knowledge reuptake inhibitor'.

Thus, the aim of my programme is to create a corps of engineers who, when they see something, say something. But in order to see like a designer, you need imaginative empathy. The heart is the eye.

[deterministic]

Yep I do agree with what you are saying. Developers are making lots of decisions every day that will impact the quality of the software. So the better they are at understanding and emphasise the end user, the better the software will be. However currently the incentives in most companies are not aligned that way. Developers are rewarded for fixing bugs and adding features. I will also say that dealing with users can be extremely difficult. Most users are reasonable, but it only takes a few self-entitled sociopaths to turn your work experience into hell. So I perfectly understand developers who avoid dealing directly with end users. Why risk the abuse when they don’t have to?

[bulatb]

Thanks for doing this and thanks for writing about it.