Why Software Developers Suck at UX | Hacker News Reader

Why Software Developers Suck at UX

cakewalklabs.com

63 pointsarvando84 comments

Some devs do lack empathy for users, but that's a trope with lots of professions. I think it's more...

1. UX is a skill you need to train separately from the rest of your engineering skillset and not everybody does. I strongly recommend "Refactoring UI" to get some fast training.

2. Not everybody does user testing where you sit down with new users and watch them use it. Until you've done that multiple times, you won't develop a good intuition for how people approach new software. I recommend this to everyone, just do it. It's an essential training tool as well as an essential product-development process.

3. Every project is driven by competing feature ideas, often in an exploratory way. Everyone has feature requests, and engineers often think in terms of exposing knobs to adjust because they want to expose the underlying power of the system. The problem is, humans have a very limited budget of concepts they can take in from a UI, and the information architecture of a UI is holistic. "Just one more feature" can throw the entire thing out of balance. This factor alone makes it easy to make bad UIs.

I'd add:

4. Not everything needs to be a minimalistic sleek Webapp. All of this depends on who your target audience is and on which level they want to deal with the problem. A minimalistic UI isn't automatically more or less powerful than a complex one if it combines well with other tools. To make every part combine well with the other parts to get out more than the sum of the parts is worth it, but find the right degree of minimalism vs complexity.

5. Make sure you waste the cognitive energy of people by having them figure out the same things over and over again. Rhe work of programmers multiplies: if you make one tiny thing a little bit nicer, it might make a hundred moments on a thousand days for a thousand people nicer. Same goes for making things that suck. So things should be obvious — if they are not (e.g. because the underlying problems are hardcore) make sure your software reduces the cognitive energy needed to solve that hard problem. Never claim that a hard problem is simple unless you really managed to simplify it.

I'll add:

6. Not every software project even has a UI

7. Some software projects have a very specialized set of users or barely interact with users and solve very technical problems or data problems (the software I work on now runs 24/7 in perpetuity, and as long as it works, they interact with it only once).

> 4. Not everything needs to be a minimalistic sleek Webapp. All of this depends on who your target audience is and on which level they want to deal with the problem. A minimalistic UI isn't automatically more or less powerful than a complex one if it combines well with other tools. To make every part combine well with the other parts to get out more than the sum of the parts is worth it, but find the right degree of minimalism vs complexity.

It doesn't have to be sleak but minimalist ! = sleak. A UX designer makes things minimalist while a UI designer makes them sleak.

A minimalist UI is a strong sign that care was put into abstracting away unnecessary and complex features that most users do not need - which is the job of a UX designer.

I think this only works for certain classes of applications.

Applications that professional users use do typically need lots of features, no matter how you present that. The idea of "most users don't need this" is misguided because while most of the functionality won't be necessary for most users, users don't necessarily agree on which features they will need, every one of them requiring a different subset of the features.

Just take something like a sheet music composer (something like Sibelius, Finale or Dorico). There's no way in hell you can just strip out a significant chunk of the features because doing that would totally break the product for many, many users (incidentally, the YouTube channel tantacrul has some interesting videos about UX design in this space - not affiliated). Word processors, IDEs, etc. share similar fates.

Frankly, I'm often annoyed when some programs pretend that I don't need some functionality and prefer to present their minimalist UI to me that doesn't let me do advanced stuff. A lot of macOS software IMHO suffers from this problem which is maybe great if you just want a barebones e-mail reader, say, but then you get something like XCode which doesn't even have proper refactoring support because "look at how complicated IntelliJ is".

> Not everybody does user testing where you sit down with new users and watch them use it.

I'd really like to. Management rarely lets me. When they do, they don't take my advice.

I have a theory. I have been designing software for 9 years. I have been designing Developer products for the last 4 years of my career. Let me tell you something. The developer experience is one of the toughest and roughest experiences for anyone who uses software.

From installing a library, to browsing logs. From reading documentation to deploying code. Everything in the developer experience is mined with obscure processes and seemingly impossible to achieve tasks. Every developer eventually figures out a mental framework to work around this experience and consider this a skill that it's part of what makes them good at their job.

