Whitespace killed an enterprise app

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.

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.

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.

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.)

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.

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.

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.

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.

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.

---

The 8 UI updates the Chase website goes through before it finishes loading/you can see your recent transactions:

1. Initial blue loading screen with a spinning loading icon

2. Tan colored background color replaces screen #1

3. Header loads

4. The blank outlines of the main UI components loads (without any data in them/with placeholder loading bars)

5. All of my Chase account metadata (account type, current balance, and last four digits of the account number) loads

6. More in-depth data of the first account on the list loads (available credit, payment due date, minimum payment due, etc.)

7. Recent transactions panel starts to load (with no data/with only a placeholder loading bar)

8. Recent transactions are shown

At this point, the page is finished loading.

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 stuff?"

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.

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.

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.

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.

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.

White space isn't just white space, it represents the expression of functionality to the customer.

The UX design question always takes you back to first principles, who is your customer and what do they need?

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 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?

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.

To this day I am still astounded that more than one person thought #BFBFBF is a perfect colour for text on a white background.

I want to wake up from this nightmare. Software like Bloomberg Terminal and CATIA doesn't need to be beautiful web apps with clean, !minimal! Material design, 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.

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.

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).

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).

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?

> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)

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.

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.

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.

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.

It's not "function over form, always"

It's function with 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.

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.

The flawed approach described in the article, was form over function, which is the identical conceptual 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.

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.

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.

I have several scratch-my-eyes-out sites I use every week for fodder and am sure you would never lack for suggestions.

> 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.

The lesson here is actually that the designer didn't understand the context in which customers were using the app.

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.

If they had done any of the above, they would have had a lot more context about what a good solution looked and felt like.

A large part of design is incorporating obvious workflows from non-obvious systems.

User testing, iterative development, some type of strong feedback loop are all tools we leverage to combat this outcome.

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.

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.

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.

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.

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 NEEDS 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.

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"

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?

Most design that happens today is actually Styling 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.

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.

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”.

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.

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

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.

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

https://randomwire.com/why-japanese-web-design-is-so-differe...

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 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.

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.

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).

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.

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.

Yes, what about the ridiculous amount of space taken by the header and footer on that page.

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.

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.).

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.

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 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.

I am also being bold on the use of colors to differentiate where the user is while among all that scrolling.

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

[0] https://www.oneonemeeting.com

    “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

If you want to make pretty little apps that get you tons of likes on Dribbble or whatever, go make consumer apps.

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.

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.

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).

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.

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.

There is something to be said for just wanting the status quo.

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.

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.

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.

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.

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.

My take on this: work with a PM that's really good at doing (proper) user research.

Digg's downfall started with a redesign: https://www.fastcompany.com/1690829/digg-redesigns-loses-mor...

I distinctly remember that they got much slower at getting work done when they switched to a colorful GUI.

They did not switch back to the text terminals. If you deal with processes that don't change much, it's a questionable decision.

No, its really not. Anyone with a hint of dyslexia or similar will not forgive you for merging cells together.

Its just not easier to scan. What would have made it easier? first name first.

Seems like the process is what failed here. Maybe there was zero feedback loop between the creator and the consumer?

This is the line that shocked me the most, emphasis on the word presumably. It comes off as a decision being made without any sort of objective data behind it.

To be clear this is a "users didn't like the new look" story.

Skeuomorphic interfaces, for all their pitfalls, are good at visually separating interface elements for quick comprehension without requiring mountains of whitespace.

High density data in good looking is still possible.

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.

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.

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.

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.

I believe completely that the company’s failure was due to our “modern” white space heavy app.