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.
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.
> Except users lie all the time...
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.
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.
Also consider that users often have a tendency to rebel against change. Habits and routines are hard to overcome and the actual might be that features and data simply aren’t in the same place they used to be, regardless of if that new location is much more reasonable. I saw it again and again: Users memorize hard-coded paths to certain functions - simply changing the name, appearance or position of certain elements along that path was enough to throw them completely off the track.
White-space became a "thing" because of the increased use of touch-screens, such as iPads and smartphones. The space helps avoid fingering mistakes. However, if the vast majority of users are using a keyboard and mouse, it's an anti-feature. People started copying the trend without thinking about and road-testing the practicalities of it. Unlike the Kardashians, science works.
It seems like that argues against changing it to me, at least in productivity-sensitive applications.
There could be a justification in revamping the interface if there is an expected amount of turnover or the costs of training are significantly higher, of course. Often, though, these are situations where form should follow precedent, not just function.
A better process may have reduced the likelihood of a bad design, but the bad process is the meta-problem, not the problem-problem.
Some design decisions really are bad in ways that are counterintuitive to a lot of designers. Reducing information density is often one of them.
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?
If you make something that is valuable but doesn’t give the users a power trip, it will fail. This is just how people work.
Vim and Emacs give you actual power, not just the feeling of it. Vim's "shortcut grammar" and Emacs' deep interoperability are a huge productivity multiplier for any imaginable task that you can reduce to manipulating text.
Information density is about providing context. A good example here would be Google Maps. The app is optimized to be used as a point-to-point navigation tool, but some design decisions - like inconsistent showing of street names - make it pretty much useless as a map. Your UI design may be leading the user down a prescribed path, but if you make it show the minimal amount of information necessary on that path, the UI automatically becomes useless for all other related paths.
I find that kind of arrogant. In a lot of cases, the UX designers simply underestimate the real complexity of a task.
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.
So, I used a nifty service (http://soundiiz.com) to sync my artists across multiple services. I hate the idea of paying for Yet Another Service, especially because I'm paying for one (Youtube Premium) that's useless for music because Google won't respond to bug reports, but I started to spend some time in Spotify.
Spotify is uglier than Youtube Music, but a thousand times more useful. Part of that is the more active community (artists that I like which have 0 followers on Youtube Music will have hundreds or thousands of followers on Spotify) and more engaging playlists, and part of it is that I was able to "get" Spotify features and navigation quicker than Youtube Music... which is still feature poor as they migrate from Play Music to Youtube Music.
So, to me.. Spotify is uglier and far more useful.
A lot of good design is minimalist. I don't know if it has to be. Sometimes it makes sense to present a lot of information in a dense block
As a trend I can't wait for it to die in fire.
But imagine staring at Foobar2000 all day as if it is your primary work. You probabbly are looking for just some of the data most of the time and filtering the rest... so in that case maybe less would be better.
On the other hand if you glance at it and want lots of data without clicks, then dense is great.
But your point about "logical" is the key for dense stuff, and getting to what is "logical" can be hard.
There's a great series by Jensen Harris, Office Program Manager, about how they designed the Ribbon: https://blogs.msdn.microsoft.com/jensenh/2005/09/26/the-why-... (you can find the rest in his blog archives, unfortunately the images are gone)
It was an incredibly complex undertaking, Microsoft did many studies, had focus groups and the whole thing (Office after all, is a major business to them, worth billions of dollars).
The end result was demonstrably better for the vast majority of users (Microsoft had hard numbers to back their design decisions).
And yet if you read many of the comments on tech forums you'd think Microsoft killed the users' puppies.
That something I didn't realize until lately but aesthetics is hugely important. We once updated our internal issue tracker and everyone raved about how better it is now. The thing is: absolutely nothing changed for the average user besides the style. Things like more tasteful color choice, a more modern look with square corners, etc... nothing practical.
Also, from some guys at Microsoft: if you didn't change the UI, from the user point of view, you didn't do anything.
The problem with modern UIs for beginners is that too much is hidden. Panels that only appear when swiped from the side, parts that give no indication of being clickable, highly abstract icons, lack of consistency (ex: the "hamburger" menu can be anywhere, or not be present at all).
I think the underlying thing is that simple UIs sell better because you're usually presenting it to someone that can't visualize their complex workflow needs up front. The number of times I've seen requirements that are basically sales enablement features that customers would rarely use is not insignificant. Similar to focusing on usability for low-res displays, when the only time the app would be used on a low res display is when hooking it up to a projector in a demo.
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.
Chrome developer tools now shows you the contrast ratio along with these recommendations when you modify text colour.
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.
I'm familiar with 3d software suites, and they're (mostly) all highly-configurable, permitting custom layouts, panels, toolbars, and even enabling intermediate users to create UI tools.
To your point, they're also ferociously complicated for novices.
Bloomberg is a funny example. It's a well-indexed reference, rather than an expressive tool, so mastering its shortcut-dense interface is an affordable cost to professionals of modest technical sophistication.
I wonder if TurboTax is in the running; for all its blandness, in 2019 it's exceedingly transparent and clear guide to doing an extremely complicated task. I hasten to acknowledge that's hardly going to be a universal belief.
Maybe Gmail? But again the functionality is fairly shallow...
Tufte talks about minimizing "chartjunk", maximizing "data ink", and being comfortable with high information density. Charts are tools, and while they may sometimes require some amount of effort to understand, they play to humans' strengths like scanning and pattern matching. I think Tufte got this very right, and it generalizes well to user interfaces.
"What’s the lesson here?", asks the article. It seems to me the lesson is don't hire UX designers that are ignorant of basic seminal work in UX.
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 miss companies like Palm that had a person who counted the taps to get something done.
Perhaps the only people happy with the migration were the Oracle sales reps.
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.
> This also makes me question the veracity of the article.
Personally I thought the opposite, I find it a fantastic quote from the article as it exactly describes the problem:
Things that used to take a single click taking multiple clicks with slow animations between them because "design" and information not anymore visible on one page even though the human visual system is very well optimized to deal with that vs waiting for multiple screens.
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?
This can also present unexpected difficulties for people who's "first name" contains a space. It will appear as though that unified field contains their middle name too, which it might, but the customer might be using their middle name as a de facto part of their first name in systems such as on their credit card.
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...
##.overlay-dialog
##.overlay
##.u-fixed
##.metabar
I used to open dev tools and add the style: visibility: hidden; but that got old fast.
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
“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.
A major advantage that often seemed to be overlooked in the rush from terminals to web pages is that if you pressed a key that took you to the next screen, your next keypresses would be queued up and they'd go into the next screen when it was ready. So if workers were following a familiar process, there was often zero latency when changing screens because they could just start typing into the box they knew was going to appear.
Web based things made this worse because you have to actually wait for the new page to load before you can start typing.
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.
Ahem...
"How Medical Tech Gave a Patient a Massive Overdose" https://medium.com/backchannel/how-technology-led-a-hospital...
> Do you spot the problem? Perhaps not, since it is hiding in the middle of this dense screen,
(that quote is from part 2 of the series of posts)
Of course that's not the only reason this incident occurred, but it likely contributed to it.
Seems like the process is what failed here. Maybe there was zero feedback loop between the creator and the consumer?
"Sure, the old system was ugly, but it had everything they needed, right at their fingertips!"
"They didn’t have time to click or scroll to find information while the clock was literally ticking."
Sounds more like they added way more friction in the new design. Users now had to click multiple areas to fill out everything they needed which slows down work flow.
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.
Not a better phrase to describe a Bloomberg Terminal. Everything is there, mainly data, quick charts, Messenger and with it 'social' (yes, Bloomberg Support do make restaurant recommendations if asked), quick facilitation to sometimes complex questions through these services, handy linking to Excel, and where data quality was questionable a quick response.
I think what Bloomberg did/do was/is listen to their customers. A Bloomberg today is much like when I first touched it 20 years ago, but it isn't. It feels the same, or similar, the screens are vastly larger, does what it has always done, scales. There are no redesigns that stop a user doing what they've done before, yet allow them to do more. It is what is expected and surprises, sometimes frustrates, but a learning curve and pleasure comes from learning.
The colour scheme also looks good. A black background gives you many more high contrast choices. Try using yellow or cyan on a light background. It seems most of the colours are based on the old 8-bit selection; red, green, blue, cyan, yellow, white and black. Orange seems to have been added as well.
It's funny how little credit we give to business users these days, and how much marketing UX there can be.
There was a time when business students attending college and their crufty professors could manage using email by telneting into the mainframe to use Pine. And the technology was a wonderment to them.
It's an attractive font.
Me too! I wonder if it was the same company?
> Our app was probably the anti-thesis to the Bloomberg Terminal in almost everyway: “modern” design, tons of white space
It was not.
Also how are monospaced fonts "the right decision"?
GUIs generally represent the sacrifice of power and automation for approachability by the lowest common denominator.