Of course developers are very smart, so why they "suck at ux"? The problem is that when your tools and processes are full of bad UX patterns you never get an opportunity to really learn and analyze how well-designed professional and productivity software works. I can't tell you that 60%-70% of the things I know come from using software (many times using it for the sake of learning its UX, not because I'm an actual user). Basically, exposure is key and this is why there are UX designers that also suck at their jobs.

Developers are trapped in this loop. Homegrown tools rarely include input from designers. Startups in the developer space rarely prioritize design hires. They can only build and try to improve what they already know, so the progress in developer experience is very slow. Any progress depends on companies like Microsoft investing in design. For example Visual Studio Code is a wonderful developer experience in my humble opinion. But it takes more than a good IDE or text editor to create that instinct to identify what's good or bad UX.

I wouldn't say that developers suck at UX. They are just not very good at articulating their UX ideas, but some of the best things that I have designed even outside of the developer tools space, came from a developer idea.

I like this take, and also add that is perpetual:

You start with some objectively bad things like bash/terminal/c/c++ and then the tools get replaced with js/electron/etc. From bad to other bad. So giving options, eventually as developer you settle with the less bad or the already understood option.

RARELY you start from good, then move to better.

---

P.D: I see this in other fields too (ie: That run in a circle of bad to bad...), from my own customers.

My UX skills are bare (I align things, use 2-3 colors max, and some typography that is barely decent, and point when logos and icons are terrible, and have the sense of just use one made by designers...).

In one app, I just deploy bootstrap as-is with slight increase in font size and base. That was all. I still get kudos for that!

I really like this take. I was mulling around a thought and I feel this might be a good place to validate it:

So I was talking about this with a friend, and I believe that there is an inclusivity to UX that most engineers don't seem to care about or have the patience for. A technological Darwinian mindset where if you don't get it, then you don't get it.

The UX designer holds everyone's hand as they run. The Engineer is the person in front telling you to keep up.

I think this appears to be 'blaming' the engineers, pointing to a lack of patience and so on. The parent idea seems closer, techies get used to working with technology-led tools and solutions, so rarely (less often) get exposed to usability best-practice, for them to consider that as an input requirement.

I agree. The assertion in the article that "when engineers are developing products strictly for other engineers...their UX is fantastic" seems way off, at least from my experience.

I think one of the problems that no one has mentioned yet is that developers like to think about things in logical absolutes, which doesn't work well in UX, which is a more holistic field. In UX, there are always trade-offs.

For example: - Adding features to a UI could help support more complex use cases. - BUT the new complexity might using the core functionality harder. - OR we could refactor to a different conceptual model that intuitively supports all use cases - BUT this shift could totally confuse the existing users who are used to the old model.

The only way to solve these sort of problems is to collect information about all the tradeoffs, make a judgement call, get the change(s) in front of users, and iterate.

Unfortunately this isn't always how internal dev tools are built. I've seen entire systems planned and roadmapped following some abstract ideal like "consistency" or "flexibility" and built out over months or years without ever really consulting the users who will be using the systems. Concerns about the system being too confusing are dismissed because "we'll just add documentation in confluence."

> I think great UX designers just grew up naturally having much more empathy towards others and having a much better ability to place themselves in others shoes and see the world from their eyes.

If UX designers are so good at empathy, how is it that I, as a developer, keep having to point out that

- making links show up as buttons and vice versa is bad UX,

- mixing heading levels willy-nilly is bad UX,

- bringing in a giant JS framework to make sure a single type of input field works the same for a single buggy browser + OS + device combination (Firefox on Android on Samsung S-something) as for the others is bad UX, and

- basically, how making every new website look and feel different from every existing website may be good for showing off your designer skills, but it has always been bad UX.

From the outside it looks like "design" and "UX" are about as antithetical as "security" and "convenience".

Isn't the motivation for arbitrarily unique design to stand out? To look like you aren't just another commodity web site and product?

Standing out visually is helpful for branding, but the unique designs that succeed usually occur when presenting the relevant data in a useful way. So understanding helpful mappings is key.

