Good article, but visually representing data differently from how it's stored in the database can be a huge PITA. A pet peeve of mine is real names as an example, Dutch family names may have an infix (van, van der, den, van den) which is always in lowercase, and usually is not even an option on non-Dutch websites. You can't leave how to display these things up to the designer: the user has to know (imho) how these are stored. For example, sorting on last name should not happen on the infix, but only by lastname. E.g., "Dijk, van" comes before "Meulen, van der".
For completeness sake, the full names here may be "Bert van Dijk" and "Anne Jan van der Meulen". Also, "Anne Jan" is a single first name, despite the space.
Exactly. Especially in something like customer service where they're often helping fix and issue. If they don't know the name is incorrect then they will have a lot harder time figuring out why a downstream system is sending the wrong mail to the customer.
In their example, the change is also much harder to read for me. It takes up just as much space but logical categorical groupings are no longer visible at a glance. Previously you could see all the people from the same zip code, city or state. Now you can't because they're all mixed together at different horizontal offsets. You could also pull out the different information at a glance by using the horizontal offset which you now can't.
I’ve been in this boat and then had to justify the choice when integrating with third party vendors whose backends absolutely want names split into first/last components.
We would set up integrations sending the full name in the “first name field” and then a hard coded “notmylastname” string in the “last name field”. And then have about 3 days of back and forth usually including a link to https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... and explaining that no, you can’t reliably use a regular expression to split the full name data into first/last components.
That reminds me of my own pet peeve regarding anglocentric UI assumptions. Spanish naming customs are 'Given_name First_surname Second_surname' [0], such as for example Spanish director Pedro Almodóvar Caballero, whose name would be shortened for convenience by dropping the second surname — Pedro Almodóvar. The problem is too many US/Aus/UK developed UIs assume the whole world follows English naming customs, and thus would insist on showing his initials as 'PC' or shortening his full name as 'Pedro A. Caballero'. For reference, that feels as wrong as it would be to an American for a website (assuming Spanish customs) to initialise the director of E.T. and Jurassic Park as 'SA' or display his full name as 'Steven Allan'.
[0] Spanish given names may often be two-words-long (e.g. 'José Manuel') and a surname may less frequently be more than one word (e.g. 'de la Fuente'), but this isn't a necessary detail for my base rant above.
And the inverse is also somewhat common- forms which require both a maternal and paternal surname, and won’t let you continue with just a single surname.
In José Manuel, Manuel would be the middle name, just like in English. It's not a "two-words-long first name". Sometimes first and middle names are coupled like a whole, like it's usual for José Manuel. Also for José-something or Juan-something in general. Other times, the middle name is never used, like in Nicolás Antonio, being the Antonio part extra annoying, because the SS personnel, for some reason, insists in calling me that when it's my turn.
Wait, what? We don't have middle names, we have "nombres compuestos". Sometimes you may drop part of the name, sometimes not, but you will never see a form with a field for the middle name like you see in English speaking countries.
So different ways of calling the same thing and different UIs. But it's just given names vs. family names and a set of rules. I like Bulgarian ones most.
As a long-time designer, this is one of my main beefs with the rise of UX Design as term for design leadership (that's compared to UX positions that include "research" in their role, for example, and are usually great contributors to a project).
When you design a digital product, it's a given that the redesign should perform better in real life situations compared to the current version. Sometimes, the current version is a digital product as well, but sometimes it's forms, a pen, and an efficient clerk. These are the benchmarks from which the product should deliver clear improvements.
Most quote-unquote UX designers of the last decade, including many authors on uxdesign.cc, have a career arc that's an ignorant rediscovery of an existing discipline (interface/product design), which they keep not learning because they must appear above the existing skills and workers to keep the illusion going in the face of their managers and LinkedIn audience.
(If you think I'm equating lots of UX designers to middle-managers who sometimes ship a wireframe, you're reading me right!)
With 12 years experience as a UX designer, I’ve found that the best UX designers I’ve worked with usually had backgrounds and careers from a non-UX field before UX. Often academic backgrounds, such as anthropology, for example, and had at least some graduate degree. They understood actual primary research and applied it to their design process, and the results spoke for themselves.
Once UX became something you could enter from undergraduate studies (guilty as charged), or no degree at all, you end up with a lot of UX designers who lack those skills. And unless you are lucky enough to work with people who have those skills (as I was) or are a particularly motivated autodidact, you end up with articles like this.
The arrogance of designing a "solution" to a problem you yourself have never tackled or even talked to someone who has even attempted is maddening to me.
The designers who have not read the classics are a pain too. There are things that normal people don't know, like how a submenu should work, and when a user ask for a submenu the designer should bring the non-crapy way of doing it with their experience. The idea of not interrupting the proceedings with idiocy is also lost ; it's irritating. As an example, if open a reddit link on my phone, I have a bunch of stuff in the way of reading the posts.
TIL frustratingly hiding basic information within a menu, within a menu, within a menu, within a menu that's within a menu is called "progressive disclosure" (top marks for that amazing euphemism).
I really wish it were possible to calculate the total destruction of human productivity caused by whitespace and "progressive disclosure".
Yes, the optic system, including the speed of the optic nerve and the eyes ability to saccade, among other things, has a functionally unlimited ability to keep the brain aware of activity in the visual field (modulo optical illusions). The short term memory on the other hand is extremely limited.
As always, design should be based on fundamental principles of human biology.
It's also a way for newcommers to discover what an app can do, people know that opening menus has absolutely no risk, while clicking a button might open a modal or actually do something. So generally you want 3 levels: menus, buttons in the UI, and shortcuts.
Yes, I liken a proper menubar to the index of a book. You should be able to find just about every function a program has in its menus.
It also serves as a key shortcut cheat sheet which is important for cultivating a fervent base of power users for your app. Maintaining a knowledge base article of shortcuts is probably good enough for existing power users, but it won’t grow that group nearly as well as menus can.
Progressive disclosure is an important principle in designing good UIs, but as you’re pointing out it’s often misused or used to excuse cuts and burying things for the sake of aesthetics.
When applied correctly, all the term really means is thoughtful, research based surfacing of features, taking into account target audiences and the way features relate to each other. It’s why you don’t just dump all your features into the main window of your program, turning it into a Great Wall of Buttons. Thoughtfulness is increasingly uncommon though, UI design has more and more been treated as generic visual design instead.
Based on my experience and that anecdote, I think the lesson might well be that users of existing complex software hate any change.
Maybe it was "hard to learn", but they had existing customers anyway despite that who found value of some kind, and their existing users have already not only already learned it enough to do what they need to do (and don't want to relearn anything, like all of us), but they fact that they have learned a complicated thing is a badge of honor and even (subconscious) job security.
I'm not confident the whitespace or design goals were the issue, rather than any change at all -- I'm not even confident that _new_ users would have preferred the old design.
Or if there was a really good design out there that would have worked better for most both new and existing users, which a skilled and experienced designer could have come up with after actually observing and talking to users and understanding their work well -- I'm still not confident in any conclusions about how much whitespace it would have had.
If your job relies on using some software for hours a day, you'll quickly learn whatever quirks it has.
Making a design change means throwing out the brain equivalent of muscle memory for every one of your expert users. If you don't have a very, very good reason to do so, you're basically dropping them off in the wilderness and expecting they'll find their way back home on their own, with no familiar landmarks to guide their way.
Right, yeah, systems people use eight hours a day are quite different from 'e-commerce solutions' and 'corporate blogs' and have very different UX-demands.
When you're in front of an application that much layout is more or less unimportant as long as it can easily be interpreted by someone who has been sitting there for a year or more. This typically means that a newcomer will feel an immediate discomfort at layout and program flows, there's just too much and much of it is impossible to interpret without initial assistance.
This also means that when you change something it has to be run by pretty much every user first, or the one percent users that is actually really annoyed will pull in the rest and everyone will hate your revamp of their workplace.
Typically you can add to the interface though, and that's how long-lived 'enterprise' software gets cluttered views that are incomprehensible to newcomers.
If you enter this segment of development you need to understand that the users are like Unix greybeards, it's just that their version of urxvt and zsh and vim is a graphical interface to business processes. They'll get mad when things aren't like they've been for decades, and they'll try to have you guillotined if you force 'whitespace' and 'just enough information per view for the purpose I, master developer, think it should have'.
My pet peeve is UX designers who design GUIs on large color-corrected desktop displays with no light reflecting on the screen, often with hairline fonts. Then the application will be run on an embedded PC with a small low-contrast touchscreen at an awkward angle and sunlight behind the user's back.
Conversely, I find it frustrating when UI designs targeting some of the most capable displays that have ever existed make little use of the incredible color, contrast, and sharpness offered by those displays, sticking strictly to vague monochrome glyphs and the occasional hint of color.
A big contributor to the popularity of flat design is how non-designers could make reasonably ok looking stuff with it, whereas more graphically rich style unavoidably requires the work of a skilled graphics artist (which a few developers happen to also be, but the number of people who are good at both is small).
Yeah especially noticeable with fonts nowadays. I'm sure they look great on their high DPI monitor with perfect colors, not so much on a generic normal DPI display.
This anecdote is not about white space. It sounds like some junior designer was allowed to go nuts and do whatever they wanted with zero regard for the actual users. The designer just found a bunch of stuff they liked online and just did whatever. The first thing their manager should’ve done upon seeing this work is correct them about the nature of their job: Designers must first understand problems and then solve problems. It’s a creative field, but at the end of the day designers produce business outcomes. Having sexy portfolio pieces and creative work that truly expresses the inner experience of the artist is great — but it has to take a back seat to what the designer is being paid to do.
Maybe “being oblivious to the needs of paying customers killed an enterprise app” is a better title.
It's hard to do design right the same way it's hard to do kanban right or Jira right. Less skilled people chase the trends without understanding the fundamentals.
> I don’t know who this was but it sounds like a junior developer
Why has HN in the last three years or so gotten this collective irresistible urge to insert “junior developer” into every conceivable ill and malaise?
The thesis sounds straightforward. Power users need the app to be efficient. Naive outsiders fret too much over æsthetics and the potential usability for newbies. In turn change does not work out for the better.
Because not talking to users and then implementing a drastic change they don’t like sounds like a rookie move? Although, as I kind of allude to, I also place a lot of blame on management: Employees will make mistakes. Big ones. That’s life. A company needs to be structured so there are checks before those mistakes go out into the wild.
But, yes: Senior designers can also make mistakes. I’d argue they make less glaringly obvious mistakes, but humans will human.
while i get what you’re saying i also know many senior devs who swim in dogma of their own creation, finding some trend they personally aspire to and enforcing it religiously. i think the relative experience of a dev is not a clue for me on if they are going to do research on what the end users actually need.
I was talking about designers, specifically. But I have found that senior people on any I’ll are generally more capable of making considered choices. Not all, of course. And engineers definitely will bias towards tools they understand and have had good past experiences with. Again, to be “senior” at something means being aware of these biases and making reasoned choices despite them.
I see in your comments some bias too. You assume that UX designer made wrong choices, hence this person was junior. In fact, many designers have specialization and the choices made were good from a perspective of a printed media designer (management error - wrong hire/assignment). Or the designer was not aware of specific use cases, that were not communicated by the product manager. It is very easy and straightforward to blame the designer, but the root causes are very often somewhere else. Too often it’s just failure to understand specialization and hiring wrong people for the job.
> Because not talking to users and then implementing a drastic change they don’t like sounds like a rookie move?
That sounds like every single sad tale where a change of management/executives forces some new process or tool on their underlings without any input. (Perhaps those are junior developer CTOs?)
So the thesis of the OP was straightforward and clear because of all the facts in the history. Replacing that with some generic tale about mismanagement and the accursed junior-run-amok is comparatively less interesting.
> Power users need the app to be efficient. Naive outsiders fret too much over æsthetics and the potential usability for newbies. In turn change does not work out for the better.
This is exactly the sort of naive guess the designer made in the first place. It was not known what power users wanted, clearly, and users of different products will have different needs. It assumes power users are the users the company wants to appeal to: Maybe they’re trying to make life easier for new users. There’s no “lesson about power users” here. There’s a “lesson to understand your users and your business needs.” I am a power user of all sorts of software that I sorely wish had a less cluttered and “more white space” or “more aesthetic” experience. This designer may not have been wrong in their choices in that situation despite designing for software with “power users.”
Design is a set of tools. You have to know what you’re trying to do before you start saying stuff like “screwdrivers are for newbs — when making things for power users only user chainsaws!”
This is exactly the sort of contrarian response that makes everything into a philosophical dilemma which cannot be concretely acted upon.
The story reported: a new design was tried (for whatever reason) which didn’t work better (it worked worse) for the concrete users of that app: productivity-focused (or -forced) support staff.
It is anyone’s guess why you want to argue over a retelling of the article which we are commenting on. Since that (following your own example) could be motivated by a thousand different reasons I guess it’s best to not speculate.
> I am a power user of all sorts of software that I sorely wish had a less cluttered and “more white space” or “more aesthetic” experience
I would add to this with the observation that the existence of "power users" is very likely a sign that the system is poorly designed.
Obviously some things are just really complex and there is no way around that. But most things are not. A good system will easily and intuitively solve the user's problems without them needing a degree from NASA to understand how to use it.
Well, as you wrote NASA I'm sure that the space shuttle cockpit could have been made simpler than it was but how much simpler? To a point that one could fly it with a joystick and no instruments? I don't believe so and I think that one really needs a degree from NASA. I u715e9
Sometimes there is space for white space and sometimes there isn't. Excel (actually Libre Office for me) doesn't have padding inside cells and its good as it is. I want to fill my screen with data of I want to and I don't want to be able to see only a 15 by 10 grid. Some other program might be better with a more white padded UI. I wish the GNOME tools didn't get that way.
It's not just Hacker News, it's all over the place. The term has lost all meaning and basically just means someone that's making a mistake or does something the writer disagrees with.
I see it all over social media where before it would've been "10 pitfalls of X", it's "10 mistakes Junior devs make when learning X". Or if somebody disagrees with someone else about technological discussion, the goto insult is that the other person is a junior dev, instead of maybe thinking that other people have different perspectives.
Can we dispense with this "power user" bs? The reason anyone uses software is efficiency. The end goal is to deliver value (measured by productivity/$ spent) with a specific toolset you are tasked with building and maintaining. Stratifying your customer base by ephemeral computer literacy ideas will just distract from delivering a product that addresses everyone's needs.
Productivity unit per dollar spent is going to follow making your system most efficient for the people that spend their entire day in it (the power user) and just workable enough for an outsider to do occasional work. Compromising the workflow of your full time SCM expert in your ERP system for the sake of somebody who spends an hour or two a month filling out purchase orders is just stupid.
> Productivity unit per dollar spent is going to follow making your system most efficient for the people that spend their entire day in it (the power user) and just workable enough for an outsider to do occasional work.
Well, why bother making this distinction to begin with? The whole concept of a power user just reeks of lazy product design.
> Compromising the workflow of your full time SCM expert in your ERP system for the sake of somebody who spends an hour or two a month filling out purchase orders is just stupid.
Yes, this is lazy product design in the other direction. It's not clear why you can't just satisfy both groups.
But see, there often are more of those "hour or two a month" people. If you have, say, 20 times as many "non power users" as "power users", then "an hour or two a month" times 20 adds up to a significant amount - still less than the "power users", but not negligible.
And that's the problem of a lot of enterprise apps. The UI design is one that makes sense and is efficient for power users, but a large number of regular users use the app too, and the UI design absolutely stinks for them.
Well, I guess damn near all designers are junior in 2024!
It's getting hard to find software that hasn't been severely fucked up by some "UX artisan" padding their resume at the users' expense. Windows 11 is a marked step backward (I just love when new options load into my Explorer context menu as I'm trying to click on things). "New" Outlook is quite obviously designed by people that don't use Outlook. Android 12+ and Material You feels like some sick freaks who get off on other people being frustrated got a blank check to do whatever they want. Read this and tell me that the people responsible have your best interests at heart:
>They’re seeking experiences that are more than just practical and functional—experiences that also evoke emotion.
The experience evokes emotion alright! My phone with a 6 inch tall screen can only fit ~3 notifications when I pull the shade down. In that menu, 1.5 inches (25%) of my screen are taken up by setting toggles, and it's not like we don't know how to do better -- Android 11 fit 6 toggles in half the space that this dogshit takes up. There is so much fucking whitespace that reliably making gesture inputs has become a challenge.
I could go on and on and on and on. We're past the point where this is even appealing to the lowest common denominator. I haven't been able to find a single person of any background who appreciates this shit. Modern UX is shameless navel-gazing and at risk of sounding like an asshole, I think the world would be better off if leaders would just let go of the bulk of their design teams once they have a working product. It is laughable that you run into non-power-users that tell you "we had it good with AS/400 greenscreens, but then my company "modernized" my most important tool and it takes me twice as long to do my work".
Work in the options market making space if you really want to experience users who need immense amounts of dense data available across half a dozen 32 inch screens. The amount of effort that goes into saving the tiniest amount of screen real estate is amazing. Also, *everything* must be customizable.
Arrgggh. The story is about how the data took too much to uncover with the redesign. Then the very first recommendation is "first, reduce data volume." No! No! No! And stop reducing data density, too! Just because something has a higher learning curve doesn't make it bad.
Dense data lets a skilled user understand more in a glance. Data density is GOOD if you are building something that is meant to be used more than an hour every single day.
Now, if you are building a consumer app where nobody wants to do the chore and you're making it easier, THEN data density is bad.
And if you must make it less data dense because you're selling to a dense-headed exec and not the actual user (the usual with enterprise software), then just provide an easy to access user-preference toggle (and let the preference be saved). You can demo the "sleek" interface to the exec and the user can actually get their job done efficiently. You'll make the initial sale AND the resale when it comes time to renew.
The other week we had a "technology decision meeting" where we were going to decide on one of many technologies after evaluating them. The exec came into the meeting with the decision pre-made, then asked for our opinion. When I voiced my opinion on the sub-optimality of his choice, he agreed with me citing his bad experience with the vendor, he said "we hear you", and didn't alter at all the decision.
So yeah, lucky you that your execs listen. My exec just "hears".
What was enlightening for me was watching my wife, who is a physician, work in electronic medical record software like EPIC. It's ugly, it's dense, the colors are high contrast.
It also fits everything they need to see in one place and makes it easy to make changes. I do not think there would be a way to make it look "modern" without making it harder to use.
I don't think I like the grouping example; yes, it looks better when you show a single row from each one, but when I'm looking at 50 rows, it becomes much easier to spot any outliers (like one San Francisco among 49 Los Angeleses, or a Carolina hidden among Californias).
65 comments
[ 5.5 ms ] story [ 193 ms ] threadFor completeness sake, the full names here may be "Bert van Dijk" and "Anne Jan van der Meulen". Also, "Anne Jan" is a single first name, despite the space.
In their example, the change is also much harder to read for me. It takes up just as much space but logical categorical groupings are no longer visible at a glance. Previously you could see all the people from the same zip code, city or state. Now you can't because they're all mixed together at different horizontal offsets. You could also pull out the different information at a glance by using the horizontal offset which you now can't.
In my app, I don't even try to separate them. I just give a single string that can handle UTF-8, and let the user do what they want.
However, I also don't need that data for tagging, sorting or anything else, so it's easy for me to say.
We would set up integrations sending the full name in the “first name field” and then a hard coded “notmylastname” string in the “last name field”. And then have about 3 days of back and forth usually including a link to https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... and explaining that no, you can’t reliably use a regular expression to split the full name data into first/last components.
[0] Spanish given names may often be two-words-long (e.g. 'José Manuel') and a surname may less frequently be more than one word (e.g. 'de la Fuente'), but this isn't a necessary detail for my base rant above.
I wish luck to those two little guys, as their names will be misrepresented pretty much in every system in the world.
Whitespace killed an enterprise app - https://news.ycombinator.com/item?id=19153616 - Feb 2019 (435 comments)
When you design a digital product, it's a given that the redesign should perform better in real life situations compared to the current version. Sometimes, the current version is a digital product as well, but sometimes it's forms, a pen, and an efficient clerk. These are the benchmarks from which the product should deliver clear improvements.
Most quote-unquote UX designers of the last decade, including many authors on uxdesign.cc, have a career arc that's an ignorant rediscovery of an existing discipline (interface/product design), which they keep not learning because they must appear above the existing skills and workers to keep the illusion going in the face of their managers and LinkedIn audience.
(If you think I'm equating lots of UX designers to middle-managers who sometimes ship a wireframe, you're reading me right!)
Once UX became something you could enter from undergraduate studies (guilty as charged), or no degree at all, you end up with a lot of UX designers who lack those skills. And unless you are lucky enough to work with people who have those skills (as I was) or are a particularly motivated autodidact, you end up with articles like this.
> They need to move through that data quickly, without a lot of digging around in the interface.
Maybe, maybe not. Only the users can tell you what's important, and what metrics they want to improve.
I really wish it were possible to calculate the total destruction of human productivity caused by whitespace and "progressive disclosure".
As always, design should be based on fundamental principles of human biology.
It also serves as a key shortcut cheat sheet which is important for cultivating a fervent base of power users for your app. Maintaining a knowledge base article of shortcuts is probably good enough for existing power users, but it won’t grow that group nearly as well as menus can.
When applied correctly, all the term really means is thoughtful, research based surfacing of features, taking into account target audiences and the way features relate to each other. It’s why you don’t just dump all your features into the main window of your program, turning it into a Great Wall of Buttons. Thoughtfulness is increasingly uncommon though, UI design has more and more been treated as generic visual design instead.
Maybe it was "hard to learn", but they had existing customers anyway despite that who found value of some kind, and their existing users have already not only already learned it enough to do what they need to do (and don't want to relearn anything, like all of us), but they fact that they have learned a complicated thing is a badge of honor and even (subconscious) job security.
I'm not confident the whitespace or design goals were the issue, rather than any change at all -- I'm not even confident that _new_ users would have preferred the old design.
Or if there was a really good design out there that would have worked better for most both new and existing users, which a skilled and experienced designer could have come up with after actually observing and talking to users and understanding their work well -- I'm still not confident in any conclusions about how much whitespace it would have had.
Making a design change means throwing out the brain equivalent of muscle memory for every one of your expert users. If you don't have a very, very good reason to do so, you're basically dropping them off in the wilderness and expecting they'll find their way back home on their own, with no familiar landmarks to guide their way.
When you're in front of an application that much layout is more or less unimportant as long as it can easily be interpreted by someone who has been sitting there for a year or more. This typically means that a newcomer will feel an immediate discomfort at layout and program flows, there's just too much and much of it is impossible to interpret without initial assistance.
This also means that when you change something it has to be run by pretty much every user first, or the one percent users that is actually really annoyed will pull in the rest and everyone will hate your revamp of their workplace.
Typically you can add to the interface though, and that's how long-lived 'enterprise' software gets cluttered views that are incomprehensible to newcomers.
If you enter this segment of development you need to understand that the users are like Unix greybeards, it's just that their version of urxvt and zsh and vim is a graphical interface to business processes. They'll get mad when things aren't like they've been for decades, and they'll try to have you guillotined if you force 'whitespace' and 'just enough information per view for the purpose I, master developer, think it should have'.
Maybe “being oblivious to the needs of paying customers killed an enterprise app” is a better title.
Why has HN in the last three years or so gotten this collective irresistible urge to insert “junior developer” into every conceivable ill and malaise?
The thesis sounds straightforward. Power users need the app to be efficient. Naive outsiders fret too much over æsthetics and the potential usability for newbies. In turn change does not work out for the better.
But, yes: Senior designers can also make mistakes. I’d argue they make less glaringly obvious mistakes, but humans will human.
That sounds like every single sad tale where a change of management/executives forces some new process or tool on their underlings without any input. (Perhaps those are junior developer CTOs?)
So the thesis of the OP was straightforward and clear because of all the facts in the history. Replacing that with some generic tale about mismanagement and the accursed junior-run-amok is comparatively less interesting.
> Power users need the app to be efficient. Naive outsiders fret too much over æsthetics and the potential usability for newbies. In turn change does not work out for the better.
This is exactly the sort of naive guess the designer made in the first place. It was not known what power users wanted, clearly, and users of different products will have different needs. It assumes power users are the users the company wants to appeal to: Maybe they’re trying to make life easier for new users. There’s no “lesson about power users” here. There’s a “lesson to understand your users and your business needs.” I am a power user of all sorts of software that I sorely wish had a less cluttered and “more white space” or “more aesthetic” experience. This designer may not have been wrong in their choices in that situation despite designing for software with “power users.”
Design is a set of tools. You have to know what you’re trying to do before you start saying stuff like “screwdrivers are for newbs — when making things for power users only user chainsaws!”
The story reported: a new design was tried (for whatever reason) which didn’t work better (it worked worse) for the concrete users of that app: productivity-focused (or -forced) support staff.
It is anyone’s guess why you want to argue over a retelling of the article which we are commenting on. Since that (following your own example) could be motivated by a thousand different reasons I guess it’s best to not speculate.
I would add to this with the observation that the existence of "power users" is very likely a sign that the system is poorly designed.
Obviously some things are just really complex and there is no way around that. But most things are not. A good system will easily and intuitively solve the user's problems without them needing a degree from NASA to understand how to use it.
I see it all over social media where before it would've been "10 pitfalls of X", it's "10 mistakes Junior devs make when learning X". Or if somebody disagrees with someone else about technological discussion, the goto insult is that the other person is a junior dev, instead of maybe thinking that other people have different perspectives.
Can we dispense with this "power user" bs? The reason anyone uses software is efficiency. The end goal is to deliver value (measured by productivity/$ spent) with a specific toolset you are tasked with building and maintaining. Stratifying your customer base by ephemeral computer literacy ideas will just distract from delivering a product that addresses everyone's needs.
Well, why bother making this distinction to begin with? The whole concept of a power user just reeks of lazy product design.
> Compromising the workflow of your full time SCM expert in your ERP system for the sake of somebody who spends an hour or two a month filling out purchase orders is just stupid.
Yes, this is lazy product design in the other direction. It's not clear why you can't just satisfy both groups.
And that's the problem of a lot of enterprise apps. The UI design is one that makes sense and is efficient for power users, but a large number of regular users use the app too, and the UI design absolutely stinks for them.
Well, I guess damn near all designers are junior in 2024!
It's getting hard to find software that hasn't been severely fucked up by some "UX artisan" padding their resume at the users' expense. Windows 11 is a marked step backward (I just love when new options load into my Explorer context menu as I'm trying to click on things). "New" Outlook is quite obviously designed by people that don't use Outlook. Android 12+ and Material You feels like some sick freaks who get off on other people being frustrated got a blank check to do whatever they want. Read this and tell me that the people responsible have your best interests at heart:
https://material.io/blog/announcing-material-you
>They’re seeking experiences that are more than just practical and functional—experiences that also evoke emotion.
The experience evokes emotion alright! My phone with a 6 inch tall screen can only fit ~3 notifications when I pull the shade down. In that menu, 1.5 inches (25%) of my screen are taken up by setting toggles, and it's not like we don't know how to do better -- Android 11 fit 6 toggles in half the space that this dogshit takes up. There is so much fucking whitespace that reliably making gesture inputs has become a challenge.
I could go on and on and on and on. We're past the point where this is even appealing to the lowest common denominator. I haven't been able to find a single person of any background who appreciates this shit. Modern UX is shameless navel-gazing and at risk of sounding like an asshole, I think the world would be better off if leaders would just let go of the bulk of their design teams once they have a working product. It is laughable that you run into non-power-users that tell you "we had it good with AS/400 greenscreens, but then my company "modernized" my most important tool and it takes me twice as long to do my work".
Dense data lets a skilled user understand more in a glance. Data density is GOOD if you are building something that is meant to be used more than an hour every single day.
Now, if you are building a consumer app where nobody wants to do the chore and you're making it easier, THEN data density is bad.
And that's the problem.
The other week we had a "technology decision meeting" where we were going to decide on one of many technologies after evaluating them. The exec came into the meeting with the decision pre-made, then asked for our opinion. When I voiced my opinion on the sub-optimality of his choice, he agreed with me citing his bad experience with the vendor, he said "we hear you", and didn't alter at all the decision.
So yeah, lucky you that your execs listen. My exec just "hears".
For inputs as well, as command line lovers and Bloomberg terminal users can attest.
It also fits everything they need to see in one place and makes it easy to make changes. I do not think there would be a way to make it look "modern" without making it harder to use.