I have 1 rule:
If you're building an app that people use for work and open every day, you should make it dense. People want to get work done, fast. They don't care about how pretty it is.
Otherwise, you should make it sparse.
If you're building an app that people use for work and open every day, you should make it dense. People want to get work done, fast. They don't care about how pretty it is.
Otherwise, you should make it sparse.
Knowledge workers who "live" in the tool want as much data as possible, as quickly as possible.
But that means not having your intern pump out that single electron design so it’ll never happen
Would the density of these interfaces increase or decrease? An actual power-user would master all the shortcuts and would prefer a zen experience where only the document is visible, with no widgets whatsoever.
The most obvious pitfall is that more UIs = more work. There's the initial development, but it also increases the work every time you need to add something to the UI, and increases the likelihood of bugs. Microsoft could afford this increased cost, but it's not clear if it would be worth it.
Secondly, having multiple distinct UIs makes it difficult for someone to transition from a "casual user" to a "power user". If someone who has only used the "simple" UI switches to the "power" UI, they have to re-learn everything from scratch. Additionally, if there are any features limited to the "power" UI, it's extremely difficult for a "simple" UI user to discover those features even exist.
That doesn't mean that creating multiple UIs isn't ultimately the right solution for MS Office. It might be! But doing that comes with downsides, and I can understand why Microsoft doesn't want to go in that direction.
All I’m suggesting is splitting it on use case rather than on which device I open it
Unfortunately, this frequently results in technical debt because "functional" often means "complies with whatever business logic the current sponsoring org (Finance, HR, Supply Chain/Procurement, Ops, etc) wants that week, and the result of that is that many internal enterprise apps get wholesale rewrites every 4-5 years because it's easier than refactoring.
This set of phenomena is completely foreign to SWEs and PMs who have only ever worked in big tech, on consumer products especially, and the reality is that while some engineering teams in some companies are sometimes doing hard and creative work, the majority of big tech SWEs "moving protobufs" is much easier and less complicated than the kind of crap faced by enterprise IT.
Four hypotheses why standard users are often the primary target of design:
(1) Power Users are louder but mostly ignored due statistically being not relevant.
(2) During design sessions the teams empathize with a standard user, not the power user. I've seen this pattern over and over again.
(3) Current web technology makes it difficult to build high density UIs that work well.
(4) Mobile UI first. If it works on mobile, we can just use the same UI for the web.
All this leads to another problem: Your standard users never become high power users on your platform. In the end platforms become interchangeable.
If your design is very dense, then a new user will be scared away. If you NEED growth, you can't afford to scare away users. You need to cater to them as much as possible. You need them to tell their friends "yes its very easy to get started with".
It leaves no room for a learning curve.
And this is also something we have come to expect. So anything with a learning curve feels like a massive investment, and we feel dumb whilst using it and not knowing how, because everything else is so dumbed down that it is instantly intuitive. This has made computers and software very popular and widely used. And I am happy for my (grand) parents that they can use these things now.
But it has come at a great cost of productivity for everyone. Because even the designs where we would have invested the learning time to get faster, can't invest that time, because the interface is so simple it becomes limiting.
This is considered good, because if they become power users and get their stuff done faster they'll "engage" less and we can't have that.
Remember that today's career incentives in tech companies means tech is primarily there to drive "engagement" and is not there to solve the user's problem.
Design for the least, compare against average, and don't cap the best, use those agents as immediate beta-user -> quality/dev feedbook loop, dog-fooding user requirements as a fundamental base, and don't let perfection impede progress.
Business apps that my customers want, crazy dense. Some of these I look at and I'm "man this is a lot of stuff" but ... then you get used to it and it works.