For example, I switched to iTunes when it was first released on Windows mainly because of the “artist | album | song” as a row of lists interface. It wasn’t a new interface: Smalltalk used something like it for code, and OSX had it as a display option for file browsing before then too I think. But it was such a big improvement over Winamp for quickly finding the album or song I wanted to hear. IIRC Winamp at the time was a direct map over folders, and they were just vertical trees. When I switched, I had to do a bunch of tagging, but it was still worth it. If iTunes had used a gmail-like “tag and search” interface, I don’t think it would have been as compelling. I’m still waiting for something like it in Windows Explorer.

i believe that inteface is called 'miller columns.' didn't realize what i was missing til i used the OSX Finder.

This. I almost see an anti-correlation, where the worst UX sites spend the most on UX designers -- I find FB and Quora a pain to use, while the easiest sites are the hacked-together bootstrap ones or the ones that never left the 90s.

Brief examples: Quora on mobile has the user-hostile floating headers and if I switch to desktop the text is impossibly small. FB takes a long time to load on comments I click from my notifications, and recently forced the switchover to the ugly redesign.

I've seen someone put it that way, and I agree: developers are often to blame for mediocre UX, and designers for downright terrible UX.

> - bringing in a giant JS framework to make sure a single type of input field works the same for a single buggy browser + OS + device combination (Firefox on Android on Samsung S-something) as for the others is bad UX, and

This is a business solution, not a UX problem. You've got a billion users. 0.01% use the buggy browser with the bad input field. You're losing $X per hour. The input pays for itself.

Your argument assumes that bringing in a giant JS framework has zero negative effects, but this should never be taken for granted:

- The framework may well be buggy for a small percentage of users who happen to this time not include someone vocal. Result: you've lost users and you won't know it.

- The framework might be the straw that breaks the camel's back in terms of load times or cost. For some reason it seems to be rare to test for slow devices on slow, unreliable, metered connections, even though it's pretty much a given that the UX designers' devices and connections will be in the top 1% in all of these. Result: you've lost users and you won't know it.

Conversely I've worked with lots of designers who also suck at UX.

I think the first paragraph nails it. The people who are good at UX are the people who have the benefit of testing designs with users and iterating on them. Either for the problem at hand or with the benefit of past experience.

As an industry I wish we could get past the idea that your job title denotes your ability in one area or another.

Also, we need consider design as not something that needs to be trendy or has a finite time. A lot of design choices made in early 90’s are totally sound - technology has changed ofcourse so we should adapt but the way things are today - it’s chasing trends after trends without giving any thought. Design is not fashion. Changes should be made only when they’re needed, not because designers like a particular aesthetic or want to make things flat, or remove borders because it’s sexy, or go after magenta/purple themes today that are rampant cliches.

Have you tried searching for anything UX/UI on the web and only to find shallow articles, blog spam, nothing authoritative?

I have a hard time finding a good textbook in this area. Why aren’t there any textbooks one may ask?

This article is close, but misses the mark. Talking about how UX researchers must grow up having more empathy sounds like an assumption that's pretty hard to back up, considering I can point to plenty of software engineers that got into the profession because they want to build a better world for others.

I have a double degree in something that's effectively user experience. The one thing I heard in school over and over again is that when evaluating the usability of software, "you are not your user." In other words, you can never assume that your own experience with software is the same as the average user's experience. This is doubly true for software that you've written yourself, since you have an intimate understanding of the mental model that other people have to somehow acquire on their own.

I agree with you but want to point out that "well meaning" and empathic are not the same thing.

I'd argue, good (let's say) usability is about communicating the/a mental model via your interface. Is your interface up to it? Is the model stringent and concise enough to be communicated just by the arrangement of elements? It's a bit like world building.

(That's what Apple used to be particularly good at, once. I'd also argue, software has become quite bad at this, recently.)

Yup, I totally agree. If you can introduce enough of the mental model to your users for them to have success with your application, you've succeeded at interface design.

