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.
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.
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
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 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'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.
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.
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 ¯\_(ツ)_/¯
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...
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?
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.
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".
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.
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.
> - 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.
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 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.
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.
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.
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.
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 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.
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.
> 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.
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.
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.
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".
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.
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
90 comments
[ 0.22 ms ] story [ 179 ms ] threadProgrammers 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."
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.
Overly broad, but pretty much my experience on projects that aren't mine
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.
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.
(That's what Apple used to be particularly good at, once. I'd also argue, software has become quite bad at this, recently.)
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.
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.
See my other comment: https://news.ycombinator.com/item?id=24760150
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 find it irritating to be criticized for a design that's meant to be a placeholder.
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.
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?
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.
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!
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 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."
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".
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.
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.
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.
- 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.
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 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.
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.
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.
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.
You probably need at least some of the first, though, because the second one takes real effort.
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.
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.
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.
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).
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.
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".
I'd really like to. Management rarely lets me. When they do, they don't take my advice.
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.
There are many many examples where single-developers create projects with great UX . They don't suck , in general