White space killed an enterprise app (2019)
uxdesign.cc
uxdesign.cc
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".
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.
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.
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.
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.
Whitespace killed an enterprise app - https://news.ycombinator.com/item?id=19153616 - Feb 2019 (435 comments)
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.
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.
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.