I think the word "empathy" is an overloaded term and was the wrong one for the author's point. Some people take it to mean "the ability to care about others on a moral level", and others take it to mean "the emotional intelligence to detect and understand the nuances of another's thoughts and feelings". I believe the author was talking about the second, not the first. It's entirely possible to be an idealistic and good-hearted person without having a shred of emotional intelligence.

Thanks a ton for posting that second definition of "empathy".

After battling with UX issues in the OP for a long time, I intuitively knew that there were 2 different meanings of that word (one very loaded and generic, another one way more specific and targeted), but I wasn't able to articulate the definition of the second one in my head (in a way that would make sense if I tried explaining it to another person) no matter how hard I tried.

Your definition nails it perfectly and fits in a single short and simple sentence that is easily understandable by pretty much anyone AND without losing any nuance or making the definition more vague. Really appreciate you posting it here.

Sure thing :)

For what it's worth I think the morally-neutral definition you used is more technically correct, it's just that it's gotten tied up with other cultural baggage. I'm also not sure I can think of another single word that does a better job of getting across the idea, unfortunately.

It would still be wrong to say that UXers as a class have more empathy, even under that definition. The fast majority of sites feel like they're giving me a middle finger, especially on mobile, and they tend to get worse on sites that invest more in UX designers. If I pointed a camera at my phone, and showed my typical use, I could a dubious decision or unnecessary hurdle every five seconds.

See my other comment: https://news.ycombinator.com/item?id=24760150

UX is too broad a term and it lumps together what used to be called "human-computer interaction", branding, web development, entertainment, and user interface design.

If we want to talk in broad terms about "experience", then a movie is an "experience"--entertainment. The redness of the red in the Coke logo is an "experience"--branding. Designing either of those things are naturally very creative tasks. But computers are interactive tools that need to be usable by people and those first two things just muddy the waters when trying to get humans to be able to use and master software, IMHO.

I'm an engineer and mostly I want to use software to accomplish tasks. I don't want it to entertain me or infect me with marketing. I would sincerely like to go back to drop down menus, rows of icons, and keyboard shortcuts. 20 years ago I crushed it using those things. Unfortunately the conversation has now shifted so that advocating for that is literally not even option. The conversation is about how much pretty doodads and innovative workflows you are going to subject yourself to. Software used to come with books written in natural human language that documented the entire thing--how you accomplish your tasks. Menus were written in a natural human language. You could read the words. The words told you want the thing did. Things were organized in a hierarchy, grouped by functionality. And help systems also could cross reference. It was searchable. All of that is gone. It's just throwing people in the deep end nowadays. Mrrff! They are all different, and I hate that. Any button has equal chance of saving my document, sending a missile to the moon, or silently deleting it all. And they're all written in iconese!

Well, anyway. I guess UX designers have more empathy for users, making them better people, or something.

/grumpy

Often my designs suck because I've been busting my ass to get the system to work and haven't had time/energy to take on the UX design as well.

I find it irritating to be criticized for a design that's meant to be a placeholder.

Lol... the number of times I've had my placeholders end up not just in the finished product, but on stage at keynotes in front of thousands of people...

Venting out a bit of past frustration, I would rename the title to "why people suck at explaining desired UX to software developer".

A kitchen designer won't be able to guess how you want your kitchen. It's my task as a customer to explain if I want a double sink, how big the induction stove etc. Why do people then expect software developers to magically guess intended UX?

Seriously, I asked people to draw me on paper a few pages of a webapp. It was pointless. I ended up making a bad UX, on purpose, just to get the conversation started.

A good kitchen designer should be able to ask a few questions to get you started, know what combinations of things go together, etc. The user is not the designer. They don't know what makes good design.

They'll know what they want but not where or how they want it. It might just be "a sink" and the competent designer will find out about their usage patterns to know number of sinks, size, style, colour, depth, faucet type -- and have it work within the constraints of the space. ...while also aware of the macro organization of the space itself.

