[hliyan]

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.

[arkh]

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.

[dylan604]

> 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.

[whstl]

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.

[dylan604]

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.

[whstl]

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.

[dylan604]

TFA is about not having a designer. If you have a bad designer, then fix that glitch.

[whstl]

Once again: grandparent post says "e.g. they will design a table in Figma, make it look nice", so I was answering in that context.