Hallelujah. It's not just enterprise apps, either. I've seen more than a few consumer app redesigns that just seemed to tack on the "clean", "minimalist", "whitespace" ethos, without really having a clue of an understanding of how users actually used the product.
I think this is a big factor in what killed slashdot. They did a big redesign years back that added a lot of whitespace but actually made it incredibly difficult to easily browse comment threads and see quality comments. Similarly, despite the old Reddit interface having a reputation as being "ugly", I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.
> I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.
I'm actually trying to "redesign" an app (I put design in quotes because I'm a dev and just trying to make a personal project look nice) and one of the struggles I have had is that high information density can look crappy at first but once you get used to it, is a better experience. So much nicer to have everything you care about in a single screen.
> high information density can look crappy at first but once you get used to it, is a better experience.
TL;DR
Your app should have the information density that it needs to be:
1. Useful and
2. Help the user avoid operating the app in a way that they don't intend to or is dangerous
Looking fancy is a secondary concern to good function. Typography has an important function because it is how you convey information to your user. Poorly laid out or written text can cause your user to get tired or use your app wrong.
Of course, making a useful interface is a difficult and long job. It is also thankless work, because if you do a good job your users will use your app without even noticing how well designed it is (good design is invisible!).
It's much easier to slap a pretty facade on your poorly designed app and call it done. People will be impressed by it, but struggle to use it.
I would recommend finding physical copies of Josef Mueller Brockmann's books, especially "Grid Systems in Graphic Design" and "The Graphic Artist and His Design Problems". They are both old (pre-DTP) but have great basic advice about how to design pages.
Craigslist is _the_ case study on how an ugly UI can survive over a long timeline. There are many techies and UI designers that are just disgusted at the UI of craigslist. For some, aesthetic is more important than usability. Luckily, for most, it's not.
That’s the strange thing about reddit’s new design: It not only lacks functionality and performance, but also white space and clean aesthetics. It feels dated already.
Given how aggressively reddit push their terrible no good very bad interface, I figure there has to be some advantage to them to my using it? I don't know what that could be, maybe users struggling to use the new interface looks like engagement to ads?
I have seen it in ill fated attempts to replace POS systems that were old green screen types to warehousing stocking tools using the same all with new pretty GUI or web page interfaces. Looking slick is great if customer facing but down in the trenches its all about familiarity, speed, and stability.
One pet peeve of mine is that these old systems are often trivially navigable with a (often custom) keyboard, then replaced with something that needs a mouse.
So 'tap, tap, tap, tap, enter' becomes 'tap, <locate mouse> click, tap, tap <locate mouse>, click'.
Also worth noting - consumer app or website designs that cram negative space everywhere are almost always slow as shit to use compared to their older "ugly" replacements. The way new Reddit renders content is an excellent case in point. An older example is the Guardian website - it's design about four or five years ago was despised by users (which was ignored) because it was slow and made using the site slower.
Reddit also fails to load aporoximately 20% of the time, too. I figured it was growing pains, but they've not changed a thing. They designed it, they're done, and they're really not interested in what the users think.
Oh man, glad I'm not the only one I noticed this. It used to take ~2 seconds to find my favorite playlist and play it. Now it takes upwards of 10-20 seconds.
On the dedicated "select a playlist" page with the squares, it even freaking re-organizes the squares every time you view it! Imagine if your desktop icons re-organized themselves in some arbitrary way every time you needed to open a program, and you get the utter destruction of muscle memory that can make up for the gaps in efficient design.
Also another great example about why user and accessibility testing are very very important. It was downright ignored and when pressed the Admins admitted it. Leave your beliefs at the door and fucking watch how the user interacts with your site, then ask them why they make those choices. Buy them a beer or whatever gets them to talk.
I use "old.reddit.com" exclusively too, information density is king.
Material design and minimalism probably have a lot of strong theory behind them, but the cargo culting around them often leads to worse UX. I think a lot of companies reach the "dedicated UX team/person" stage before the "careful A B testing of user flow" stage.
I'll forever be scarred by a web app I made to make the workflow in a mainframe terminal obsolete. Was so proud of what I'd done and all the theoretical productivity I had enabled (hey, I calculated the numbers, and the manager signed off on it!).
But my only lasting memory of that app is that it probably didn't increase productivity as much as I thought it did when I looked at how they used it day to day, and only succeeded in giving them carpal tunnel syndrome due to all the extra mouse-clicking. The final conversation I had with those users is how their wrists were starting to hurt so much. But hey, I was moving on to another project. Hey, sorry to hear, here are some exercises for your wrists, see ya. Oh, by the way, did you ever try Powerball? Supposed to do wonders to make your wrists stronger.
I try not to be so narrow-minded about app design after that.
Pretty does not necessarily equal functional, useful, or value-adding.
edit: In retrospect, those users grocked that terminal interface with all their key shortcuts the way a seasoned developer or sysadmin would grock emacs. Imagine forcing such a guy to use point and click instead for everything. You'd have a riot. I can't believe I didn't see it at the time. Young and naive, and now also regretful for all those people's wrists.
Bank tellers went through this in the 90s. You could tell when they swapped out their terminals for Windows. No more machine gun F key navigation, hello “hunt n grunt” cruising with the mouse.
This is what I’m increasingly going through with apple’s Touch Bar. Half the time I’m accidentally hitting it when I don’t mean to, and the other half of the time I have to look down, as a touch typist, to find the “button” I want.
>Are there things my users really don’t need to see right now? If you don’t know, ask!
ASK! ASK! ASK!
For the love of god please ask your users. I worked for a company with a big clunky enterprise app. It got redesigned numerous times and rolled out with big fanfare.
Nobody who used for any significant amount of time was involved in any of the redesigns. It was horrible every time with numerous changes just to get it not to be a huge pain point.... and then a new overhaul would come again.
I changed jobs to web development recently and really the first questions are to define the problems we're solving, and find out from folks using it day to day what their pain points are and how they work. I'll make some mvp type stuff for say a given function and then show them and get more feedback, the important thing is to get it from the end user, not their boss, not their VP, but the end user (boss and VP have to be involved too of course, just in other ways, distract them with fun control panels and such....).
I ended up working for a very small company, handful of people, me and one senior programmer, the product doesn't dominate the market but time and again customers just love that we call, ask, and do stuff and don't dictate how they work (within reason).
You can still make things clean, but when removing things you have to ask, communicate, you'd be surprised how much you can change if it is part of a conversation, and how little you can change if you just force it on them.
Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.
Watch them work. Watch a bunch of people work. Test and prototype changes and watch more people work. And watch them work at their desk or where ever they work.
This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.
They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...
In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.
We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
I wound up spending 6 weeks before even proposing anything that had to do with technology.
My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.
From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test.
Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius".
It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.
I often find that it's not that they lie, it's that they're often trying to come up with solutions and present those, rather than explaining the root problem.
But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of:
1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen.
2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...
I probabbly didn't emphasize it enough but yeah you give them something mvp like and watch them and get feed back on it.
Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on.
Sometimes you also just have to let them get used to it too ;)
It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.
Consider their response an input signal and not necessarily instruction from them. If my little niece comes crying saying there is a monster under her bed, of course I know it's not a monster but I'll still go look. Maybe a toy is under there making a noise, or the heater pipes, or the cat is moving stuff around.
>> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.
That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better.
I like to say users don't have requirements. They have problems.
This is why user/usability/UX research is actually a _thing_. Like a discipline, a thing to learn, a thing where experience and skill matter.
Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.
I think that this attitude a great example of the arrogance that permeates a lot of the redesigns that get dropped on people today. Yes one needs to sometimes throw out suggestions (because they aren't aware of techniques) but when users complain or praise something that needs to be listened to because they are literally telling you their workflow and describing potential optimizations. Nothing is more obnoxious than designers telling me I won't want something! It's like, 'fuck you, you don't know me, stop discounting what sounds like a good idea!'
Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.
> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.
Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for.
Remember, your users (usually) aren't UX designers, they just know where they get frustrated.
Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).
I've found its not that they lie (all the time) it's that often they don't have the time or mental energy to figure out what they want and even if they do they lack the tools to communicate it.
That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.
Some of this comes down to phrasing. We should both ask and observe (but it has to be the right kind of asking).
The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work.
Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing.
I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use.
When we do ask people questions, they need to be done in a methodical and probing way.
OK, observation is certainly important, but if they tell you something LISTEN.
Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.
So ASK, but do not ask direct questions (e.g., what do you want?).
Instead, ask what are their problems, their pain points, and what items they rely on most.
And OBSERVE -- watch what they actually do. What items they most rely upon (i.e., do NOT change that stuff if you can avoid it).
These answers & observations can then form the basis of your solution, which should relentlessly focus on their needs (and not your own design conceits).
Story from a friend who wrote & sold software into IT shops: When he asked "Do you like these features and would you buy this software?", he got all kinds of "Yes" answers, would write the package, and find few buyers.
When he switched to asking (basically) "What are your pain points, what is aggravating, time consuming, etc?", then writing software to address those issues, he got plenty of sales and happy customers.
A friend's company actually films users using software/websites, analyse their reactions and build a thorough report on UX. All their science is based on the concepts from IA -- information architecture -- from a decade or so ago.
And only change what are real problems. Maybe something like a user needs to navigate to three different pages to get the information they need. That's something you can improve.
But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.
Another thing is that suggestions from users often suffer from the "XY problem" issue. So even when a user has a ridiculous suggestion or request, there might be a legitimate issue behind it.
Its not always an option, but another alternative to asking and observing is becoming. If you yourself (or someone on your team) have previously been or are currently a user then you can usually answer a lot of the questions yourself with much less of a bias and maybe find solutions you wouldn't be able to by just asking and observing.
It's true, but you still need to ask, and watch them work. But what it often comes down to is that the company underestimates the effort involved, they push you to rush the process, and communication is the first thing to suffer.
Exactly. Asking users is only interesting if you know what you are looking for and you have to ask around the questions instead of leading them to answer. 90% of the time observing is what you want.
You don't ask them how do they want it redesigned. You ask them what they like, what they don't like. And preferably, you get a chance to see them use it.
We have this issue now. Inevitably when the actual users of the app report issues with this or that, the answer from the dev team is almost always, "Works as designed".
Yes, we know, THE DESIGN IS BROKEN.
And then, nothing. New features come out though, most of which aren't needed or deprecate features that we actually like. So I'm sure some Project Manager is being paid handsomely.
Asking is good but you often get a lot of wrong information that way. As well as very selective information.
When I was working on a reimplementation of an existing web app I had several team members watch how users were using the application. A mixture of sitting next to them and quietly watching (not interrupting their workflow) and remote watching via shared desktop (which we also recorded to refer to later).
Watching (in person and remotely) was without question more valuable. We could go back and replay what they were doing and why (we had copies of the worksheet they were working from for each use). Without it we wouldn't have delivered about 30% of what they were looking for and would have had to redo a load of work compared to if we had just gone by how they said they were using the system.
The new system rolled out and we had a total of two post-launch changes to make. Both of which were very simple changes. So don't just ask but watch how the users who use the system actually use it.
The challenge with Enterprise software is that the people who pay for it are usually not the people who use it everyday or a lot. So the vendor takes feedback from the end-users but they still have to demo to the guys holding the purse strings and when those guys give feedback (usually different from that of the every day user), vendor has to go with feedback from the purse string holder. If the vendor doesn't do this, the project doesn't get approved.
I think the proper thing here is for the purse string holders to defer to the views/feedback of the every day users.
lack of communication is main issue in all issues. people thing 'user' opinion is worthless or they lie or cheat you, but fun fact is that if they don't like your fancypants app, it will get shot down and cost you either time , money or clients or a combination of the three. if you ask ask ask, and then subsequently put it all in writing, verify with everyone they agree on the plan, they can never hold it against you even if they lied and cheated.
Not just ask, work with them. Try doing their job for the day.
The article has an example of customer records where the name fields are merged, same with the address fields. I know that would be hell for my friends in customer service wanting to find a customer by postcode or just their first or last name. Sometimes people are insistent they have complained before and you have ignored them, or you get scam artists. In these scenarios the team have to do detective work and they rely on having a decent sortable grid of customer records so they can find what they want if given incomplete information. Incomplete information comes from telephone messages made by cover staff, poor quality handwriting and a multitude of other sources. Since the staff stare at the same screen all day they know their way around it and simplifying the layout helps nobody.
Or even better - RUN 5-minute user testing sessions!!
Even in terms of the "recommendations" in the article, I can see all sorts of red flags. Group addresses? What if I needed to see what state it is at a glance? Now the state alignment is off. Or if I needed to sort by state?
All of this could have been avoided by sitting down with users of the existing system, watch how they interact, and then put together a revised version, and watch how they interact/where they have trouble/etc before doing a wide release.
The fact that user testing wasn't done, especially on an internal application where the users are right there available for it, is the real story here.
Agree - I could take most of this comment back to the late 90s and most of it would still apply. One thing you could do back then was with visual GUI editors, you could place buttons and widgets where you wanted them and change it quickly.
Indeed. I sure the hell miss WYSIWYG ui design. The auto-flow "constraint management" of web UI's and CSS turned bicycle science into rocket science. (There was a HN story about this a few weeks ago.) I had Jetsons technology, it felt great, but then it was ripped from my warm productive fingers. Will they do the same with my flying car?
The industry I worked in was networking (data center products, routers for ISPs, etc), but technical support. I did that for 20 years.
Even though it was pretty high end stuff.... everyone hates technical support and I found that generally companies eventually devalue it as time goes on. I got tired of that system.
I got paid really well but just got tired of seeing the atmosphere at company after company get more negative. Poor management trotted in, just coasting, incapable of making changes and such. Despite bringing in massive $$$ in support contracts... that money was never directed to support and things just degrade over time.
Then companies would outsource to some garbage company and the support there would be terrible so I and others would take the brunt of angry customers. Then someone would roll out metrics that show those folks overseas who just close cases are doing great because ... they just close cases without solving the issue.
The bad stuff just snowballs and there is no going back no matter how valuable you are in support.
When I was in support I worked closely with the engineering teams who wrote the code and who really liked how I worked (they'd ask that difficult cases be transferred to me because they know I'd document things, actually troubleshot, be honest if I don't know). They actually picked me at one point to be able to fast track issues that I saw straight to engineering and they'd pick up the phone immediately, because if I told them "you're gonna see this soon (either from a VP or something) because it is bad, you want to get a head start on it" they knew it was real. So I was already curious about coding in some form.
I wanted to do something new, got laid off after an acquisition, got a severance, and went the bootcamp route. I like making things now and web development is fun for me, I find that "troubleshooting" and "debugging" and such are all the same thing and that has served me well as well as the ability to work independently and learn independently.
>a well-intentioned UX Designer at a large high-tech company who was given a new project: Redesign an internal control panel that was ugly [...] It lasted one month before the company was forced to retire it. Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips! Their jobs were incredibly fast paced—they worked in a tech support call center and were rated on productivity metrics. They didn’t have time to click or scroll to find information while the clock was literally ticking.
This same exact story of a UI disaster happened at a Fortune 100 company I was at in 2005. They had a legacy app (think DOS character mode talking to a mainframe) for entering accounting documents.
To replace it, a high-priced consulting firm installed a "web portal" technology. (Unifying a company's various enterprise applications behind a single web portal was a hot endeavor back then.)
When it was rolled out, the accounting department fell behind on their work. Nobody noticed that the constant UI banner at the top of the of the web portal browser window was forcing users to always use the mouse to scroll up and down to look at information. In the old DOS system, they could just enter info from invoices quickly without even looking at the screen. But the new system broke the users' fluid familiarity.
The UI disaster was so bad that the consulting company had to have their consultants come in on Saturday to help the client's workers catch up on all their data entry. Imagine an army of $150k consultants doing the work of $10/hour clerks because the web portal's UI was never really field-tested with a real-world workload! If just one UI web developer actually shadowed one of their users for a day, they would have noticed the usability problem.
I can't believe how many times I've heard your story but in different companies.
I feel like there is an opportunity to make a graphical user interface framework that mimics old terminals. Full screen apps that leverage use of the keyboard shortcuts or hell even a custom keyboard specifically made for industrial use. Basically a IBM 400 system but running on modern software stack. Airlines have stuck with their UI and for good reasons.
Being easy to use and easy to learn are not necessarily the same thing. GUI's are generally easier to learn, but not necessarily the most productive once a typical user reaches the plateau of the learning curve. A UI designed to minimize hand and eye movements may have a longer learning curve than a GUI. The ideal solution may thus depend on staff turnover rate.
Those old green screen apps (CICs etc) supported enormous key stroke rates all right, with nary a mouse in sight.
But productivity was not as high as a rosy colored view of the past might suggest.
Operators had to be highly skilled. Entering a record for the East coast sales team would require remembering the code ESALES03. There were no helpful UI affordances of the modern age, e.g. fuzzy or free form searching.
Not sure the lesson here in going back to CLI. What designers need to do is to conduct research - interviews, observational studies, etc - to understand how and why people use their software and then create design alternatives.
There are custom keyboards, they're just hard to find. The Devlin KMX-144 or the Logic Controls LK1800 come to mind. I'm sure there are others. You can use (n?)curses to make a terminal user interface.
I still prefer the web - just with the keyboard as a first class citizen.
Re: Everyone agreed it needed modernization—it looked like it was from the early 2000s, after all!
My goodness, Flintones even. The fashion chase is becoming obsessive and wasteful. As I've ranted about many times on HN, UI faddism is a huge time and resource drain and the industry should just say no or see a therapist.
It sounds strange, but desktop UI's around 2000 pretty much reached the pinnacle of business UI's. The web slid us downhill with its stateless ways, unpredictable layout results, and now wasting screen space while copying touch-screen-oriented design for mouse users who don't need swollen boundaries. Use 5-pixel lines to visually segregate panels, saving you about 20 pixels of width versus white space. ("Web" pixels, not nec. actual pixels.)
(The only exception is perhaps drill-down link-heavy lists/reports/charts. The web served these well.)
I’m convinced this happens everywhere, at almost every software company. As a developer, the most demotivating part of my job was the endless redesigns-for-the-sake-of-redesigns that kept happening. It’s ultimately what drove me away from being an individual contributor software engineer.
And it’s always for goofy vague reasons: “It looks dated!” “It needs more pop!” “It’s not fresh enough!” (What are we making? Software or food?) Nobody is willing or able to prove with numbers or measurement that the old UI is bad and the new UI is better. It’s usually just the designer’s hunch! Yet if I want to change the search algorithm we are using I have to prove the new one is faster with research...
Nobody ever talks about the psychological toll this takes on developers, and also on the overall software quality. If you are just re-building the same UI over and over again because "everyone is now doing it in Django / Angular / Vue / React / {insert future hyped framework}", no developer will go the extra mile to produce a stable, high-quality code base anymore. Why should they, if they instinctively know that they are just coding for the garbage bin? What you get is a team of depressed, cynical developers and low-quality software that barely works, which will then be re-implemented 12-24 months lather in some other framework, possibly by another team of developers because the old team has left in frustration or been fired for lack of motivation. It is a vicious circle that consumes the most productive age of an entire software engineer generation, and (although I am sure some of you will heavily criticize this) I am deeply convinced that the only way out of this is to just stick to basic tools and programming languages that have been around forever. Avoid any framework that is advocated like a religious cult.
Not only does it happen almost everywhere but is has been going on since the beginning. There were people in the 90’s who did nothing but study UI’s, what happened to them??
Also remember: you MUST kill any Java-based enterprise app (Java is old and not modern) and replace the backend with Node.js. Then you can reuse all your server code in the frontend!
And remember to use Angular or React... actually, now you must use Vue. And create polyfills for your webpacks (and vice versa).
I wish more web apps would give a bit more choice on information density and layout - remember desktop software 15 years ago? You change all the colours, fonts, layouts (sometimes) so it suited you.
White space is great for new users to help not overload them, but after a few weeks of use, most should be able to go to their options and change the layout to save all this pointless mouse wheel scrolling.
I am impressed at the responses in this thread - I honestly thought I was in the minority about this, but hopefully the fashion moves a little more towards functionality
Please change the clickbait title. The app didn't die, they just had to revert the design change.
That aside, the Freshbooks redesign last year pushed me to switch to QuickBooks for exactly this reason. The new design had the stereotypical "modern app" design, but every common task required 5x more time than before.
For example, just to change the category of an expense you have to 1) click on the expense, wait for the detail page to load, 2) click on the category, 3) click "Change Category" and wait for the dropdown to load, 4) click on the new category, wait for it to apply, 5) click "Save", 6) click "Back to expenses." And every interaction takes a second or two to register, so imagine a delay between every step. Now imagine doing this 50 times every month when you're doing bookkeeping.
... In the previous version this took two clicks: 1) In the expense listing screen, click on the category, a drop down instantly appears, 2) click on the new category, it instantly applies.
They also took away the feature to add an accountant to your account. Imagine if GitHub took away the option to add "member" users.
Xero just did this with their Invoice section. Everything is fancy looking but has less visible data and less features with 10x more work to do the same thing.
But people want Excel levels of functionality, not a brochure, and the community has been unanimous with negative feedback so maybe they'll improve while they still can.
Really mind-boggling. I'd think companies of those sizes would do usability tests to see how users react BEFORE they roll it out to hundreds of thousands (millions?) of users.
> Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips!
I'm not sure this is about whitespace or information density.
I think that users, especially users using something as part of their job on a regular basis ("enterprise"), hate change. Any change. If they know how to use the thing as part of their job now, it is very difficult to make a significant change that they won't (at least initially) say they hate and want the old thing back. Even if the change would have been liked better by more new users/customers. Even if they hated the old thing too!
And aside from just change-aversion, of course, there may have been lots of knowledge/decisions about what users actually needed to do to do their jobs "encoded" in the old UX, as a result of lots of changes over time, that can be lost when creating a brand-new-from-scratch UX -- especially if you aren't doing a lot of (or any? it wasn't mentioned in the post) UX research in advance of the re-design.
I think this story may be about change, without necessarily being able to conclude anything about the factors of the change/design, such as whitespace, or any other design elements.
If you're doing UX design, you should be doing UX research. And not assuming any universal principles about whitespace or information density from this blog post.
Yeah I have similar concerns about the lessons learned. Power users rely on muscle memory. Productivity is boosted by familiarity. Unless there is a great deal of turnover on the team, the thing they are familiar with is the thing they have.
If you want to change that you have to come at it with respect and empathy. Fields nobody uses anymore? You can take them away but that changes tab order. So you might have to do that piecemeal or one screen at a time to give people time to adjust.
UX for pros runs counter to a lot of guidelines for beginners. You’re trying to reduce the amount of attention they have to dedicate so they can go faster or juggle the feelings of the person they’re talking to. They want speed and predictability. Discovery is only for very obscure workflows. Important, yes, but not paramount.
I’ve seen this even with developer tools. When someone starts yelling at a dev the conversation goes smoother when the task is straightforward. “Let me just pop in here and look... here’s your problem.”
And think of the color blind. Especially dark red shouldn't be the only way this information is highlighted. 8% of men are the kind of red-green colorblind, where dark red and black is not easily distinguishable.
If 8% of men don't see your error notifications, maybe that shouldn't be the only kind of highlighting (or choose a color that is less likely to affect so many people, like orange).
>Let users export data, instead
And maybe even import. I have a lot of administrative tasks I could script easily, if I had more direct access. But writing a python script using a headless browser, which breaks every time they update, doesn't sound as attractive.
And a point they kind of forgot:
Make it perform well. There are so many enterprise apps where you need to click a lot and wait so much time in between you start doing something else, which reduces your flow.
A second point: Give people keyboard shortcuts, and make them apparent through tooltips.
Your power users will highly appreciate if they can do things more quickly with the right shortcuts.
And think of the color blind. Especially dark red shouldn't be the only way this information is highlighted. 8% of men are the kind of red-green colorblind, where dark red and black is not easily distinguishable.
The example given in TFA is bad. Red should never be the sole indicator of an error. As you pointed out, color blindness is a thing.
The example should have also put an error glyph (like an exclamation point in a triangle, or the local equivalent) next to the problematic number. Or presented it in reverse, or with an unusually thick border. Anything but color alone.
>If 8% of men don't see your error notifications, maybe that shouldn't be the only kind of highlighting (or choose a color that is less likely to affect so many people, like orange).
While it is true that it's about 8% in total, there is a gradient on how red/green color blind one is.
Readit News
I think this is a big factor in what killed slashdot. They did a big redesign years back that added a lot of whitespace but actually made it incredibly difficult to easily browse comment threads and see quality comments. Similarly, despite the old Reddit interface having a reputation as being "ugly", I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.
I'm actually trying to "redesign" an app (I put design in quotes because I'm a dev and just trying to make a personal project look nice) and one of the struggles I have had is that high information density can look crappy at first but once you get used to it, is a better experience. So much nicer to have everything you care about in a single screen.
TL;DR
Your app should have the information density that it needs to be:
1. Useful and 2. Help the user avoid operating the app in a way that they don't intend to or is dangerous
Looking fancy is a secondary concern to good function. Typography has an important function because it is how you convey information to your user. Poorly laid out or written text can cause your user to get tired or use your app wrong.
Of course, making a useful interface is a difficult and long job. It is also thankless work, because if you do a good job your users will use your app without even noticing how well designed it is (good design is invisible!).
It's much easier to slap a pretty facade on your poorly designed app and call it done. People will be impressed by it, but struggle to use it.
I would recommend finding physical copies of Josef Mueller Brockmann's books, especially "Grid Systems in Graphic Design" and "The Graphic Artist and His Design Problems". They are both old (pre-DTP) but have great basic advice about how to design pages.
How is this an improvement?
[0] The one which you can still reach by adding '.compact' to any reddit url
In particular, faster.
I need to have a supercomputer to scroll past the first few pages.
Although anytime I mention this I fear they'll take it away...
So 'tap, tap, tap, tap, enter' becomes 'tap, <locate mouse> click, tap, tap <locate mouse>, click'.
These days it's so hard to organise or browse your own music collection.
On the dedicated "select a playlist" page with the squares, it even freaking re-organizes the squares every time you view it! Imagine if your desktop icons re-organized themselves in some arbitrary way every time you needed to open a program, and you get the utter destruction of muscle memory that can make up for the gaps in efficient design.
Material design and minimalism probably have a lot of strong theory behind them, but the cargo culting around them often leads to worse UX. I think a lot of companies reach the "dedicated UX team/person" stage before the "careful A B testing of user flow" stage.
For me it was the pedantic, toxic community. HN is a breath of fresh air by comparison.
Dead Comment
But my only lasting memory of that app is that it probably didn't increase productivity as much as I thought it did when I looked at how they used it day to day, and only succeeded in giving them carpal tunnel syndrome due to all the extra mouse-clicking. The final conversation I had with those users is how their wrists were starting to hurt so much. But hey, I was moving on to another project. Hey, sorry to hear, here are some exercises for your wrists, see ya. Oh, by the way, did you ever try Powerball? Supposed to do wonders to make your wrists stronger.
I try not to be so narrow-minded about app design after that. Pretty does not necessarily equal functional, useful, or value-adding.
edit: In retrospect, those users grocked that terminal interface with all their key shortcuts the way a seasoned developer or sysadmin would grock emacs. Imagine forcing such a guy to use point and click instead for everything. You'd have a riot. I can't believe I didn't see it at the time. Young and naive, and now also regretful for all those people's wrists.
>Are there things my users really don’t need to see right now? If you don’t know, ask!
ASK! ASK! ASK!
For the love of god please ask your users. I worked for a company with a big clunky enterprise app. It got redesigned numerous times and rolled out with big fanfare.
Nobody who used for any significant amount of time was involved in any of the redesigns. It was horrible every time with numerous changes just to get it not to be a huge pain point.... and then a new overhaul would come again.
I changed jobs to web development recently and really the first questions are to define the problems we're solving, and find out from folks using it day to day what their pain points are and how they work. I'll make some mvp type stuff for say a given function and then show them and get more feedback, the important thing is to get it from the end user, not their boss, not their VP, but the end user (boss and VP have to be involved too of course, just in other ways, distract them with fun control panels and such....).
I ended up working for a very small company, handful of people, me and one senior programmer, the product doesn't dominate the market but time and again customers just love that we call, ask, and do stuff and don't dictate how they work (within reason).
You can still make things clean, but when removing things you have to ask, communicate, you'd be surprised how much you can change if it is part of a conversation, and how little you can change if you just force it on them.
Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.
Watch them work. Watch a bunch of people work. Test and prototype changes and watch more people work. And watch them work at their desk or where ever they work.
This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.
They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...
In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.
We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
I wound up spending 6 weeks before even proposing anything that had to do with technology.
My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.
From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test.
Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius".
It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.
But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of:
1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen.
2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...
Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on.
Sometimes you also just have to let them get used to it too ;)
It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.
That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better.
I like to say users don't have requirements. They have problems.
Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.
Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.
Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for.
Remember, your users (usually) aren't UX designers, they just know where they get frustrated.
Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).
That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.
If they're so deluded about what they want what makes you think you can see through that and find a solution more clearly than they can?
The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work.
Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing.
I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use.
When we do ask people questions, they need to be done in a methodical and probing way.
Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.
So ASK, but do not ask direct questions (e.g., what do you want?).
Instead, ask what are their problems, their pain points, and what items they rely on most.
And OBSERVE -- watch what they actually do. What items they most rely upon (i.e., do NOT change that stuff if you can avoid it).
These answers & observations can then form the basis of your solution, which should relentlessly focus on their needs (and not your own design conceits).
Story from a friend who wrote & sold software into IT shops: When he asked "Do you like these features and would you buy this software?", he got all kinds of "Yes" answers, would write the package, and find few buyers.
When he switched to asking (basically) "What are your pain points, what is aggravating, time consuming, etc?", then writing software to address those issues, he got plenty of sales and happy customers.
It's the indirect question that matters.
But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.
Exactly. It's your job to see that, for example, people spend lots of time manually doing X in Excel, and design a tool to do it for them.
You need to ask/provide a way for users to tell you what they want (fixing or features).
And you also need to observe users using the product.
- the boss of the boss of the representative of the customer company
- the boss of the representative of the customer company
- the representative of the customer company
- my line manager's boss
- my project manager's boss
- my line manager
- my project manager
- me and my team
- the user
Any of these people might of might not have been ever in contact with the elusive "user".
Yes, we know, THE DESIGN IS BROKEN.
And then, nothing. New features come out though, most of which aren't needed or deprecate features that we actually like. So I'm sure some Project Manager is being paid handsomely.
When I say 'works as designed', what I'm actually saying is that I didn't have control over the design, go talk to the ones who did.
When shit's broken I want to at least be able to go in there and fix it myself, not email some support vendor who's just going to ignore it.
When I was working on a reimplementation of an existing web app I had several team members watch how users were using the application. A mixture of sitting next to them and quietly watching (not interrupting their workflow) and remote watching via shared desktop (which we also recorded to refer to later).
Watching (in person and remotely) was without question more valuable. We could go back and replay what they were doing and why (we had copies of the worksheet they were working from for each use). Without it we wouldn't have delivered about 30% of what they were looking for and would have had to redo a load of work compared to if we had just gone by how they said they were using the system.
The new system rolled out and we had a total of two post-launch changes to make. Both of which were very simple changes. So don't just ask but watch how the users who use the system actually use it.
I think the proper thing here is for the purse string holders to defer to the views/feedback of the every day users.
The article has an example of customer records where the name fields are merged, same with the address fields. I know that would be hell for my friends in customer service wanting to find a customer by postcode or just their first or last name. Sometimes people are insistent they have complained before and you have ignored them, or you get scam artists. In these scenarios the team have to do detective work and they rely on having a decent sortable grid of customer records so they can find what they want if given incomplete information. Incomplete information comes from telephone messages made by cover staff, poor quality handwriting and a multitude of other sources. Since the staff stare at the same screen all day they know their way around it and simplifying the layout helps nobody.
Even in terms of the "recommendations" in the article, I can see all sorts of red flags. Group addresses? What if I needed to see what state it is at a glance? Now the state alignment is off. Or if I needed to sort by state?
All of this could have been avoided by sitting down with users of the existing system, watch how they interact, and then put together a revised version, and watch how they interact/where they have trouble/etc before doing a wide release.
The fact that user testing wasn't done, especially on an internal application where the users are right there available for it, is the real story here.
The problem is, the arrogance of the designer. Who would ever redo something without talking to the user?
Even though it was pretty high end stuff.... everyone hates technical support and I found that generally companies eventually devalue it as time goes on. I got tired of that system.
I got paid really well but just got tired of seeing the atmosphere at company after company get more negative. Poor management trotted in, just coasting, incapable of making changes and such. Despite bringing in massive $$$ in support contracts... that money was never directed to support and things just degrade over time.
Then companies would outsource to some garbage company and the support there would be terrible so I and others would take the brunt of angry customers. Then someone would roll out metrics that show those folks overseas who just close cases are doing great because ... they just close cases without solving the issue.
The bad stuff just snowballs and there is no going back no matter how valuable you are in support.
When I was in support I worked closely with the engineering teams who wrote the code and who really liked how I worked (they'd ask that difficult cases be transferred to me because they know I'd document things, actually troubleshot, be honest if I don't know). They actually picked me at one point to be able to fast track issues that I saw straight to engineering and they'd pick up the phone immediately, because if I told them "you're gonna see this soon (either from a VP or something) because it is bad, you want to get a head start on it" they knew it was real. So I was already curious about coding in some form.
I wanted to do something new, got laid off after an acquisition, got a severance, and went the bootcamp route. I like making things now and web development is fun for me, I find that "troubleshooting" and "debugging" and such are all the same thing and that has served me well as well as the ability to work independently and learn independently.
This same exact story of a UI disaster happened at a Fortune 100 company I was at in 2005. They had a legacy app (think DOS character mode talking to a mainframe) for entering accounting documents.
To replace it, a high-priced consulting firm installed a "web portal" technology. (Unifying a company's various enterprise applications behind a single web portal was a hot endeavor back then.)
When it was rolled out, the accounting department fell behind on their work. Nobody noticed that the constant UI banner at the top of the of the web portal browser window was forcing users to always use the mouse to scroll up and down to look at information. In the old DOS system, they could just enter info from invoices quickly without even looking at the screen. But the new system broke the users' fluid familiarity.
The UI disaster was so bad that the consulting company had to have their consultants come in on Saturday to help the client's workers catch up on all their data entry. Imagine an army of $150k consultants doing the work of $10/hour clerks because the web portal's UI was never really field-tested with a real-world workload! If just one UI web developer actually shadowed one of their users for a day, they would have noticed the usability problem.
I feel like there is an opportunity to make a graphical user interface framework that mimics old terminals. Full screen apps that leverage use of the keyboard shortcuts or hell even a custom keyboard specifically made for industrial use. Basically a IBM 400 system but running on modern software stack. Airlines have stuck with their UI and for good reasons.
But productivity was not as high as a rosy colored view of the past might suggest.
Operators had to be highly skilled. Entering a record for the East coast sales team would require remembering the code ESALES03. There were no helpful UI affordances of the modern age, e.g. fuzzy or free form searching.
I still prefer the web - just with the keyboard as a first class citizen.
My goodness, Flintones even. The fashion chase is becoming obsessive and wasteful. As I've ranted about many times on HN, UI faddism is a huge time and resource drain and the industry should just say no or see a therapist.
It sounds strange, but desktop UI's around 2000 pretty much reached the pinnacle of business UI's. The web slid us downhill with its stateless ways, unpredictable layout results, and now wasting screen space while copying touch-screen-oriented design for mouse users who don't need swollen boundaries. Use 5-pixel lines to visually segregate panels, saving you about 20 pixels of width versus white space. ("Web" pixels, not nec. actual pixels.)
(The only exception is perhaps drill-down link-heavy lists/reports/charts. The web served these well.)
And it’s always for goofy vague reasons: “It looks dated!” “It needs more pop!” “It’s not fresh enough!” (What are we making? Software or food?) Nobody is willing or able to prove with numbers or measurement that the old UI is bad and the new UI is better. It’s usually just the designer’s hunch! Yet if I want to change the search algorithm we are using I have to prove the new one is faster with research...
And remember to use Angular or React... actually, now you must use Vue. And create polyfills for your webpacks (and vice versa).
White space is great for new users to help not overload them, but after a few weeks of use, most should be able to go to their options and change the layout to save all this pointless mouse wheel scrolling.
I am impressed at the responses in this thread - I honestly thought I was in the minority about this, but hopefully the fashion moves a little more towards functionality
That aside, the Freshbooks redesign last year pushed me to switch to QuickBooks for exactly this reason. The new design had the stereotypical "modern app" design, but every common task required 5x more time than before.
For example, just to change the category of an expense you have to 1) click on the expense, wait for the detail page to load, 2) click on the category, 3) click "Change Category" and wait for the dropdown to load, 4) click on the new category, wait for it to apply, 5) click "Save", 6) click "Back to expenses." And every interaction takes a second or two to register, so imagine a delay between every step. Now imagine doing this 50 times every month when you're doing bookkeeping.
... In the previous version this took two clicks: 1) In the expense listing screen, click on the category, a drop down instantly appears, 2) click on the new category, it instantly applies.
They also took away the feature to add an accountant to your account. Imagine if GitHub took away the option to add "member" users.
But people want Excel levels of functionality, not a brochure, and the community has been unanimous with negative feedback so maybe they'll improve while they still can.
I'm not sure this is about whitespace or information density.
I think that users, especially users using something as part of their job on a regular basis ("enterprise"), hate change. Any change. If they know how to use the thing as part of their job now, it is very difficult to make a significant change that they won't (at least initially) say they hate and want the old thing back. Even if the change would have been liked better by more new users/customers. Even if they hated the old thing too!
And aside from just change-aversion, of course, there may have been lots of knowledge/decisions about what users actually needed to do to do their jobs "encoded" in the old UX, as a result of lots of changes over time, that can be lost when creating a brand-new-from-scratch UX -- especially if you aren't doing a lot of (or any? it wasn't mentioned in the post) UX research in advance of the re-design.
I think this story may be about change, without necessarily being able to conclude anything about the factors of the change/design, such as whitespace, or any other design elements.
If you're doing UX design, you should be doing UX research. And not assuming any universal principles about whitespace or information density from this blog post.
If you want to change that you have to come at it with respect and empathy. Fields nobody uses anymore? You can take them away but that changes tab order. So you might have to do that piecemeal or one screen at a time to give people time to adjust.
UX for pros runs counter to a lot of guidelines for beginners. You’re trying to reduce the amount of attention they have to dedicate so they can go faster or juggle the feelings of the person they’re talking to. They want speed and predictability. Discovery is only for very obscure workflows. Important, yes, but not paramount.
I’ve seen this even with developer tools. When someone starts yelling at a dev the conversation goes smoother when the task is straightforward. “Let me just pop in here and look... here’s your problem.”
And think of the color blind. Especially dark red shouldn't be the only way this information is highlighted. 8% of men are the kind of red-green colorblind, where dark red and black is not easily distinguishable.
If 8% of men don't see your error notifications, maybe that shouldn't be the only kind of highlighting (or choose a color that is less likely to affect so many people, like orange).
>Let users export data, instead
And maybe even import. I have a lot of administrative tasks I could script easily, if I had more direct access. But writing a python script using a headless browser, which breaks every time they update, doesn't sound as attractive.
And a point they kind of forgot: Make it perform well. There are so many enterprise apps where you need to click a lot and wait so much time in between you start doing something else, which reduces your flow.
A second point: Give people keyboard shortcuts, and make them apparent through tooltips. Your power users will highly appreciate if they can do things more quickly with the right shortcuts.
And think of the color blind. Especially dark red shouldn't be the only way this information is highlighted. 8% of men are the kind of red-green colorblind, where dark red and black is not easily distinguishable.
The example given in TFA is bad. Red should never be the sole indicator of an error. As you pointed out, color blindness is a thing.
The example should have also put an error glyph (like an exclamation point in a triangle, or the local equivalent) next to the problematic number. Or presented it in reverse, or with an unusually thick border. Anything but color alone.
While it is true that it's about 8% in total, there is a gradient on how red/green color blind one is.