This goes beyond UX: it affects API design, it affects communication within a team, documentation quality, etc. As a programmer who is able to put myself in others' shoes, it is deeply exhausting to have someone try to explain a new part of a system to me who doesn't have the ability to put themselves in my shoes. Leaving out key details left and right, foregoing analogies that in hindsight would have made things go so much more smoothly, phrasing things in ways that are very blatantly going to be ambiguous to an outsider's ears.

It's probably not fair to judge simply because I personally don't have that issue, but it's one of the most frustrating recurring experiences in my professional life.

Why do design people like light gray text on white backgrounds?

They don't. This blog is pretty badly designed.

Must have been designed by a developer

Because it's lovely. Designers usually have a pretty refined aesthetic sense, and sometimes it wins out over usability.

Yes, with all of the typographical aesthetic of something etched into granite. Reminds me of a tombstone, frankly.

I think that's the default theme on sites built with Squarespace.

Experts in something are rarely able to see it from an outsider's perspective. It's pretty much a universal for humanity. People who can absolutely do exist, in quite large numbers, but they're not the norm.

Maybe software gets targeted for this more often because a one-person (or very small company) project can reach a lot of users? Physical products need more money / manufacturing / staff to reach, say, 100k+ users, at which point they've got more than a tiny handful of people contributing to it. Or maybe it's just a fairly adjacent news bubble so we notice it more ¯\_(ツ)_/¯

I don’t think they suck at it anymore than UX professionals suck at it, e.g. gray text on a white background for an article I just read.

It is not egregiously gray on all devices. It is #575757 but is exacerbated by the choice of a lighter-than-normal font weight, so in that context it an odd call. You get a lot more variation between across screen densities and devices than most people account for when they make their favorite body font more stylish by reducing the weight. To say nothing of monitor color accuracy. I keep a mid-tier monitor with crappy colors at home to test things once in a while, and remind myself not everyone has an expensive laptop with a beautiful color-calibrated screen.

Setting font weight to just 400 (up from 300) made it easier on my eyes on the two devices where it was a very faded gray (I checked on three).

I disagree with the article's premises, and think a more correct analysis is along the lines of pfraze's comment, mixed in with unnouinceput's comment regarding time. Lacking experience in, training in, or predilection for, UX you can often still iterate toward a well-designed experience over time (and thus gain experience for the next situation). Being shuffled from one feature to another, or not being given context about the user, or the opportunity to develop UX skills (even incidentally within a project), leads to what seems like a lack of empathy, but is not.

Not enough exposure to real-world elements.

Every software dev should regularly try conducting a couple of five-minute user studies with 1-3 basic tasks.

It was just mind-blowing to realize, see for the first time, even though it had alwayws been there, the mind-boggling amount of extra crap there was in my UI, which was, totally unnecessary for basic use, confusing and unhelpful, etc.

I understand the need for power users as well, so I opted to create two basic "layers" of UI, along with a layer of brief helpful explanations of each control which can also be shown.

There's a lot of work to do, but I've had great results with both power users and novices alike with testing this interface.

I've worked as a UX designer, and I think the mindset required to solve UX problems is just different to that required to solve engineering problems.

For example: The engineering needed to have the user select, crop, adjust, and upload a photo is not easy. But getting that functional is just half the challenge. Knowing how to make the UX be easy is another domain of thinking. That's why we have different people doing different jobs.

For me the biggest issue with making a good UX when developing is primarily that, by virtue of being the developer making the thing, I have a perfect mental model of how the software works.

This makes it difficult to view the software from the POV of someone who is not in that position. It takes a conscious effort, and even then I find it difficult.

That's why I enjoy taking support calls every now and then, looking at screenshots or viewing the customer reproducing an issue over Teamviewer and having the customer explain what they think should happen and what actually happens. I might prod a bit, ask about why they do things a certain way, or to discover more about how they work and what they need our software to do.

Invariably I learn how we can improve some area of our application, making it more intuitive, less error prone or simply improve the workflow.

I think your statements are the nub of the issue - as a developer, the view is of how the software is designed and operates internally. Users don't (normally) have that same view. This is why 'Use Cases' and/or 'User Stories' can help cross the divide between what the user needs the software to do, and the technical details of how it may do it internally. Of course, Use Cases or User Stories don't easily capture the UI/UX aspects, which would come from a broader level of business modelling in the application/user domain.

