Why are web apps so badly designed from a user-friendliness perspective?

maybe its cause they get shitty useless feedback like the above "impossible to make it work" is not constructive. It's an utter waste of time. To read and to write. Man up and put some fact in your bitching.

I am not an UX expert, but idea of beta testers who aren't also developers is a solid idea. Even big companies fail on this. Recently I have written about it

https://hackernoon.com/users-are-not-programmers-amazon-expe...

Complex web interfaces aren't easy, you gotta do a lot of magic to make a browser be like a desktop app. I think most struggle in getting their concept to work in the first place, and when they get to ease of use it's a lot more work they may not want to invest time in.

Given web limitations you cant just do the same UI as a desktop you have to be mindful of web browser input idiosyncrasies, screen size limitations, etc.

I've written intranet database stuff, which can be a bit a tad rough and user intensive - but when you are doing more public facing things you have to concentrate on simplification, sanity checks, added security and cross-platform issues. That stuff doesn't always come easy.

Until you get a handle on how you are going to pull-off doing X on the web you can't think too much on how to make it work easier. I think you would see better UX when you have seasoned web developers doing the apps, as they understand the environment and can now also concentrate on UX.

HCI is more of art than science. That's why UX/UI engineers have their own title, not just "web developer".

I think that things are easy and intuitive for the designers, not so much for the user that tries the app for the first time. Devs don't see the problem. Moreover serious qualitative research is expensive and difficult to do. Finally it is hard to actually apply changes proposed after doing the UX research because it may require a lot of coding which costs both lots of time and money.

In short: the business wants to deliver fast and the users will use it anyway.

Not a web app, but another interface: Hulu on Roku. When watching a movie you get an overlay suggesting "Watch this next" that cannot be removed by hitting the back arrow or any other means, doing so leaves the movie. This means you can't watch any scenes in the credits without having 1/4 of the screen obscured.

Why did this survive into production? It's clearly user hostile, especially with the way a lot of movies (comedies and action movies in particular) include extra snippets. It survived because it drove people to click on the next movie. Which is what Hulu wants, they want people to keep watching (it bolsters their viewership numbers which is what lets them charge $$ for advertisers).

A lot of web UIs have the same issue. The things they measure are clicks and page views. They don't care how good/bad the page is if it gets them views and clicks that they can sell. It's like anything else where what's measurable becomes the goal itself, even when creates a system that's hostile/counter to the original intent.

Because we design around database tables and not workflows.

Quite often our underlying architecture simple mirrors the database structure with pattern like the Repository pattern and Active Record. Then it flows to the user. Instead of the user creating x as part of their workflow, they have to first create x on the "add x" page then go back to what they were doing.

Of course this only applies to some software, you couldn't make a word processor that encapsulate the user workflow, but for many apps, especially LOB apps, you can.