> Optimize for use cases instead of branding/marketing.
Even if a company had in-house people for both branding/identity and interface design, which isn't common, they probably wouldn't even go to each others meetings, just like a database administrator wouldn't go to front-end dev meetings. My having professional experience in both is the exception, not the rule.
The overwhelming majority of the interface work I've done was for applications published by a nonprofit that didn't give a shit about branding or prettiness. They needed their interaction-heavy applications to be very visually parseable and have things like action status and next actions be clear and intuitive instantly. That doesn't happen by accident: you must delve deep into the minutiae of what you communicate with information hierarchy, implied relationships through gestalt or implied lines, and other visual cues that help people subconsciously understand what they're looking at. While these things are very important to everyone trying to use an interface, it's triply so for people that aren't used to staring at dense screens of text all day long, which is why other developers are the only ones that don't hate interfaces made by developers. Branding people care about very general look and feel and are usually satisfied if you use the appropriate colors and typefaces. Interface design is the hard part with layout, has little to do with aesthetics, and is 100% about the use case.
Interface design do seem a thing of the past. It’s always a pleasure to use a properly made application. But a lot of business only cares about being pretty and mix that with abysmal technical performance, and the result is usability hell.
There are probably more active interface designers now than ever in history. It's easy to see interfaces of yesteryear through rose-colored glasses, but it's nostalgia speaking. There is and always will be plenty of shit design in the world, but the idea that usability in applications is declining is just not supported by the interfaces we use. The problem with good interface design is that its entirely transparent-- since we use so many more interfaces than we used to, we notice more interfaces that don't meet our expectations, and at the same time, our expectations for interfaces have grown. Also, with time, fewer interfaces prioritize what developers want in them. The interface features desirable to people with a working mental model of software are often orthogonal to what everybody else wants. That's why the nearly the only end-user-facing open source projects that even approach the popularity of their closed-source equivalents-- e.g. Signal, Blender, Firefox-- are grant funded projects with people overseeing the UX. In contrast, Eclipse is also grant funded but I don't see any designers on their team, and based on the experience of using it, that tracks.
I don't mind paying for software, but not for the current crop. It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds. And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
> I don't mind paying for software, but not for the current crop.
Nothing about this is specific to commercial software. I've got 5 digits of hours in FOSS contributions.
> It was once expected to get training for a tool. But now the trend is for the tool to become a toy. Just play with it until you get light and sounds.
Your stance is pretty common among developers. The fact is that we use so much end-user-facing software for which we don't even think about the interfaces... we just accomplish whatever task you need the tool to accomplish and move on. Think about every phone app, screen, website, ordering system, electronic appliance-- all of those things have designed interfaces. Do you think it's reasonable to require customers to read instructions on using an ordering terminal at a quick serve restaurant? Their phone email app? Web browser? Messaging clients? If every one of those interfaces was assembled according to the developer's fancy rather than someone who knows how to utilize people's existing mental models and cultural understanding, well, that's a whole lot of "RTFM" time that would be better spent on actually getting something done. Most people will never read a single line of software documentation in their entire lives for the same reason they'll never need to learn how to use a Bobcat for yard work-- it's just not necessary for non-professional work. Developers have a fundamentally different perspective on software and it's not 'better.' Needing docs for basic application functionality is the right tool for some jobs, but not for most jobs.
> And for safety, we will reduce the set of actions you can take. Fine for a single purpose application, but not great when you want versatility.
You're conflating bad with intuitive with well-designed. An interface that doesn't let expert users work efficiently is a bad interface. Almost invariably when you see an interface that looks 'designed' but it's not functional, it's because a developer went looking for nifty UI mockups on Dribbbbbble and copied it so they could tell people about the beautiful interface they designed. They think that works because they think UI design is about aesthetics rather that making your interface as useful as possible. Great designs aren't even always intuitive to non-experts. Lots of times it has to be fast and efficient for people who know exactly what they're doing, and training might be appropriate for important, complex interfaces... but complex expert-targeted interfaces are not the same things as interfaces that are confusing because they were assembled rather than designed by someone who knows what they're doing. One of those things looks like the console for a modern X-Ray machine. The other looks like the interface for the Therac-25. I use vim (or, vim keybindings in other editors) these days because it's a great expert tool, and it's about as far from intuitive as you can get. If someone said "make an efficient text editor for people who will spend many thousands of hours at keyboards, there's a good chance interface designers would come up with something just like that, though probably with better visual cues.
Even if a company had in-house people for both branding/identity and interface design, which isn't common, they probably wouldn't even go to each others meetings, just like a database administrator wouldn't go to front-end dev meetings. My having professional experience in both is the exception, not the rule.
The overwhelming majority of the interface work I've done was for applications published by a nonprofit that didn't give a shit about branding or prettiness. They needed their interaction-heavy applications to be very visually parseable and have things like action status and next actions be clear and intuitive instantly. That doesn't happen by accident: you must delve deep into the minutiae of what you communicate with information hierarchy, implied relationships through gestalt or implied lines, and other visual cues that help people subconsciously understand what they're looking at. While these things are very important to everyone trying to use an interface, it's triply so for people that aren't used to staring at dense screens of text all day long, which is why other developers are the only ones that don't hate interfaces made by developers. Branding people care about very general look and feel and are usually satisfied if you use the appropriate colors and typefaces. Interface design is the hard part with layout, has little to do with aesthetics, and is 100% about the use case.