One thing I noticed when coders (myself included) do their own UX is that it ends being optimized for testing the code.

I mean, the thing coders do the most with their software is to try it, test it and fix bugs. For them, the best UX is the one that gets them to their breakpoint as quickly as possible and reveals as much as the internal state of the program as possible. If you are doing coverage analysis, expect to see elements that serve no other purpose than to reach 100%. Of course, it is not a use case for the end user.

Even when they are also users, they know what their code is capable of, and will sneak in plenty of ways of accessing every function, that's extra features for cheap, but ones that require a level of understanding of the inner workings that regular users won't have.

I posted this in a thread below, but I think the word "empathy" is an overloaded term and was the wrong one for the author's point. Some people take it to mean "the ability to care about others on a moral level", and others take it to mean "the emotional intelligence to detect and understand the nuances of another's thoughts and feelings". But those are independent things, and I believe the author was talking about the second, not the first. It's entirely possible to be an idealistic and good-hearted person without having the least bit of emotional intelligence. Conversely, it's entirely possible to have lots of emotional intelligence and use it to manipulate people instead of help them.

I was just about to say this. Caring about another person's needs or sensing their feeling is one thing. Being able to set aside your own view, shift your mindset, and put yourself in someone else's shoes is another thing.

You probably need at least some of the first, though, because the second one takes real effort.

I don't think you even need to be able to sense others' specific needs or feelings to care about making the world a better place.

That's fair. You might do it just because of pride in your work or because you want the software to succeed. Maybe I should say that if making someone's experience better is meaningful to you personally, that adds to the motivation.

This feels backwards to me. Software developers suck at UX because they are too empathetic. Products get bloated because engineers get emotionally attached to the work and can't cut anything because there's always someone's feelings attached.

Meanwhile all the good UX people I've known have been either exceedingly impatient or obsessively narcissistic. The ones who empathize do so with the people right in front of them, their co-workers not the user, and end up compromising the product.

The person with an abundance of empathy is going to consider John's feelings when throwing out six weeks of his work. But stuff like that doesn't matter at all to the user.

> I imagine that it’s like when you’re trying to explain something technologically mundane in your world, say, Instagram Stories, to your grandma who can barely send email

This trope needs to go away. Your grandma might be Ada Lovelace, or any other uber technically minded person. Same with your mom. This is both sexist and agist. Notice how they never talk about 'your dad,' in this example, which I personally find hilarious because in my family my mom is the technical one and my dad has the most trouble with any technology. These are the kinds of 'microagressions' that I know first hand have turned women off CS.

Why shouldn't Software Developers suck at UX? It's like wondering why Doctors or Lawyers might suck at UX. It's a completely orthogonal skill set.

The same question reversed sounds completely absurd:

Why aren't UX people experts at low-level systems programming? Huh? What's wrong with you!? /s

Most software these days isn't even written for other humans its written for other services to consume, or to improve some other piece of already running software.

I think some companies tend to think of software devs as a one-stop shop. Like all you need to hire is a software dev and they can handle all aspects of the build. It would be like hiring a civil engineer to do everything, when in reality you need an architect, intertior designer, etc.

1) it's a whole other discipline 2) software is often made in a little enclave without outside input until the very end on how a user would interact, at which point it becomes a shoe-horned mess.

Overly broad, but pretty much my experience on projects that aren't mine

Because they don't actually have time to test it themselves 1000 times. I bet any developer given that time to test his own UX would improve it ten folds when he starts to get frustrated with his own design.

Data entry UX? Suddenly instead of having everything overwhelming a user you'd get only most used and then have an "show advanced options" button where you get the rest.

Charts? Show only important features then rest get hidden behind "show advanced options" button.

Reports? Menus to show only most common used reports, rest must go into "Show advanced reports"

And so on and so forth. See VLC player options, I think that UI is beautiful, despite it's myriad of options there.

