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.<p>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'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!).<p>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.<p>I try not to be so narrow-minded about app design after that.
Pretty does not necessarily equal functional, useful, or value-adding.<p>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.
One point:<p>>Are there things my users really don’t need to see right now? If you don’t know, ask!<p>ASK! ASK! ASK!<p>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.<p>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.<p>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....).<p>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).<p>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.
<i>>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.</i><p>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.<p>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.)<p>When it was rolled out, the accounting department <i>fell behind on their work</i>. 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.<p>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.
Re: <i>Everyone agreed it needed modernization—it looked like it was from the early 2000s, after all!</i><p>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.<p>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.)<p>(The only exception is perhaps drill-down link-heavy lists/reports/charts. The web served these well.)
Please change the clickbait title. The app didn't die, they just had to revert the design change.<p>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.<p>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.<p>... 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.<p>They also took away the feature to add an accountant to your account. Imagine if GitHub took away the option to add "member" users.
> Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips!<p>I'm not sure this is about whitespace or information density.<p>I think that users, especially users using something as part of their job on a regular basis ("enterprise"), <i>hate change</i>. 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. <i>Even if</i> the change would have been liked better by more <i>new</i> users/customers. <i>Even if</i> they hated the old thing too!<p>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.<p>I think this story may be about <i>change</i>, without necessarily being able to conclude anything about the factors of the change/design, such as whitespace, or any other design elements.<p>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.
>Use color deliberately.<p>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.<p>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).<p>>Let users export data, instead<p>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.<p>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.<p>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.
I feel like the author really wanted a scapegoat for a process that was flawed from the start (redesigning a product without research, empathy with users, feedback, gradual introduction with small test groups etc.)<p>Too often I see UX issues blamed on visual choices — the whole everything must be flat movement of 2013-2018 is one example — when there are deeper issues that can't be extracted into a pithy recommendation.
Another modern web design pattern that I hate is when a website uses an excessive amount of AJAX requests. The practical effect of this behavior is that you see the UI update many, many times before the data you're looking for is actually shown. While the data is being loaded, you just see placeholders and you don't feel like you should do anything until the entire page finishes loading.<p>For instance, when I log into the Chase website, there's 8 UI updates (i.e. 8 sets of loading bars/HTTP requests; see below) that have to load before I can see the recent transactions on my account. Each chunk of requests must finish before the following chunk can start. All in all, it takes ~7.1 seconds for the page/recent transactions to load.<p>---<p>The 8 UI updates the Chase website goes through before it finishes loading/you can see your recent transactions:<p>1. Initial blue loading screen with a spinning loading icon<p>2. Tan colored background color replaces screen #1<p>3. Header loads<p>4. The blank outlines of the main UI components loads (without any data in them/with placeholder loading bars)<p>5. All of my Chase account metadata (account type, current balance, and last four digits of the account number) loads<p>6. More in-depth data of the first account on the list loads (available credit, payment due date, minimum payment due, etc.)<p>7. Recent transactions panel starts to load (with no data/with only a placeholder loading bar)<p>8. Recent transactions are shown<p>At this point, the page is finished loading.
Was a PM for a product that got criticism for its lack of density. When you are building a powerful tool for power users, you may need density and a lot of levers for flexibility. The consumer/enterprise distinction is huge here.<p>As a domain expert, I was for a sparse UX that emphasized the awesome just-works power of the product. I'll never forget how one bank IT director customer said, "I just can't pay for something with this little on the screen. Can you add more <i>stuff</i>?"<p>I think the key PM-fail on my part was privately scoffing to the architects afterwards that while we reduced the whites pace, we should also implement the ruby acts_as_enterprisey module to make the product seem crappier. This lack of people insight (and downside of visionary personality type attitude) pretty much summarized my limits as a PM.<p>Real lesson for us was: enterprise users trade on demonstrating their value by performing complex work. It's job security. The stakeholders you need to close an enterprise sale include those users. If your product or UX trivializes someone's job, they are going to fight you.<p>When they say they don't want your UX but they want your data, what they are really saying is, they don't need the problem you think you are solving solved, they are indexed on finding a way to demonstrate their value.<p>I"m learning this the hard way now with a product that doesn't quite close the knowledge gap for non-experts, but am finding it's simplicity is undermining to the authority of experts. Solving problems and demonstrating value are very different things. It's like building a tools vs. building instruments.<p>The UX question I need to answer is, does my product solve a problem, or help a problem solver demonstrate value? If a) then the end user is not my customer, if b) it's going to need a lot more knobs and whistles.<p>White space isn't just white space, it represents the expression of functionality to the customer.<p>The UX design question always takes you back to first principles, who is your customer and what do they need?
Am I the only one like dense information? There is judicious use of whitespace (Swiss layout, Brockmann et. al) and then there is the whole material UX enchilada.<p>I prefer Foobar2000 over Apple Music. Give me dense, logical and flat layout over 50 page long hierarchical layout full of whitespace. Whitespace is tiring when used extensively.
It seems a lot of UIs these days are designed for beginners instead of people who know what they are doing. Someone’s this is OK but in a professional conetwxt it often isn’t. I can’t even imagine if IDEs like Visual Studio were designed “spacious” and “minimalistic”. It would look cute but you wouldn’t get anything done. Some things are just complex and there is no way to design that away without hurting productivity.
Jira drives me nuts with this. I have a 34" monitor and with six columns in our Kanban board I can see 4, maybe 5 tickets per column. With 10 people on a team it means constant scrolling to see what people are working on.<p>It finally pushed me over the edge to use user stylesheets. A bunch of "margin: 0 !important" and "display: none" and I get twice as much information on my screen at the cost of... looking polished I guess?
The real lesson here is that the company tried to save money by hiring a design agency instead of a UX designer who would have done the research to understand the end user and their needs. Had that been done then the new interface would be just as quick to use but with major improvements. Instead of modernizing they should have asked how to design a product that’s even more useful.<p>I see this problem all the time when I talk to companies. They hire a big agency expecting big results and the agency rolls out the red carpet and does everything they are asked. Both parties fail. The first question I ask when someone asks me to design something for them is “why?” Most of the time the response is way out of touch with the actual reason why you should ever consider design. A real UX consultant will do 70% research, 30% design if they offer that portion of the service which I do. Please don’t make the mistake of assuming you know what you need. Find a UX designer not a UI designer and listen for the hard questions- who is your customer? What problems are they complaining to you with? What do you think this redesign will do for you? These are just some of the basic questions you’ll be asked. Your consultant will know your customer better than you when they are done before they touch any designs, if they don’t do any of these things then walk away.
Related and no doubt even as infuriating is the tendency to also decrease the contrast of UI elements by, in addition to adding copious amounts of whitespace, turning blacks into light greys. I remember one instance where an internal website was "modernised" with a new stylesheet and panicking for several minutes wondering if something was wrong with my eyes or monitor, because everything looked faded and unclear in addition to the nauseating effect of the sea of whitespace. My coworkers were just as repulsed by the change, and after confirming with the department responsible that they were not going to revert the change ("because we don't want to go back to old stuff" --- that's literally the explanation I was given), took several minutes to come up with a user stylesheet and distribute it to everyone else interested.<p>To this day I am still astounded that more than one person thought #BFBFBF is a perfect colour for text on a white background.
Modern UI design is awful. It might work for Joe Moron, who is just scrolling through video clips and short fragments of text, but I can't imagine why you would ever try to apply design principles designed for that case to professional users. Do people really think they can take the complexity out of these inherently complex business systems? I'm not saying that everything has to look like shit, but no amount of dumbing down an interface is going to fix the fact that certain software needs to display an intimidating amount of info, and that the learning curve for that software is going to be pretty brutal.<p>I want to wake up from this nightmare. Software like Bloomberg Terminal and CATIA doesn't need to be <i>beautiful web apps with clean, !minimal! Material design</i>, they need to tear through the issues they're meant to solve as quickly and easily as possible, even the reality of that is a little ugly.
A champion of data density who has a lot of thought provoking words on design is Edward Tufte: <a href="https://www.edwardtufte.com" rel="nofollow">https://www.edwardtufte.com</a> Worth a look if you aren't familiar.
> In the above example, note the prominence of the single red highlight in the gray-themed table, thanks to the lack of other color. Each row suffers slightly in its horizontal scannability, but at the gain of increased table-wide scannability. Consider what is more important for your application.<p>For what it's worth, I found the blue table easier to spot the red numbers. I'm red/green colorblind and I could not differentiate the red from the grey table coloring very well. With the blue it stood out.
Never underestimate the power of a data entry person working in a high volume organization with an app that looks like it was designed in 1975.<p>I worked on a potential redesign of the US Navy's medical appointment booking application and the data entry rate and responsiveness of their "ancient" system was far superior to the newly proposed solution (web based).
> Users absolutely hated the new system.<p>I feel like this is a universal absolute, doubly so when it comes to enterprise apps (the lone exception being when we switched from Lotus Notes to Gmail -- then only half the company hated the change).<p>I would've liked to know how long the changes were in place and how it affected productivity metrics, especially the amount of training time spent on new users. As is, the article seems kind of obvious. Enterprise users abhor change; who knew?<p>> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)<p>This also makes me question the veracity of the article. It's a really terrible metaphor that makes me wonder if they were _solely_ concerned with pretty design on the outset.<p>I want a dictionary that shows me 1 word per page, with a search bar. The page flipping functionality is useless and can be removed entirely. It's a bad workflow.<p>I can definitely say that over the past 20 years, our in-house LoB app has developed some really bad workflows as well (business changes a lot over 20 years). Removing these bad workflows would give us back a ton of screen real estate without losing productivity.<p>The causality is backwards. I don't want to create whitespace by changing the design and ruining the functionality. I want to change the functionality which will create more whitespace and allow room for beautiful design.
The author writes a solid article, makes good points, then blows the conclusion.<p>It's not "function over form, always"<p>It's function <i>with</i> form, always. They're properly inseparable when building a product. They aren't separate things such that one should ever be over another, or that one should ever suffer to the other. You consider the product and match the function and form together to that product's needs.<p>It should never be function over form, or form over function. They work together in unison to be one: simpatico. The function isn't separate from the form, the form isn't separate from the function. The necessary end result product can only exist with both, as such they necessarily inform and cooperate with each other at all times.<p>The flawed approach described in the article, was form over function, which is the identical <i>conceptual</i> mistake to function over form. It's the mistake of ever considering the two to be separate or to ever elevating one over the other.<p>If a high density information presentation approach is the best form, that's not function over form. That's the proper form for the function of the product. That means the two are working together - neither is elevated - to deliver the best combined form + function for the product in question and its specific needs.
I have worked with many teams at large companies where clunky applications, usually just database facades / CRUD, have been in place. In almost every case these 'database interfaces' never fully satisfy the users' needs.<p>Instead, I have found much success in slowly deprecating these applications and, instead, giving these users direct read-only access to the database and teaching them SQL. SQL is not a tool only for 'technical' people. Most of these users have mastered the 'dark arts' of Excel so they are capable of learning other tooling. These users can then query the data in any way they want and export it in any way they want. There is more to this, like ensuring to only give them access to reporting databases. The application then can focus on being an interface for updates / writes and not for data exploration.
If someone in the UX space wants to change the world, start a twitch stream and review websites/apps.<p>I have several scratch-my-eyes-out sites I use every week for fodder and am sure you would never lack for suggestions.
> What’s the lesson here?<p>> A large business by its nature has massive-scale data and usually thousands of users who directly interact with it—searching, manipulating, reporting, and more. They need to move through that data quickly, without a lot of digging around in the interface.<p>The lesson here is actually that the designer didn't understand the context in which customers were using the app.<p>It sounds like s/he didn't talk to customers about how and why they use the app, or show wireframes to them, or even sit and watch them use it for an hour.<p>If they had done any of the above, they would have had a lot more context about what a good solution <i></i>looked and felt<i></i> like.
There really needs to be a different term for 'visual' white space and \s+. I can't be the only one who was expecting a tale of python/makefile woes.
We use an enterprise MIS and the developers just did this very thing to us. When I reported it, they just said to decrease the zoom level in the browser. Of course, they blew me off when I asked how that reduced the ratio of whitespace to data, which leads me to believe they're in denial of the problem. Just to reiterate some sentiments already expressed here, "Spacious. Minimalist. Clean." is great for consumer/entertainment/etc. apps, but you can pry my data-density from my cold, dead hands when it comes to business apps where real work needs to get done.
Sounds like UX failure.<p>A large part of design is incorporating obvious workflows from non-obvious systems.<p>User testing, iterative development, some type of strong feedback loop are all tools we leverage to combat this outcome.<p>I understand why the title was used but it really falls short in highlighting just how critical and valuable UX is as part of the development process.<p>It isn't just these stylish hipsters building art on storyboards which is what I am arguing your title implies....its about UX bridging the user with the developer as well ensuring their voice is not only heard but can drive the process.
This reminds me of those older systems that had a learning curve, where employees were trained in them, but they were efficient to use. Navigation was all keyboard-based, making extensive use of the function keys. You'd be talking to an employee and while they were using the system, they'd be confident and hitting all kinds of memorized keys to jump around and look up parts or orders or whatever. As those systems get replaced with more "intuitive" web-based UIs, where navigation is done with a mouse, and they are sold with the prospect that there isn't much of a learning curve, it seems there are more folks that don't get to that level of confidence and efficiency. Maybe it's due to lack of training, or the software isn't designed for efficient use, or web-based UIs tending to change more frequently, or the backend systems being less responsive and reliable... I'm not sure. But it sure feels like I encounter more people saying "well the system isn't doing what I want it to do today" or "let me just figure this out I'm not seeing it here". I like seeing software empower people, not make them feel inferior, so hopefully it's a temporary trend. Or maybe my view is just skewed through the lens of nostalgia. I hope I never see the day when grocery store checkers have to fumble through an ill thought out web-based UI...
I think another lesson to learn is "if it isn't broken, don't fix it". I think we all have used apps where we got used to one thing and then there's a UI design that changes everything.<p>As an example that really has no major impact (but I think illustrates subtle changes), I got mad with the Android 9 update. The number one thing I was mad about was the clock placement. Every previous generation it had been placed in the upper right. Since 9 it moved to the top left (same as iPhones). Problem being that Android literally trained the userbase to look in a specific area for that feature and then moved it. Sure, I know where to look now, but I still frequently look at the top right first.<p>Feature changes like this I don't understand. I can't understand how it would be a significant factor in converting users (which in this case the platform had majority market share) and also results in confusing (rightly so) the existing userbase.<p>Not working in UI I see them a lot like QC (but with more work to do). If everything is working perfectly QC should have nothing to do. Just like if your UI is good then it shouldn't be changed. I don't understand this "need" to always change things. Sure, there are legit reasons to do so (just like QC <i>NEEDS</i> to exist (for the love of god don't get rid of QC)), but I see a lot of changes that happen that don't make things easier and appear (from the user side) to just be change for the sake of change.
> See where you might reduce visual complexity by combining elements — for example, by putting a customer’s first and last name in the same field.<p>Great, until people want to sort/filter by stuff that is now crammed in to one field. Sort by state? Sorry - it's now "city/state/country/postalcode"<p>Some people will want things one way, some will want it another, and you'll be tasked with making it work "both ways" - just add a checkbox to check to switch how it works. How hard can it be, right?
You can get a beautiful fast and dense interface if you want one. But then you need someone to actually <i>design</i> it for you.<p>Most design that happens today is actually <i>Styling</i> rather than design: you just slap some framework on everything select some colours, apply some layout patterns and call it a day. Maybe you “go wild“ with some minor detail and are proud for beeing a rebel.<p>Like with architects who like to use glas and wide open spaces everywhere, regardless of social use, this is what divides really good designers from mostly ok designers.<p>Design is not finding the same clean, minimal look for everything, but looking at every interface that has been designed (including physical interfaces) and asking the question what is appropriate. And let’s face it: sometimes your design is worse than the unstyled browser default or the “readability mode”.<p>Design should be a lot of work, but like always you don’t pay an expert just to get it done, tou pay them for their experience, their knowlede and their ability to treat your project the way it deserves to be treated. This takes a little longer, but the iconic minimal designs everybody and their grandmother knows (Rams Braun radio for example), were 90% thought and the rest was styling and technical problems to be solved.<p>If you have a chance, please hire someone for actually thinking about a design and critically analyzing things they try out — this is were all great usable designs come from. If it looks modern as a side effect, so be it. Give them somebody who knows all hairy technical implementation details as a side kick and you are good to go
This is exactly how I feel about FreshBooks’ redesign last(?) year. Sure, it looks a lot prettier and I assume discoverability is better for first time users, but it feels overly dumbed down, information density is much lower, and common tasks take longer with more friction.<p>There is always some resistance to change at first, but over time I’ve only grown more frustrated with it rather than getting used to it, to the point where I’m starting to evaluate alternatives now.
This is where user research would have saved time and money. Rework is expensive so is slowing down staff. Usability testing would have determined this prior to launch.
Its important to distinguish between apps that have super users and then apps which is really just for consumption. Super users apps might have features that if you use them once in a while it doesent matter if they are a little more cumbersome if in exchange you get a cleaner and easier to understand interface, the problem arises when clean gets to trump feature and functionality which is used all the time.
In my opinion the lesson to be learned here is not design related, but requirements related. Gather your requirements from your users before you implement a change, otherwise you're just working off of assumptions, and that's just bad practice.<p>If you have Product Management the failure was on them for not driving the customer need. Also, this is not me just scapegoating PM... it's actually what I do
This article reminds me of Japanese web design and how <i>dense</i> it is. It's almost a bit like the 'western' web when Craigslist was first launched. Ultradense, kind of ugly, but extremely utilitarian.<p><a href="https://randomwire.com/why-japanese-web-design-is-so-different/" rel="nofollow">https://randomwire.com/why-japanese-web-design-is-so-differe...</a>
The real problem here is the lack of UX Research that went into designing the new interface. All of this could have been foreseen before the design project even started.<p>The whole point of UX research is to avoid expensive redesigns/features/products that users don't want. It is future oriented and pays for itself tenfold in avoided missteps in the product lifecycle.
The author suggests Google’s “Material” but in my experience, Google has it wrong compared to Apple’s Human Interface Guidelines. For example, Google hides stuff behind icons with no text. Unless you already know the UI, you are hunting around for what you need (remember screensharing on Google Hangouts?) On Apple’s apps, icons always come with a text label and rarely are things hidden behind unnamed icons. Google also seems to be changing UI constantly. Material Design is terrible — it’s the very essence of the problems being mentioned in this article. Apple’s Human Interface Guidelines also address accessibility far better than Material design. Maybe it’s me, but it does feel like there are camps when it comes to UI: the Material Design side and those that care about usability for people that don’t spend their time in the Googleverse.
The typical person making a purchase decision doesn't know what the app does in any detail. So if he sees less information on screen he thinks it's easier to use, as compared to more information on screen. Of course the opposite is normally true, which is where the trouble starts. It also looks similar to simple consumer apps that the decision-maker is used to. Finally the UX designer says magic words like "clean" and "simple" and "focused" and "beautiful" and the sale is made.<p>The lesson here is to find way to counteract this. User engagement metrics would be the last line of defense. Earlier than that maybe small focus groups.<p>But something is already lost by the time we got here - we're not on the same page wrt what is important and what are the criteria. I'm open to suggestions here.
I don't really agree about the merging of information (the rest is fine). In the example, what happens if you want to sort by state or zip (assuming they are sortable)? The upgrade is really just a downgrade functionality wise in that case. This is something I find happens time and time again, an app will get redesigned and lose functionality to look simpler. It might not be the case here if it doesn't need to allow sorting, but I hate that general trend/idea.<p>There are better ways to have less crowded information (custom optional columns), that doesn't remove functionality. Also the more flexible a UI, imo, the better, so long as the flexibility does not increase complexity too much and it's obvious (if the setting for the columns is hidden in some obscure place, it's useless).
I worked at a company whose name begins with K ... exactly this happened. The 'old' UI was an ASP nightmare from the early 2000s but it contained all that the users loved. The new thing never took off, despite the CTO putting his job on the line for it.<p>Another company had a green-screen nightmare from the 1980s replaced by some mouse-driven mofre modern UI - ditto. The users could easily naviate with arrow keys, tabs, function keys. It was FAST. The new UI, and it's even newer HTML replacement, both needed the mouse.<p>Hard to sell and 2002 nightmare or a green-screen to a prospective client - but they LUURRRRVE a cool modern Angular UI, but the people who buy thing thing aren't the ones who have to use it.
It blows my mind that to date we have major companies who put forward horrible UX. Few come to mind off the top of my mind: Chase, PayPal, Digital Ocean. Trying to get statements from Chase is like playing ping pong. Webflow, Freshbooks, all major offenders.
There are tradeoffs when designing for <i>first time use</i> vs <i>repeated use</i>. And also between simple and powerful. Like a GUI vs a Terminal. Or keyboard shortcuts vs Menu. A user configurator vs a cad program. Or when it comes to game design - first time vs replay vs endgame. Maybe Ux designers can be inspired by games - designed for engame (multiplayer) but with campaigns with a progressive difficulty ...
This could have been written about the redesigned user panel for gandi.net. The old one looked like Windows 95, but it was very usable. The new one seems to be made as a lifestyle site for mobile users on the go. So not me. I emailed them my concerns, as a good customer and citizen. Didn't get a response, why would they bother? So I voted with my wallet and migrated all my domains.
> Are there things my users really don’t need to see right now?<p>Yes, what about the ridiculous amount of space taken by the header and footer on that page.
Oh the irony of posting this on medium. On my laptop the content is merely 30% of the screen - there's a big banner, pop up, and big footer. To boot to that 60% of width is dead white space too.
I'm excited to see the death a frankenstein medium.com has become - it's completely unreadable without postprocessing extensions.
I don't think the root problem is white space.<p>Taking the dictionary example: A good dictionary doesn't display a hundred words per page. Instead, you just need a box to write down the word you search and a few lines to display the results. Plenty of space for the designer to turn white.<p>The problem is somewhere in the process where someone creates an app without having experience with the old system and not understanding how the app is supposed to be used. It is quite common that UX designers do not have that kind of knowledge, but then they have to make sure to include people who have it (workshops, interviews, prototype testing, etc.).<p>I am not saying that white space is always good the way it is used today, but the problem isn't a clean look. The problem is a dysfunctional design and the process that caused it.
In the "Use color deliberately" paragraph the table has a column of numbers that are left justified. This makes comparing adjacent rows very awkward. The should be right justified. This is such a simple thing to get right yet it is nonetheless very common that it is done wrong.
I think interfaces should be constrained to match the specifications of your input devices and screens. If your users use a mouse, then dense windows with lots of check boxes and radio buttons is usable, and probably preferred. If your users might interact with fingers on a tablet or phone, then you need more space around things to make it easier on the user.<p>I've never been a fan of trying to build one interface that works for all systems. It sounds great in theory, but in the end you are left with everything at the level best suited for the least capable system. Same goes for games, by the way. If you see I'm using a mouse and a keyboard, present me a different interface than if I'm using a controller.
I am building an enterprise-y software (a 1:1 meeting app[0]) and, not being a designer or UX expert, I am taking some chances with the design.<p>I am using a dark background and I am aiming for a design heuristic where everything of common use is reachable with scroll and 1 click. It becomes a long page the more meetings and notes you had. This does not leave much space for white space.<p>I am also being bold on the use of colors to differentiate where the user is while among all that scrolling.<p>I am not sure I am right in any of my choices, but this article makes me think I am on the right path. Even if we have different instances on scrolling<p>[0] <a href="https://www.oneonemeeting.com" rel="nofollow">https://www.oneonemeeting.com</a>
This quote (below) reminded me a story...<p><pre><code> “There should be a minimum amount of furniture (rules, boxes, dots, and other guide rails for traveling through the typographic space) and a maximum amount of information.”
– Robert Bringhurst, The Elements of Typographic Style
</code></pre>
A company I know of, had rolled out major UX changes in their bug tracking system. One of the changes was complete removal of all borders on text boxes on bug entry screens. Imagine a page filled with text boxes, with not a single clue of where they are except labels above them. Users literally revolted. The change ended up becoming an option just for that company.
I see this all the time. It is a symptom of blowhard UX designers who don't understand there's a difference between mass consumer and enterprise app design. They look at a shitty looking enterprise interface and snort <i>"I can make this so much better! Let me introduce you to Material design!"</i><p>If you want to make pretty little apps that get you tons of likes on Dribbble or whatever, go make consumer apps.<p>When it comes to enterprise apps boring is beautiful. I'm talking dense data displays, esoteric shortcuts, NO optimistic saving behaviors, etc. Everything that classical consumer app designers hate. The point of an enterprise app is all business.
>Consider using monospaced numbers when comparing digits between rows matters.<p>For the love of god don’t only consider it, actually use tabular numbers in any context where the number is not part of a sentence or something similar.
>>>> Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips!<<<<<p>I understand this but before agreeing to this, I think one should look at the issue of "change management". By default, people resist change. Once you get used to something, it is difficult to adapt to a new one (even if it is better). If the UI is "really bad", then it should definitely be changed but this should be done in tandem with change management (lots of training, slow cut-over to the new system, etc).
Have to agree with this. Too many times I've seen UX people brought in who see the ONLY path to simplification as removing things /they/ don't perceive as necessary. They're flat out wrong - you can simplify also by using the suggestions mentioned in this article.<p>Sometimes the strategy pays off. But for enterprise apps with high information density it often doesn't. New systems end up lacking essential features just because a few people who never needed to use the original system (and would not need to use the new one either) end up stripping things away.
And PLEASE don’t break the keyboard with your bespoke (buggy) reinvention of html. Specifically Ctrl-F and the back button. Oh, and <select>s. I could go on but it’ll just make me sound grumpy.
I rewrote 12k Powershell application for a previous job. Thing was ugly, full of errors, but they had been using it forever.<p>Turned it into a webapp. It didn't last three weeks. The users didn't want change. My app was able to increase speed by about 10%, management wanted it. But the guys in the call center didn't like it. Unlike the redesign in this article, I spent a year using that Powershell app and was very familiar with how it was used and its shortcomings.<p>There is something to be said for just wanting the status quo.
> <i>A large business by its nature has massive-scale data and usually thousands of users who directly interact with it—searching, manipulating, reporting, and more. They need to move through that data quickly, without a lot of digging around in the interface.</i><p>The challenge strikes me as less handwaving assertions of what "large business" ops is about, more understanding user needs and capturing intent with a UI that balances productivity and experience.
> Look at Material’s Updates
No! If you're thinking about your enterprise application like an android app then you're starting in the wrong place.
remember a guy who worked in some fany BLUE in basic developed application for accounting on his dosbox windows xp. he wanted a new tool, he had a bunch of web apps made for him, but all the time he hit the simple fact, that page refreshes and lack of keybindings made his work incredibly tedious and slow.<p>Made a curses implementation of his old application so he could work full speed with the exact same interface and keys. a modern implementation of his oldskool app, so he could finally ditch dosbox and windows xp for a more modern operating system. happy chap after that, he wondered why people even use web UIs for local things.<p>funny lesson in that 'modern' doesn't mean 'fancy', just like in this case. you can modernise something and not make it fancy, that is what they wanted. this guy made it fancy, which is useless.<p>i try to tell people (hard to hear for IT people i know) that internal applications are not 'user apps' in the same sense a website is. so they should be treated differently as well.
if you would ask the users what they want before redesigning the thing they use for hours a day i'm sure such mistake can be prevented.
I'm somewhat in the minority, but I like plain html that puts the right stuff in the right place way better than an unnecessarily designed masterpiece.
This reminds me that I should go back and re-read "Don't Make Me Think". So many of these things seem obvious, but only when pointed out.
For any UI that has long running power users, however complicated, the users will over time memorize how the screens look and operate. It doesn't matter how 'intuitive' the redesign is because you will have broken their rote patterns - and the user has to rethink how they use the software, often at every turn. In the high paced environment of a call center this is simply untenable.
This is everywhere, not just enterprise. Take a look at craigslist and how every attempt to make it "pretty" has failed. Many successful products are focused on getting things done, even if they're exceedingly ugly in doing so.<p>There seems to be a lack of education and experience in
teaching designers that UI != UX and what design really means is helping users reach goals, not just looking nice.
Speaking of data intensive applications, I find it really hard to design a complex UI with popular frameworks such as bootstrap/antd because of the amount of padding/white space in input/select/row/column components. Always have to adjust the CSS/LESS/SAAS/whatever to get to an optimal amount of whitespace.
Everybody says the designer should learn the user's workflow. But for complex workflows the designer is not going to learn everything they need to know. I think the other way around is better: let the users tweak the design. UX isn't that hard to learn or understand, especially for industrial systems where aesthetics are not important.
For every case where there is excessive whitespace, I see 10x where there is way too much clutter, and not a single place where one can click (for example, to bring the browser's window back into focus) without activating something. This sounds like a problem of not talking to your users enough, not a problem of too much whitespace.
I think that this is more of a tale of not doing proper user research. If they've done their homework, they would know what data users of the platform need at their fingertip, and they wouldn't have hide it behind clickable-collapsable UIs.<p>My take on this: work with a PM that's really good at doing (proper) user research.
Speaking of not understanding the users while redesigning, anyone remember Digg?<p>Digg's downfall started with a redesign: <a href="https://www.fastcompany.com/1690829/digg-redesigns-loses-more-quarter-audience" rel="nofollow">https://www.fastcompany.com/1690829/digg-redesigns-loses-mor...</a>
I think the problem stems from the responsive designs that were used to build really slick sites for marketing purposes. Everyone wants to apply the same aesthetic to what are really software applications running in your browser. These are very different things and should not follow the same design guidelines.
The local bank office used to have text terminals (ok, this is a long time ago).<p>I distinctly remember that they got <i>much</i> slower at getting work done when they switched to a colorful GUI.<p>They did not switch back to the text terminals. If you deal with processes that don't change much, it's a questionable decision.
The example where the author takes a row of address data and merges the columns, with the caption: "easier to scan"<p>No, its really not. Anyone with a hint of dyslexia or similar will not forgive you for merging cells together.<p>Its just not easier to scan. What would have made it easier? first name first.
This person has it all wrong. If there are too many nobs and too much data for a person to comprehend, then it means you need more automation. The people who complained about the GUI are the people who will probably lose their jobs in the next decade to machine learning.
I think about this every time I watch some physician friends using Epic or any Electronic Health Records system. Those things are dense as hell and packed full of data and utility. You won't see a bit of wasted space. Different problems require different solutions.
Was there any usability testing done on this throughout the entire design process? I don’t see the word “test” in the article mentioned once.<p>Seems like the process is what failed here. Maybe there was zero feedback loop between the creator and the consumer?
This is exactly the Google plus vs Facebook argument I've been making over the years. 'Plus', with all it's white spacing was arguably ugly and this was also why it had low user retention that led to it's demise.
> It used progressive disclosure to hide presumably insignificant information.<p>This is the line that shocked me the most, emphasis on the word <i>presumably</i>. It comes off as a decision being made without any sort of objective data behind it.
Usually when I hear that something "killed an app" I think "software stopped working", not "users didn't like the new look".<p>To be clear this is a "users didn't like the new look" story.
Sounds like a classic “throw it over the wall” redesign without getting input on how users experience the current application. Great recommendations in the article though — loved the address readability example.
Ironically not listed as a solution: use skeuomorphism.<p>Skeuomorphic interfaces, for all their pitfalls, are good at visually separating interface elements for quick comprehension without requiring mountains of whitespace.
If the "UX collective" thinks that site is what user experience should be, then I think it's time for a military coup. It's really hard to read.
I find it quite telling that no major takeaway mentioned talking to users or testing the design. This reeks of genius design, which really isn't genius at all.
The author seems to have completely missed the lesson that designers should get buy in from the people who actually use the tool, or at the very least should be required to use their own design under realistic conditions. If you just want to apply design principles and not worry about whether your work is accessible, stick to fine art. I feel no sympathy for the designer in this scenario, s/he deserved to fail.
White space didn't kill the app. A lack of adequate analysis, interviewing, and user testing killed it. Let's be clear about this; design trends in themselves aren't the issue, it's their improper usage.
TL;DR: 1. Design for design
2. Wilfully ignore business requirements in favor of visual groupthink
3. Feign surprise when your brand-new, byoo-tiful and oh-so-modern app is unusable, blame your tools
A great example of a really nice information dense app is the Bloomberg terminal. Maybe it’s ugly (a lot of people say this, but I personally don’t think so), but all the right design choices have been made. High Contrast, monospaced fonts, extensive keybindings, absolutely no wasted space. And, most essential, it’s not a web app.<p>I used to work at a portfolio analytics company who’s explicit goal was: to have all of Wall St use Bloomberg on one screen, and our product on the other.<p>Our app was probably the anti-thesis to the Bloomberg Terminal in almost everyway: “modern” design, tons of white space, a web app, making you have to log in every 30 minutes for “security”, no keybindings.<p>I’m sure most of HN have never used the terminal, but let me give an analogy. The Bloomberg Terminal is like using Emacs or Vim, they make you feel powerful, they make you feel like a wizard.<p>Our app was like google docs, you never felt like you were in direct control of it. You never felt like it was an extension of yourself. Unsurprisingly, even though our app was incredibly useful and provided portfolio analytics that you could only get from excel (our biggest competitor), it, and the company, was largely a failure. Instead of being worth billions, we were capped at a valuation of 200m for over 5 years.<p>I believe completely that the company’s failure was due to our “modern” white space heavy app.