> This might be okay for consumer apps, but maddeningly, the same doctrine gets applied to enterprise applications as well. I've literally heard non-techie employees of a Fortune 100 company ask for their legacy green screen terminals back because the new, flashy SPA was slowing them down.
Applying general design principles without taking actual use cases into account is the worst.
A common one is putting heaps of whitespace around each cells in a table. Visually appealing, sure. But unusable if I need to look at more than 8 rows at the same time.
Agreed. Most user experience work today are done by people who ironically have little experience as a user. E.g. they will design a table in Figma, make it look nice. They may even go so far as understand that this table will typically contain 2500 rows and introduce pagination and filtering by most commonly used attributes. But if they load some sample data into a functional mock system and simulate a typical user's day (e.g. they have to wade through this table multiple times per hour, while on the phone with a customer), they will immediately realize the feel good factor of white spaces, pastel colours and high contrast icons are very low priority.
You forgot one awesome feature of those SPA: once your user finally manage to get some muscle memory in, you can push a new UI redesign so get them back to square one. Because you have to give work to do to your frontend people.
> Most user experience work today are done by people who ironically have little experience as a user
So many upvotes for this. While the provided thing might technically work, if it is clunky for the users, the users will not like it. I understand those making the thing will probably never use the thing. The problem comes when those making do not listen to those using. There have been many times where I've made the thing, but then when I went to use the thing I wanted nasty things to happen to the person that made it. I've been in some very contentious UAT rounds where I was the user and the devs refused to listen to valid complaints.
The funny thing is that a lot of those problems are known during development time, by the people who have to actually "use" the product at all times during development, a.k.a. the developers.
Not sure I follow. The situations I've built appear fine during testing during development. I go to the UI, click the buttons, get the correct result. Test complete.
The type of thing I'm thinking about is when the user does that many many times in a day, but to get to the button that is on one part of the screen which is very inefficient compared to if the button was moved closer to something else so that the UX is improved. Sure, what the dev did "worked", but it might not feel clunky when you test it once or twice. That's the difference that drives most UX<=>Dev disagreements.
Dev: but it works
User: yes, but it sux using it. it can be better for us if change X, Y, Z
Dev: but it works. ticket closed
It doesn't matter if it works while everyone hates using it. I don't care what the devs think. If the user's request is reasonable, rational, and will improve the UX, stop fighting it. This situation is precisely my experience that happens when there's no designer.
I'm talking about bad designs. Grandparent mentions Figma, this is who I'm talking about.
Developers have to work on the app the whole day and they know when a design is bad for long term usage. Either by doing manual testing, or even when automating it.
UX people dictating the designs will rely on instinct even when developers complain that a design is inefficient. Or even for visual design things like excessive padding getting in the way of making the apple useable. IME, YMMV.
If you're talking about inexperienced/unemphatic developers being in charge of UX alone: well, yeah, that will happen too.
Reading about whitespace on tables infuriates me so much.
At a previous job we had an actual good designer figure out what users wanted and she found out users wanted denser information. So she designed a more compact table. It was quite smart, used the whole screen, but still looked amazing and didn't feel cramped.
Then my company released it as a library for the whole company to use and the first thing one of the product managers did was requesting margins AND frames around it, plus a lot of whitespace between cells.
Now instead of displaying around 25 items on the screen at a given time, this other system can only display around 10.
The cherry on top: it looks horrible with the frame and with the unbalanced margins.
Applying general design principles without taking actual use cases into account is the worst.
A common one is putting heaps of whitespace around each cells in a table. Visually appealing, sure. But unusable if I need to look at more than 8 rows at the same time.