Ergonomic and usability considerations are rarely valued because they do not have a cell on a spreadsheet. What is measured tends to improve. What does not tends to worsen.

Programmers have been driven to obsess about features to the exclusion of other criteria (security being a category with many examples) will not have had the freedom to experiment and come up with easier, more consideration workflows and interactions. This also means that they are not practiced at it. It follows that so-called (in the article) unicorn programmers are rare, perhaps because the environments in which they can get better are rare.

"Don't hate the player, hate the game."

This is interesting because I think the problem is about what is measured, not what isn't.

Have you happened to read the Tyranny of Metrics?

It talks about how we measure what is easy to measure, then use that. And once others know what we're measuring, they game the system. So the moment something becomes a metric, it ceases to be a good metric.

An article full and replete of generalizations. Is he talking about frontend engineers? Or just engineers in general? We could pick this argument apart sentence by sentence, but it just doesn't feel worth it.

That's not true. Where is the evidence? Comparing work made for a client to something that is an obvious labour of love is apples to oranges. When UX sucks its because (a) the client demanded so many incompatible changes that the dev loses interest in the project and (b) design-by-committee

There are many many examples where single-developers create projects with great UX . They don't suck , in general

I think one of the reasons is that "we don't train people on how to make UIs". If you look at when UI is introduced in CS programs, its as a visual example for Object Oriented Programming. However, its introduced and immediately moved over. The next time its used is only if the program has a specific course on UI development.

Because

- if the developer does the UX it's usually an afterthought

AND

- usually the UX forms the most difficult set of requirements to add to an existing system.

Because (almost) everyone else does, too.

For the same reason that just because you're an expert in one topic, this doesn't automatically mean that you're also good at teaching it. There's a reason educational science exists. There's a reason UX exists.

> I think great UX designers just grew up naturally having much more empathy towards others and having a much better ability to place themselves in others shoes and see the world from their eyes.

This is nothing more than a trope.

I like your explanation. I have a simpler possibility though... "No technology can ever be too arcane or complicated for the black t-shirt crowd." -- Linus Trovalds

Nothing beats the following during UX development:

1. early preview of customer requirements

2. Seat in their Physical operating environment

3. Silent observation and noting of their daily use

4. And an eye for streamlining their steps

It would seem to me that a good UX designer would be better at manipulating people. Not sure if that is the same as empathy.

The headline "Why Software Developers Suck at UX" is a nice example of the Bulverism fallacy

I see so many UX-related things wrong with the OP's website.

And I am just a software developer.

That was my first thought too. Small font size and slim font and grey-on-white. It's an unreadability hattrick.

Is this implying that somebody doesn't suck at UX?

Just no.

This article ended before it really started...

Agreed. I read the article after seeing some of the discussion comments here, then thought "is that it"? Claims about empathy, little else, other than the generalisation - which I think most of us agree with - that a lot of software UX is poor, and that this is being blamed on 'engineers'. Are there no other types of people involved in delivering software applications then? Who captures requirements, architecture, design, non-functional requirements, prioritises features for inclusion (or not), etc...

Cake What? Nice generalizations.

>But the reason I wanna mainly talk about is that engineers, developers, whatever you want to call them ... > I think great UX designers just grew up naturally having much more empathy towards others and having a much better ability to place themselves in others shoes and see the world from their eyes.

Wow, ok. So software developers (or whatever we call them...) grew up naturally to have less empathy for others, than UX designers...

It seem to hit multiple of logical fallacies [1]

I would like to ask the Arvand from Cakewalk Labs this:

May I also 'extrapolate' that software developers (or whatever we call them..) are not as good parents, spouses, care takers, friends, siblings, when compared to UX practitioners?

Are software developers also closer to displaying symptoms of the illnesses listed here (again when compared to UX folks)

https://www.mayoclinic.org/diseases-conditions/antisocial-pe...

While I am disappointed in authors conclusion and explanation, I think observations have merit.

In a typical project, objectively grading (if possible), contribution to 'good' UX of a final product, by somebody who has been full-time software developer for a long time vs somebody who is product owner, or a UX designer -- we will find that the software developer contributed less to good UX.

This could be because, software developers, when working on complex software, must be in the mode of optimizing and reducing, while maintain clarity, verifiable correctness (as it is, eventually, the CPUs that interpret the work of software developers, not opinions of end users...)

That mind set, does not directly translate on to UX work.

In my experience, software developer has to 'switch' the mind set so to speak. To value human interaction constraints, context in which software is used, guidelines and patterns for good UX. And this switch, usually, hard and expensive to do (in both time and effort).

It has nothing to do of how software developers 'grew up' and the levels of their empathy.

I would also suggest that incentives for software developers are different than for UX consultants. So it is natural, and perhaps business-inspired, that software developer would resist software changes that do not expressly address written requirements or bug reports.

[1] https://owl.purdue.edu/owl/general_writing/academic_writing/...

Things are, indeed, getting dumbed down too much lately.

This page has no empathy for my eyes. No contrast.

TLDR; The real answer is because they are first taught to code applications with a command line interface.

Composer/musician here. I think one of the reasons, as other comments have pointed out, that even designers sometimes (often?) suck at UX is because UX and the constraints of Capitalism don't mix, much in the same way that art in general and Capitalism don't mix.

UX is generalized optimization at the intersection of multiple specific needs. The software has to work, the appearance/disappearance of features needs to make sense within a workflow or many workflows (but probably without too heavy-handedly forcing a specific workflow). Features need to be discoverable, the UI needs to be information-dense without being cluttered. The application of the application needs to feel inseparable from the app's design. It's a tough problem, and unfortunately it takes a lot of time, trial and error, iteration, and refinement -- all things that Capitalism tends to not like, especially w/r/t things that don't clearly demonstrate a contribution to the bottom line.

If engineering is applied science, then UX is a form of applied art, just as music-as-a-job is. "Art" in this case meaning "something that requires a novel approach for each separate problem and can't really have too many rules-of-thumb or best practices applied to it without strangling the thing in the process."

The science -> engineering conversion, while fraught with its own problems, works because best practices are more readily able to be applied to logical problems. Optimization in this case is identical to Capitalism's goal -- to make more money in less time while spending less money -- so any and all optimizations in the realm of engineering tend to be met with open arms and a corresponding fatter bottom line.

Capitalism -- or rather, those that tend to run Capitalism -- expect that everything is like this. But applied art does not follow the same rules as applied science, one reason being that what works today may not work tomorrow. Styles change, novelty (something highly optimization-resistant) tends to sell. Every app needs a bespoke approach in order for its function to be optimally eXperienced by the largest audience of users possible. UX being a kind of meta-optimization means that, like composing and producing music, you're often discovering the thing in the sea of not-that-things that is the act of creation, sort of like sculpting. Every time I try to optimize the music itself or the process of making it (which is notably separate from the tools that I use to make it -- these should very definitely be optimized), I end up not reaching my goal of making good, impactful, novel music. Instead, I get what always happens when you try to optimize art: generic, uninspired shit.

Whereas every time I allow the process to be what it by definition is -- obtuse, messy, non-linear -- and stumble around in the dark, slowly discovering the "solution" (analogous to "the right approach" or something like that, in the case of music), I end up with a whole that is greater than the sum of its parts, full of thematic and conceptual connective tissue that is as invisible as it is essential.

Unfortunately, deadlines tend to disagree with the ivory tower approach.

This same phenomenon is my theory as to why so many apps break the "prime directives" of UX as outlined above -- they're somehow not information dense while still cluttered, seemingly essential features are non-obvious or non-discoverable, one way of using an app becomes preferred by the app's own internal logic (so, just in the same way that "the medium is the message," "the app is the medium" -- something that can really hamstring creative software for me), etc. On the design front, this tends to result in wasted space in the name of "minimalism," unimpactful and unopinionated color/type choices, and so on. The Windows 10 effect, in a nutshell.

You can't optimize design and experience like you can a supply chain or a pipeline. You just can't.

“I didn't have time to write a short letter, so I wrote a long one instead.” - Mark Twain

Reply on news.ycombinator.com