Hacker News new | past | comments | ask | show | jobs | submit login
Whitespace killed an enterprise app (uxdesign.cc)
708 points by kirkbackus on Feb 13, 2019 | hide | past | favorite | 435 comments

Hallelujah. It's not just enterprise apps, either. I've seen more than a few consumer app redesigns that just seemed to tack on the "clean", "minimalist", "whitespace" ethos, without really having a clue of an understanding of how users actually used the product.

I think this is a big factor in what killed slashdot. They did a big redesign years back that added a lot of whitespace but actually made it incredibly difficult to easily browse comment threads and see quality comments. Similarly, despite the old Reddit interface having a reputation as being "ugly", I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.

> I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.

I'm actually trying to "redesign" an app (I put design in quotes because I'm a dev and just trying to make a personal project look nice) and one of the struggles I have had is that high information density can look crappy at first but once you get used to it, is a better experience. So much nicer to have everything you care about in a single screen.

> high information density can look crappy at first but once you get used to it, is a better experience.


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.

Make an optional pro interface so noobs get lured in for the prettyness and when they know what they are doing, can swith?

Why have one interface if, for twice the money, you can have two?

Clever girl.

God yes, the older reddit interface was so much better. I don't give a shit how pretty the UI is.

Craigslist is _the_ case study on how an ugly UI can survive over a long timeline. There are many techies and UI designers that are just disgusted at the UI of craigslist. For some, aesthetic is more important than usability. Luckily, for most, it's not.

Not to forget amazon.com. I am actually in awe of their boldness in completely ignoring UI design trends.

Amazon has purposefully broken their search and navigation, but probably in an anti-consumer metric-driven way instead of designer-driven.

Ebay is the pinnacle of broken search and navigation! They should be winning awards, industry accolades, Webbies, the works!

I find eBay search more predictable than amazon. When I use amazon I feel that they show to me what they think I should get instead of what I want.

Ebay removed substring search years ago, and this basically collapsed a whole bunch of industries that were using Ebay as their marketplace. Think hundreds of thousands of similar part numbers. This is why you see pages of part numbers blasted over the listing details.

Ebay's one job is to connect buyers and sellers and they fail miserably at that.

Not even a local minimum, a global minimum. Not a platform, a gated swamp.

Yes, both Amazon and EBay are bad examples.

They are old-school because they are lazy about it, not because something is already optimized.

Whenever I hear about how great a Amazon is as a company, I just do a single search and am dumbfounded.


If you type the name of a product - even when it is in their catalogue - it may not come up.

Search for 'mousr' on Amazon and you only see PC mouses.

The only way you can get to the mousr product is by typing the company name.

It's ridiculous.

Tip of the iceberg.

I can sort by price on eBay. On Amazon, I have to jump through a bunch of hoops to finally be able to sort by price, and the results I get are far from exhaustive.

I find eBay search pretty fine for my purposes. They could allow for more fine-gained structured descriptions, though.

Amazon search is in comparison much more... approximate.

I think that has a lot to do with Bezos saying "no" when it matters, like Jobs did at Apple.

Amazon's interface is pretty bad, though, especially in the video and kindle areas. I know I'm constantly frustrated using the site, and as far as I can tell, they don't appear to be very interested in reducing user's pain.

they probably follow the money instead of trends.

Well, minus their shit video streaming site, I agree.

Yes exactly. CL is probably my favorite website on the internet, for the sheer reason that they have virtually not changed at all since they first launched over 10 years ago. It's fairly incredible. I can't think of another website that has done that.

> I can't think of another website that has done that.


This still exists?! It's still being updated?!?! So much more content than when I last checked it, which would have been 2004 or so. My faith in the internet is restored.

holy shit

I don't think the Berkshire Hathaway site has changed much:



> I can't think of another website that has done that.

Hmm, I'll give you a hint. You're looking at it.

CL is only ten years old? I always figured it was from the 90s — maybe a bias originating from the design.

It's over 20 years old, it launched in 1996. Time flies.

oh wow, I stand corrected. I always thought it was 10 years old because I discovered it around 2008. Sheesh.

Remember Windows XP?

Fun fact: we're further away from its first release (2001), than it was from Windows 1.0 (1985).

Remember Windows 7?

We're further away from its first release (2009), than it was from XP.

Win7 certainly has some rough edges in retrospect, but I occasionally interact with old systems and so many things are so much snappier. I'm sure the modern frameworks in Win10 allow for "new experiences" but the plain old desktop experience was well served by Win7.

And those of us who do remember Windows 1.0 (not using it, though, but I do remember the ads), are probably mostly closer to retirement age than to the start of our careers... I feel old now.

Craigslist was a true innovation when it started.

I think craigslist survives _despite_ its ugly UI just because of market lock-in/inertia. the ui is awful from a utility/ux, pov - it’s limited and hard to shop/browse with.

Definitely - there used to be a bunch of sites that scraped craigslist and put their listings into more browse-able formats (e.g. Padmapper), but once they got too popular, CL started sending C&Ds and filing lawsuits.

Craigslist is _the_ case study on how an ugly UI can survive over a long timeline.

I wouldn't call the CL UI ugly. It's certainly not beautiful, but I'm not sure how it could be described as ugly. There's something in between, right?

It's not aesthetically polished, but it's well though-out. So it works.

Amazon's website comes to mind, also

Wikipedia would make this list as well.

apod.nasa.gov is the classic example for me

The Drudge Report is another one.

That’s the strange thing about reddit’s new design: It not only lacks functionality and performance, but also white space and clean aesthetics. It feels dated already.

It's also slow, unresponsive and breaks all the time. The dark mode toggles back to bright mode randomly, posts sometimes don't render... It takes multiple seconds to render the comments in a thread. It's a mess.

it was designed to make it easier to integrate ads

The thing is that the new interface can take seconds to load whereas the old one was instant.

How is this an improvement?

It's better for them, not necessarily for you.

Reddit wants lots of growth (they are taking new money now I think) and that means lots of new users that don't know the old UI. The new one is designed with those users in mind, not ones that know the site inside and out already.

It's sanding down a barrier to entry that was already fairly low, in my opinion. They haven't really made it much lower either.

Integrating RES into the main site would've been most of what they needed to get going...

imo the killer feature of RES is that it makes it extremely easy to manage arbitrarily many sockpuppet accounts. there are other nice features of course, but the ease of managing multiple accounts always stood out as one of the biggest perks to me.

in the current political climate, it's not hard to see why reddit might be cautious about implementing such features. of course, the real reason might just be that most reddit users don't even have one account to manage.

They aren't going to care about what anybody on HN has to say about it because we aren't the audience they are after.

They need hundreds of millions of new users and those have to come from Facebook and probably on mobile.

> and probably on mobile.

The site isn't mobile-friendly though, is it?

It's slow, bloated, and has repeated interstitials demanding you get their app if you deign to use mobile.

There is an old mobile interface which is very quick and also easy to use.


I tried the new interface, and even after a couple of minutes I still couldn't find where my saved posts were. Went straight back to `old.`

The old mobile reddit site [0] is _amazing_! No whitespace, no padding!

[0] The one which you can still reach by adding '.compact' to any reddit url

> so much better

In particular, faster.

I need to have a supercomputer to scroll past the first few pages.

I use ud.reddit.com

Although anytime I mention this I fear they'll take it away...

Just out of curiosity, why "ud"? It seems like any two letter subdomain works in the same way.

I have no idea what ud is, I use old.reddit.com

Honestly, I think that was just one I bookmarked at some point and there it is in my history ;)

It's actually old.reddit.com but they probably have some sort of a wildcard rule.

This is probably it : any two letter combination seems to work.

It was (originally) for localization: ja.reddit.com would (for example) give you a Japanese interface. Eventually they realized what a horrible idea l10n is for a community-oriented site, and dropped the translations, but kept the `lang` that it would apply attributes. Eventually subreddit moderators figured out that you could use this to provide multiple variants of the per-subreddit CSS, such as dark modes, custom filters, and other silliness[0].

[0]: For example, see /r/CrappyDesign with (https://old.reddit.com/r/CrappyDesign/) and without (https://of.reddit.com/r/CrappyDesign) Comic Sans.

Testing it out I found something interesting. You can put in subreddit.reddit.com and it redirects to reddit.com/r/subreddit. But any 2 char prefix works sends to old.reddit.com (a.reddit.com -> reddit.com/r/a)

e.g. hackernews.reddit.com -> reddit.com/r/hackernews

Why does this subreddit exist?

> hackernews.reddit.com -> reddit.com/r/hackernews

> Why does this subreddit exist?

Considering the prevalence of the rebuke "HN is not reddit" on HN, probably for people who want to talk in a more reddit-like style.


Other than "np", as in "np.reddit.com", which is used for "no-participation mode", I think the other two-letter sub-domains are used for language codes. I think at one point in reddit's history doing things like de.reddit.com could give a german site, and so on. I'm not sure what "ud" would refer to, but I assume it's similar.

np is implemented as a language code. Subreddits have to change their stylesheets for that language for it to work.

Maybe "undefined"/"undetermined"?

Given how aggressively reddit push their terrible no good very bad interface, I figure there has to be some advantage to them to my using it? I don't know what that could be, maybe users struggling to use the new interface looks like engagement to ads?

The new UI isn't all that pretty either...

I have seen it in ill fated attempts to replace POS systems that were old green screen types to warehousing stocking tools using the same all with new pretty GUI or web page interfaces. Looking slick is great if customer facing but down in the trenches its all about familiarity, speed, and stability.

One pet peeve of mine is that these old systems are often trivially navigable with a (often custom) keyboard, then replaced with something that needs a mouse.

So 'tap, tap, tap, tap, enter' becomes 'tap, <locate mouse> click, tap, tap <locate mouse>, click'.

The new Reddit interface wasn't designed for users. It was designed for the customers (advertisers).

Also worth noting - consumer app or website designs that cram negative space everywhere are almost always slow as shit to use compared to their older "ugly" replacements. The way new Reddit renders content is an excellent case in point. An older example is the Guardian website - it's design about four or five years ago was despised by users (which was ignored) because it was slow and made using the site slower.

Reddit also fails to load aporoximately 20% of the time, too. I figured it was growing pains, but they've not changed a thing. They designed it, they're done, and they're really not interested in what the users think.


These days it's so hard to organise or browse your own music collection.

Oh man, glad I'm not the only one I noticed this. It used to take ~2 seconds to find my favorite playlist and play it. Now it takes upwards of 10-20 seconds.

On the dedicated "select a playlist" page with the squares, it even freaking re-organizes the squares every time you view it! Imagine if your desktop icons re-organized themselves in some arbitrary way every time you needed to open a program, and you get the utter destruction of muscle memory that can make up for the gaps in efficient design.

Netflix is the king of this awfulness for me. Every time I use it the homepage is different. Different lists show up, disappear, change position, etc; even my list of saved shows that I reference all of the time suffers from this. Sticking with literally any layout I've seen on there would be better than the randomness that I have to navigate through each time.

Just give me the damn list of everything in your database and let me search and sort using the metadata. Why do they need to throw algorithms at everything?

I keep hearing this but I find Google Play Music to be way, way worse.

So because Google Play Music is worse at X, that means Spotify's X can't be bad?

Or are you saying the bar is: "as long as there's something worse"

> So because Google Play Music is worse at X, that means Spotify's X can't be bad?

It could be that, in most cases, we only think of the options as ones that we've been introduced to.

We're way too busy with daily life to really think in-depth about everything in hypothetical possibilities, such as "here's a way in which a music app that doesn't exist could do it better." Instead, (unless we're very passionate about music), we tend to only think about the options that have been presented to us.

You're extrapolating here. Maybe I was not clear enough. I've never found Spotify's interface to be that bad, but have the same sentiment you hold for Spotify towards Google Play Music.

I haven't seen a web music player / library manager with good UX for a very long time.

Need a spotify for WinAmp plugin

I long for the days of foobar2000!

I think old Reddit, HN, and Craigslist are good examples of what I've seen referred to as Brutalist Web Design (https://brutalist-web.design/).

Also another great example about why user and accessibility testing are very very important. It was downright ignored and when pressed the Admins admitted it. Leave your beliefs at the door and fucking watch how the user interacts with your site, then ask them why they make those choices. Buy them a beer or whatever gets them to talk.

I use "old.reddit.com" exclusively too, information density is king.

Material design and minimalism probably have a lot of strong theory behind them, but the cargo culting around them often leads to worse UX. I think a lot of companies reach the "dedicated UX team/person" stage before the "careful A B testing of user flow" stage.

> I think this is a big factor in what killed slashdot

For me it was the pedantic, toxic community. HN is a breath of fresh air by comparison.

Obligatory anger for the Gmail and Calendar minimalist redesigns. This is not minimalism really. It's whitespace maximalism.

A great example of a really nice information dense app is the Bloomberg terminal. Maybe it’s ugly (a lot of people say this, but I personally don’t think so), but all the right design choices have been made. High Contrast, monospaced fonts, extensive keybindings, absolutely no wasted space. And, most essential, it’s not a web app.

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.

> You never felt like it was an extension of yourself.

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 Terminal is probably the best and greatest app that's ever existed. There's just this ineffable feeling you have when using it.. like all the knowledge in the entire world is available at your fingertips. Using it just feels good, you feel powerful, and in control.

For people that haven't used it, I know it sounds like porn. But it's incredible.

I love the Bloomberg Terminal style. I watched one of my users retrieve some product information yesterday, a few key presses and it was there. Much faster than a web application.

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.

Actually orange is the oldest. The story goes that when the Bloomberg terminal was created in the early 80s all the consoles where monochrome, and the only choices were green or orange (on black in both cases, of course). Everyone else used green so they went with orange to be distinctive.

> The story goes that when the Bloomberg terminal was created in the early 80s all the consoles where monochrome, and the only choices were green or orange (on black in both cases, of course).

It's probably not entirely true given there were dozens of known phosphors, and there were monochrome displays in other colors (e.g. the 1980 Apple Monitor III was available in green and white).

However assuming they went with pretty standard equipments green was by far the most common followed by amber. Amber is also somewhat softer on the eyes, which might have been an argument in favour given they'd have folks looking at these displays all day long, especially for charts which would fill the terminal with <color>: green monitors were OK when you had mostly black (text, curses interfaces) but it was way too harsh otherwise.

Our first computer actually had both green and amber displays, the amber display was dedicated for games and the like, anything which would light up a significant fraction of the display at once would go to the smaller amber monitor instead of the larger green one.

Green and orange? You just gave me a flashback to my 1980s school experience in Australia with MicroBee computers.


I was going to post about Bloomberg Terminals, but figured since I'm late to the story, someone else already did. Yeup.

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.

People who say Bloomberg is ugly have a very shallow view of what design means. It's the form over function way of seeing things. These are the people Apple markets its products to.

This seems to be the mainstream school of design, no doubt inspired by what Apple and Google are doing.

Myself, I absolutely hate it, because it puts sellability over productivity for end users. I.e. it literally wastes people's time.

I liked the bloomberg style so much I ripped the fonts out of some Bloomberg software and use them as my terminal font :).

It's an attractive font.

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

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.

I worked for a company that rhymes with “potus” did you work for the company that rhymed with “brighthouse”?

Man those guys had an ugly app.

Mine rhymed with "grim soup". To be honest, although there was a portfolio management tool of sorts, it only had one customer, and the company's real focus was on trade ideas. It sounds like the top brass had similar levels of ambition, though.

Actually I was talking to the Bloomberg people at a conference and parts of the terminal are web based now.

Also how are monospaced fonts "the right decision"?

For the same reason that monospaced fonts are the correct choice for code: so text can line up. If you you’ve used the terminal, it displays structured information really nicely because of this.

Also in regards to the monospaced fonts, you can easily calculate how much space a block of text will take on the screen.

They do have the Bloomberg anywhere portal which is web-based, but the main app isn’t web based.

> the main app isn’t web based.

Source? I heard this from the developers directly.

> For the same reason that monospaced fonts are the correct choice for code: so text can line up.

This isn't a requirement for code. Coding in variable width fonts actually works fine.

I don't think I've ever met a single programmer that has ever used variable width fonts for code. Maybe you're the exception?

But the vast, vast, majority of people think otherwise.

This is how I feel about computing in general. GUIs in general were a mistake. Vim is fucking awesome, and there's no replacing a shell and the myriad CLI utilities you have at your disposal. The computer is there to automate repetitive tasks, not create virtual busywork.

GUIs generally represent the sacrifice of power and automation for approachability by the lowest common denominator.

> The computer is there to automate repetitive tasks, not create virtual busywork.

The GUI eliminated the busy work of setting up your environment to make your workflows easy. It instead provides an environment where a wide variety of workflows are easy by default, although maybe not as easy as they could be with specific configuration like setting up customized keybindings, etc.

Easy but time consuming. I.e. not ergonomic. Also point&click UIs tend to sacrifice composability, whereas keyboard-driven interfaces tend to allow to chain operations and modifiers in a way that makes it ergonomically cover much larger space of possible workflows.

> Easy but time consuming

But learning is time consuming, too. Keyboard-driven interfaces can be more efficient but they are not discoverable. Maybe keyboard-driven interfaces make sense for the domain specific tasks that you do every day, but would you want a keyboard-driven interface for every random website you come across?

> would you want a keyboard-driven interface for every random website you come across?

Definitely, no. But you can have both at the same time; in fact, in 90s-era applications and in professional desktop software, this is the norm. You build your discoverable UI, but ensure every action is attached to a keyboard shortcut, and that keyboard shortcut is also discoverable. Call it "progressive enhancement" of UI ergonomics, if you like; the point is not to put the ceiling for regular users on the level of your average first-time user.

> But learning is time consuming, too.

Not as much as time wasted if you don't provide a "faster path" to learn. I'm trying hard to understand, why modern UX designers react to the possibility (not even requirement) of users learning like devil to holy water. That is, beyond the obvious reason - pretty but useless software sells better, as you rate looks on first impression, but ergonomics on repeated use (i.e. after sale).

Vim has a GUI (or a UI I guess), but it allows you to input commands. For some reason we think of GUI as mouse based interfaces in which you click around. There’s no reason why this has to be the case.

The most powerful form of computing is having the command line for input but also allowing a UI for the display of information.

Vim has a TUI, not a GUI. Unless you're referring to gvim.

I have also thought this through to the following logical conclusion: Imagine computer users being fluent in SQL and everyone sharing one giant database.

Let’s check Twitter...

select message, username from TWEETS order by date desc limit 10

Slightly more realistic is the “semantic web” concept.

The trend of GraphQL in JS-land is helping move a little bit towards this, since it's a strong reason to have row-level user authentication and access control so that queries can live in the frontend.

The problem at this point isn't with technology, it's with companies that try to silo in the data users give them.

I'll forever be scarred by a web app I made to make the workflow in a mainframe terminal obsolete. Was so proud of what I'd done and all the theoretical productivity I had enabled (hey, I calculated the numbers, and the manager signed off on it!).

But my only lasting memory of that app is that it probably didn't increase productivity as much as I thought it did when I looked at how they used it day to day, and only succeeded in giving them carpal tunnel syndrome due to all the extra mouse-clicking. The final conversation I had with those users is how their wrists were starting to hurt so much. But hey, I was moving on to another project. Hey, sorry to hear, here are some exercises for your wrists, see ya. Oh, by the way, did you ever try Powerball? Supposed to do wonders to make your wrists stronger.

I try not to be so narrow-minded about app design after that. Pretty does not necessarily equal functional, useful, or value-adding.

edit: In retrospect, those users grocked that terminal interface with all their key shortcuts the way a seasoned developer or sysadmin would grock emacs. Imagine forcing such a guy to use point and click instead for everything. You'd have a riot. I can't believe I didn't see it at the time. Young and naive, and now also regretful for all those people's wrists.

Bank tellers went through this in the 90s. You could tell when they swapped out their terminals for Windows. No more machine gun F key navigation, hello “hunt n grunt” cruising with the mouse.

This is what I’m increasingly going through with apple’s Touch Bar. Half the time I’m accidentally hitting it when I don’t mean to, and the other half of the time I have to look down, as a touch typist, to find the “button” I want.

One point:

>Are there things my users really don’t need to see right now? If you don’t know, 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.

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

> it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.

I think one of the most valuable thing software engineers can do for themselves in some circumstances is attempt to shift perspective towards assessing projects by how many people they help and how. The most rewarding projects I can think of are the ones where a day or two after rolling them out, I'm contacted by a few employees that they affected the most and told they love it and it saves them 30-90 minutes every day, consistently.

I think it's a feeling most developers can empathize with, since we often automate boring drudge work in our own jobs and lives. Making multiple people's lives and jobs a little less monotonous and dreary, or a little more effective at their job in a way they feel and appreciate is a good feeling.

My wife is a genetic counsellor, and as part of her work she regular has to use this one formula to calculate the probability of this one genetic condition I can't quite recall.

Because of the complexity and the importance of getting it right, it took her around 10-15 minutes every time she needed to use it. She, and her colleagues, are pretty much luddites so a basic calculator was their only tool.

I spent 10 minutes writing the formula in javascript, dropping it an html file, and running a few test.

She absolutely loved it, and shared it with the rest of the staff. Apparently some counsellors at another clinic heard about it and requested it as well. Someone thanked me at her Christmas staff party.

In terms of effort to build vs. hours saved and end user appreciation, I don't think I'll ever top it.

It probably boggles the mind of people like us, used to being power command-line users and automating our boring tasks with powerful tools, to hear stories like this.

With the prevalence of office jobs that use computers, being a developer is sort of like being an engineer in the 1960's or before but having the ability to whip up designs for simple mechanical devices that you can build for very low time and money cost, and replicate for free. It's like being the inventor of the slap-chop except that it costs so little to get items out there, that people often just do it for free. I would love it if I was doing some annoying repetitive task like mincing garlic or onions and someone said "hey, I can make that easier. Give me an hour..."

I like your description, it's one of things I love about software, how malleable it is for quickly building "devices", tools for my own use or a potentially large number of users.

About the last point you made, how it would be great if hardware/mechanical devices could be made more like software - a few years ago I heard about "micro factories" (forgot the exact term): 3D printers for small(er) scale manufacturing. It seemed promising that soon we could be writing software to manufacture devices/products at home, in a garage, local maker "lab". If you thought of an easier mechanism to mince garlic, you could whip up a prototype in a code editor and "print out" a working prototype (or production-level device)..

One of my best work hackathons was spent asking non-technical people what parts of their job sucked, and helping them automate those tasks. The last project involved updating a button that cloned data to go further, and clone some additional data. That work took me an hour, but saved a team at least 10 hours every month!

You did the work of a product manager, business analyst, and engineer all in one. This is what consulting is supposed to be but most companies are merely hiring contractors and are uninterested in any challenges to their requirements (that were never derived from the real world in any way, just an ivory tower of management / conceptual consultants). So you also had a good client as well that respected your proposal and were willing to re-assess their assumptions.

> you also had a good client

I had a fantastic client. I don’t know if it’s because the rigging industry is full of “holy sh, we gotta think on our feet” situations or what, but for a seemingly “low tech” client they grasped on to an iterative and flexible approach so much better than most clients I’ve ever had from the tech industry.

Yep, most clients aren't interested in _paying_ for it. "I wound up spending 6 weeks before even proposing anything that had to do with technology." And they start paying without knowing exactly how long/how much money it will take to get to the end, or even what the end is.

Penny wise pound foolish.

To be fair, they may not _trust_ that you'll actually do a _good job_. There are so many terrible consultants out there, and clients are not very good at evaluating who's going to be good.

RE: and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.

One has to be careful with this; often a process has "invisible benefits" such that outright removing it creates unintended consequences. For example, one industrial analyst found a way to speed up the assembly process. However, it was so efficient that the glue didn't have time to dry before the subsequent steps, damaging the product. Work-arounds were found, but it took time to iron out all the changes.

My first paid gig I did this with wild success also. After that I tried to do this several times and was always met with incredulity. Management never seemed to grok the importance of this, to the point where I started thinking maybe my first experience had been a fluke (gaslighting). While I no longer think this is practical (unless you are the one in charge), I do recommend it whenever possible. The product will be orders of magnitude better, but expect management to strain at the gnat of paying a software developer to watch a non-technical person do their job.

You could manage this by setting expectations early. When you start negotiating, a classic trick is to set a few different “packages” and then gently guiding the other side towards the option you really wanted from the start.

So let’s say you really want to do this bit, but you also know management is too cheap; you create a super-cheap option where you don’t do the activity, but something else also happens that management is unwilling to accept, something pretty horrible. Then you have two other packages that are actually desirable, both containing the activity; one of them should be the bells&whistles option that will look expensive. Management will discard the costly choice and the obviously-subpar one, and pick the middle tier. The skill is in not making it too obvious that is what you wanted all along - i.e. you should sound really disappointed that they didn’t pick the super-expensive version.

Great war story with enough specifics to be learnable, thanks for sharing! Reflects my experience as well.

Loved the story. I'm studying (mainly web) software development right now, but this type of work is what I enjoy most. Studying & understanding users' workflow and building a solution that does exactly what they need.

Do you have any tips/ideas on how can I pursue this as a career?

Contact is in the profile, reach out and I’ll make the time.

Thank you! Your profile only has your Twitter handle, and I tweeted @you last night - https://twitter.com/willediger/status/1095901887537315840

I also added my email to my HN profile.

This story makes me happy. It's what I aspire to

> Except users lie all the time.

That's the starting point for all the garbage enterprise apps I've ever used. Someone that has no clue what the users are doing makes a decision about how best to design an app that they don't even know how to test.

Don't ask them how to design the app. Ask them what they do with the app, then find the best way to get them where they need to go. Then let them test the first and second and third versions, and listen to their feedback without an assumption that "they just don't understand my genius".

It's important to distinguish between casual social media app users and power users spending hours of their day using an app to get their work done.

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

You're talking at cross-purposes.

To get a sense of how people are interacting with the software you have to watch them interact with the software. The moment you ask them a question about UX you'll begin to get low quality input that you can't trust:

* user is expressing an exaggerated desire for some esoteric feature that nobody else would use or discover

* user is repeating what they think should be decent design

* user is agreeing with a criticism they don't understand because they want to appear knowledgeable

All of those and many other problems go away when you just watch somebody use an interface.

Watching someone use an interface can be low-quality information, especially when that interface is already heavily optimized to guide the user down a prescribed path. If that's your sole input, then you're essentially doing a naïve gradient descent, and you're bound to be stuck in a local minimum.

Asking users, in addition to watching them struggle, can inform you on what they're actually trying to achieve, and what's their mental model.

I do try to avoid getting them to tell me _solutions_ though.

"What's the most annoying part of your job with this software" (with followup questions to understand why and what they were trying to do and _why_ they were trying to do it) is better than "What feature do you want that would most make this software less annoying"?

This I can agree with, but with a caveat: if you're dealing with professional domain and users who are domain experts, it might be worth it to pick their brains about features too. They might have used other software in the past, and know a design element or functionality that works better.

You all them what they do, and they say things like "I open my email, ...":

If you watch them you see that what they mean is (dramatised!) "I open my browser, which defaults at Google, then on the Google home page I type 'bing', click on the first search result, then go back because it wasn't Bing search but something else, then read the results and find bing search engine, follow that, login to Bing, then access the app button to choose "Outlook" online, ...".

You might not be able to train them not to search for a URL, but IME users will click an "outlook email" icon on desktop or favorites/links bar; of course you need to watch them to see if they do.

Aside: browsers could fix this but the browser makers are either the SE owners or in their pockets and don't choose to.

>>If you watch them you see that what they mean is (dramatised!)

Not necessarily dramatized... I've seen almost identical behavior in some places I've worked.

Basically: you can't take anything users say for granted. You need to actually see them work.

Yes, this is from experience of watching users. I've often had to bite my tongue. Sometimes one learns something clever.

I once saw a professor type "google" into the browser search box (which had google selected as the search engine), click on the first result, and then type in their Google query.

ofcourse you dont ask them how to design. you are hired as the designer. ask them for specifications / limitations / painpoints in the current system etc. etc. and base your design upon their feedback on actual relevant questions.

a plumber doesnt ask his customer how to plumb. just which pipes need fixin! doesn't go fix the toilet if the shower is broken :S

I think the better analogy would be installing a whole new bathroom (it’s a redesign after all).

In that case the plumber could and should ask where the sink is going, even if he was only told to move the toilet.

Why? Because maybe the sewage line is over there and about to be covered over with concrete and they’ll have to tear up all of that to move it in two weeks, but the sink hadn’t arrived yet so no one told him that would move either.

The point is not that the plumber is asking his customer how he should do his job, but that he can be more valuable if told the whole scope and impact of his job.

Similarly you can’t just ask a user “how could this screen work better”, you need to watch them work so that you see that that screen isn’t even the problem - they’re clicking off of it 15 times every call - but you didn’t even know to ask about the other page.

> you can’t just ask a user “how could this screen work better”

Why would you ask that anyway? You've already assumed the problem and solution at that point.

You ask how it's going, very generally and let the conversation lead you to their pain points.

You don't ask about the UI, which they are not an authority on. You ask about their subjective experience, which they are.

The best approach is to watch them do their work and ask a lot of questions. For example, "Why did you have to leave this screen to go find X?"

'Why?' is a very powerful question.

A few months ago I heard a talk by the chief product manager at a photo album printing company where he talked about an in-depth series of customer interviews they'd recently conducted.

His advice was to keep asking why until you get to the root of why someone did something. However, if the answer you reach 'Because I don't want to die alone', then you've gone too far...

This technique is called a 5-Why in lean manufacturing. Useful tool in digging into a root cause, and helps people think deeply about the causes of issues that are not inherently obvious.

Also, 5 is just the "suggested" number. More or less may be needed. If you reach 'Because I don't want to die alone' in 3 whys, probably no need to try for 5...

Or the answer is, "Because the last guy who didn't do X got fired."

Perhaps you could measure the user instead, as in time taken to complete tasks.

If you use a stopwatch or equivalent, the user may get weirded out. Maybe do a rough-count in your mind and take a note, but to emphasize time above other factors may be a mistake, except for special domains or circumstances.

I often find that it's not that they lie, it's that they're often trying to come up with solutions and present those, rather than explaining the root problem.

But yes, watching them work is invaluable. First time I visited one of our clients, I noticed two issues that I had no idea of:

1. All users had dual-monitors, and maximized our application across both. Our application is MDI still. This was a very bad fit for dialogs that were (for historical reasons) had the default position set to center-of-application, rather than center-of-screen. Try reading a dialog split right across two monitors. So when I got back I immediately did a pass to make them all center-of-screen.

2. When doing the main data entry, they didn't look a the window they were entering data into, but rather the source material. Thus any additional controls or dialog would mess up their workflow big-time. That's when it really hit me why the user interface for that window was rather clunky...

I probabbly didn't emphasize it enough but yeah you give them something mvp like and watch them and get feed back on it.

Recently, I actually forgot to make a whole series of changes on a dashboard that were requested. They hated the old version .... but I didn't change it before the next meeting ... and then they loved it at the recent meeting. It was the same one they hated on.

Sometimes you also just have to let them get used to it too ;)

It's an iterative process no doubt, but as a dev... I'm no better at knowing what I'll do too. Iv'e worked something up and weeks later changed it completely after I've used it.

Consider their response an input signal and not necessarily instruction from them. If my little niece comes crying saying there is a monster under her bed, of course I know it's not a monster but I'll still go look. Maybe a toy is under there making a noise, or the heater pipes, or the cat is moving stuff around.

This is how you get your kid eaten by monsters.

But in all seriousness, this is a good point. In addition, you have to think about the user you are listening to. Are they smart? What terminology do they know that other users don't? Maybe they figured out a workaround to some problematic UI already, and you can just make that workaround global.

I've heard a corresponding principle in both game design and writing expressed as "When people tell you what needs fixing, they're almost always right. When they tell you how to fix it, they're almost always wrong." Feedback is great, but feature requests and proposed changes aren't actually feedback, they're new ideas.

>> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.

That's a bit harsh. IMHO people don't know what's even possible, so they can't tell you what the solution is. Sometimes they can tell you what bothers them about what they've got even if they don't know what would be better. The rest of your comment it good though. Watch them. Look for things that look hard or redundant. Ask if they ever get tired of X, what gets in the way, etc... But don't necessarily expect them to tell you how to make it better.

I like to say users don't have requirements. They have problems.

They often gloss over how they might use an app, or use it differently to described when doing real, live work with real data instead of test scenarios. Just as I would likely gloss over much of what I do when I drive a car, as I no longer think about it. Sometimes they use something differently to how their supervisors think they do. Maybe they found a handy shortcut or unintended timesaver, maybe relying on a side effect or unused field.

Best to watch a few at all levels of seniority, if at all possible, to fully understand how to deliver what they might need. Then dig into the issues, shortcuts and timesavers or bottlenecks they currently have.

This is why user/usability/UX research is actually a _thing_. Like a discipline, a thing to learn, a thing where experience and skill matter.

Yes, you can't just "ask". But there are certainly ways to learn. Doing a major UX redesign without doing any UX research seems like asking for trouble -- and I don't trust the conclusions drawn from the outcome, still without being based on UX research, either.

I think that this attitude a great example of the arrogance that permeates a lot of the redesigns that get dropped on people today. Yes one needs to sometimes throw out suggestions (because they aren't aware of techniques) but when users complain or praise something that needs to be listened to because they are literally telling you their workflow and describing potential optimizations. Nothing is more obnoxious than designers telling me I won't want something! It's like, 'fuck you, you don't know me, stop discounting what sounds like a good idea!'

Ask things to your users, and then listen to them! Watch them when they show you things, watch them when they work, watch their emotions to see what they like and don't.

> Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.

Asking them to describe the problems they have and doing exactly what they say will fix those problems are two very different things. The difficult, but critical, step here is to decipher what root problem should be fixed given the feedback users have given you. Sometimes the right thing to change is something the user never would have thought of to ask for, but can be figured out from what they did ask for.

Remember, your users (usually) aren't UX designers, they just know where they get frustrated.

> They don't know what they need or want

Of course they don't always know. That's why you have to do proper user research. You should not just build what they are asking: you should try to figure out why they are asking for a particular solution, try to find patterns among all the users, find the actual source of the problem and then propose a solution that could work for them. This is, of course, an over-simplification. Like I said in another reply, work with a PM that's really good at user research (like scientifically-good).

I've found its not that they lie (all the time) it's that often they don't have the time or mental energy to figure out what they want and even if they do they lack the tools to communicate it.

That is fundamentally a human problem and I'm not sure what technology can really do to significantly improve the solution which is to slog through it and listen to feedback.

I think many people don't really understand how they perform the functions of their job. Some things they enjoy doing, some things feel like busy work: all the things are mixed together over the course of the day. Picking and teasing the separate pieces apart and dealing with them individually is always hard for people and for some more than others.

> They don't know what they need or want.

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?

Because you know something about UX.

Good design is a cross-disciplinary activity, mixing the domain knowledge in users' heads with the design knowledge in the heads of developers/designers. This is hard to do well, with few hard-and-fast rules, but it often benefits from collaboration.

There are often big a-ha! wins when you're watching a user and ask a question like "why did you do that that way?" or "what if I redesigned it like this?" Users often can't ask those questions because they're focused on doing their job rather than the meta-job of improving it. They often don't realize what's possible.

That's no excuse for ignoring their suggestions, and unfortunately many users have been specifically discouraged from thinking how to improve their own experiences by developers who were lazy, incompetent, or merely bureaucracy-laden. But fostering a collaborative environment, where developers learn something about the domain and users learn something about how their tools are created, can lead to much better user experiences than either could do alone.

More to jfengel's point, it's not just UX, you have more knowledge of what is technically possible. People will often come up with very convoluted solutions to problems because they don't have a good view of what is technically possible.

It also happens that people only take their own needs into account and not those of the other users they're indirectly interacting with via the app. They'll tell you that certain app objects should have certain constraints, that certain things should be impossible, and that such assumptions can be used as foundations for other features. Then you go visit another user and they'll tell you very plausible conditions under which those things should be possible and even required. Talking to users is good, but you also need to observe them as a group and sometimes weigh their needs against each other.

You can probably find a better term for this phenomenon than "lie", which implies a degree of active intent to deceive.

Users have ideas. These ideas are motivated by pains and pleasures.

When asked what they want, they present the ideas they believe will reduce pains or increase the pleasure of using the software.

It's up to you to 1. Determine if the idea reduces pain, increases pleasure or both. 2. Test whether the hypotheses are correct.

Rephrased: Users come up with untested ideas

Some of this comes down to phrasing. We should both ask and observe (but it has to be the right kind of asking).

The asking should be user interviews and contextual inquiry to understand their problems. What are they trying to solve? We shouldn't be asking them to design our products for us, because users often don't know what they want or what they even do. This should typically come very early in the process as foundational work.

Observing people both working and in a usability testing setting will help us learn what is and isn't working. As we get into the prototyping stage, it should be a lot more observing and testing.

I think what you are responding to is this idea that all we need to do is just talk to our users, and you are correct, that is very wrong. Just asking users what they want is a good way to give them something they won't use.

When we do ask people questions, they need to be done in a methodical and probing way.

    > Except users lie all the time...
OK, observation is certainly important, but if they tell you something LISTEN.

Users who have "skin the game", who actually have to use the application usually have valuable observations and suggestions. Does it mean that you should uncritically implement what they ask for verbatim? No, but sometimes the insight is right in front of you if you're receptive to it.

Why not both? It's not even that people lie, but they might not know what's possible, limiting the amount of information they will give you.

Yes, users do lie all the time.

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.

A friend's company actually films users using software/websites, analyse their reactions and build a thorough report on UX. All their science is based on the concepts from IA -- information architecture -- from a decade or so ago.

And only change what are real problems. Maybe something like a user needs to navigate to three different pages to get the information they need. That's something you can improve.

But resist the urge to do a general facelift or reorganization just for cosmetics. Users can fly through the ugliest interfaces, even text-mode terminal interfaces, once they get used to them. Change that at all, and they will be stumbling around and complaining. That can be worth in the end if their usual workflows are now shorter and faster, but tread carefully. Users of enterprise apps really don't care too much about how they look.

Another thing is that suggestions from users often suffer from the "XY problem" issue. So even when a user has a ridiculous suggestion or request, there might be a legitimate issue behind it.

Its not always an option, but another alternative to asking and observing is becoming. If you yourself (or someone on your team) have previously been or are currently a user then you can usually answer a lot of the questions yourself with much less of a bias and maybe find solutions you wouldn't be able to by just asking and observing.

While this can give you insight, I think there's a huge danger of thinking you are a _typical_ user when you are not at all representative. I have seen this happen with disastrous consequences. I think "becoming" can supplement, but never ever substitute for observation.

While they might not know what they need, they definitely know what won't help them.

It's true, but you still need to ask, and watch them work. But what it often comes down to is that the company underestimates the effort involved, they push you to rush the process, and communication is the first thing to suffer.

Exactly. Asking users is only interesting if you know what you are looking for and you have to ask around the questions instead of leading them to answer. 90% of the time observing is what you want.

You don't ask them how do they want it redesigned. You ask them what they like, what they don't like. And preferably, you get a chance to see them use it.

Couldn’t agree more! Often the users look at you as “the expert” as if you could tell them how to do their job and show up basically with a ready app.

Don't just watch. Measure. Observers have biases. Figure out what you want to improve, figure out how to tell if you have, test changes against that.

>Watch them work

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.

I think you need both.

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.

A/B testing can help. Show them 2 or 3 different ways and watch them as they work with each.

You have to do both. Watch and ask.

Look, we're playing an intricate meta game where the application must please the following people in this order:

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

We have this issue now. Inevitably when the actual users of the app report issues with this or that, the answer from the dev team is almost always, "Works as designed".


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.

>the answer from the dev team is almost always, "Works as designed".

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.

And in addition, that they are aware it is batshit crazy too.

Yup, and this is the primary reason for why I avoid commercial products (or, even worse, services) like the plague.

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.

Asking is good but you often get a lot of wrong information that way. As well as very selective information.

When I was working on a reimplementation of an existing web app I had several team members watch how users were using the application. A mixture of sitting next to them and quietly watching (not interrupting their workflow) and remote watching via shared desktop (which we also recorded to refer to later).

Watching (in person and remotely) was without question more valuable. We could go back and replay what they were doing and why (we had copies of the worksheet they were working from for each use). Without it we wouldn't have delivered about 30% of what they were looking for and would have had to redo a load of work compared to if we had just gone by how they said they were using the system.

The new system rolled out and we had a total of two post-launch changes to make. Both of which were very simple changes. So don't just ask but watch how the users who use the system actually use it.

The challenge with Enterprise software is that the people who pay for it are usually not the people who use it everyday or a lot. So the vendor takes feedback from the end-users but they still have to demo to the guys holding the purse strings and when those guys give feedback (usually different from that of the every day user), vendor has to go with feedback from the purse string holder. If the vendor doesn't do this, the project doesn't get approved.

I think the proper thing here is for the purse string holders to defer to the views/feedback of the every day users.

lack of communication is main issue in all issues. people thing 'user' opinion is worthless or they lie or cheat you, but fun fact is that if they don't like your fancypants app, it will get shot down and cost you either time , money or clients or a combination of the three. if you ask ask ask, and then subsequently put it all in writing, verify with everyone they agree on the plan, they can never hold it against you even if they lied and cheated.

Not just ask, work with them. Try doing their job for the day.

The article has an example of customer records where the name fields are merged, same with the address fields. I know that would be hell for my friends in customer service wanting to find a customer by postcode or just their first or last name. Sometimes people are insistent they have complained before and you have ignored them, or you get scam artists. In these scenarios the team have to do detective work and they rely on having a decent sortable grid of customer records so they can find what they want if given incomplete information. Incomplete information comes from telephone messages made by cover staff, poor quality handwriting and a multitude of other sources. Since the staff stare at the same screen all day they know their way around it and simplifying the layout helps nobody.

Or even better - RUN 5-minute user testing sessions!!

Even in terms of the "recommendations" in the article, I can see all sorts of red flags. Group addresses? What if I needed to see what state it is at a glance? Now the state alignment is off. Or if I needed to sort by state?

All of this could have been avoided by sitting down with users of the existing system, watch how they interact, and then put together a revised version, and watch how they interact/where they have trouble/etc before doing a wide release.

The fact that user testing wasn't done, especially on an internal application where the users are right there available for it, is the real story here.

Agree - I could take most of this comment back to the late 90s and most of it would still apply. One thing you could do back then was with visual GUI editors, you could place buttons and widgets where you wanted them and change it quickly.

Indeed. I sure the hell miss WYSIWYG ui design. The auto-flow "constraint management" of web UI's and CSS turned bicycle science into rocket science. (There was a HN story about this a few weeks ago.) I had Jetsons technology, it felt great, but then it was ripped from my warm productive fingers. Will they do the same with my flying car?

> So this designer set out to solve the problem, taking cues from modern consumer apps.

The problem is, the arrogance of the designer. Who would ever redo something without talking to the user?

What made you switch to development?

The industry I worked in was networking (data center products, routers for ISPs, etc), but technical support. I did that for 20 years.

Even though it was pretty high end stuff.... everyone hates technical support and I found that generally companies eventually devalue it as time goes on. I got tired of that system.

I got paid really well but just got tired of seeing the atmosphere at company after company get more negative. Poor management trotted in, just coasting, incapable of making changes and such. Despite bringing in massive $$$ in support contracts... that money was never directed to support and things just degrade over time.

Then companies would outsource to some garbage company and the support there would be terrible so I and others would take the brunt of angry customers. Then someone would roll out metrics that show those folks overseas who just close cases are doing great because ... they just close cases without solving the issue.

The bad stuff just snowballs and there is no going back no matter how valuable you are in support.

When I was in support I worked closely with the engineering teams who wrote the code and who really liked how I worked (they'd ask that difficult cases be transferred to me because they know I'd document things, actually troubleshot, be honest if I don't know). They actually picked me at one point to be able to fast track issues that I saw straight to engineering and they'd pick up the phone immediately, because if I told them "you're gonna see this soon (either from a VP or something) because it is bad, you want to get a head start on it" they knew it was real. So I was already curious about coding in some form.

I wanted to do something new, got laid off after an acquisition, got a severance, and went the bootcamp route. I like making things now and web development is fun for me, I find that "troubleshooting" and "debugging" and such are all the same thing and that has served me well as well as the ability to work independently and learn independently.

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

We've all got bad metrics stories, but wanted to share this one.

Friend at megacorp was doing JS work, and working with the offshore team in India (few people in the US, and 3-4x as many in India IIRC). India team was "killing it" because of all the issues closed, and the US team was getting crap because they "took forever".

One of the mandates was "when you commit code, you need to have a test for it". Friend checked out the offshored code, ran the tests, and ... they failed. Almost all - a few worked by accident, but they were failing tests. Actually, when he first ran the test suite, his whole system locked up and crashed - the test suite runner couldn't deal with that many failures (that was my impression based on the symptoms and repeatability).

The 'defense', such as it was, was that no one had instructed anyone that the tests should actually be run or pass, just that test files needed to be committed with regular code. So they'd write empty tests, or copy/paste code from other tests. The line count and 'closed issues' were both great - so much better than the US counterparts. It's just that... literally... nothing was actually being tested. Budgets were cut and he and a bunch of other folks didn't have their contract renewed - they put more money in to the offshore team. :/

Ooof that's brutal. That's like just abandoning a fundamental aspect of the job for an excuse.

I feel like my current company was going this direction for a bit, but they’ve reversed course and are now bringing all development on-site, if not in-house.

Which is really the only way to develop if you want anything to get done.

Biggest issue I had with technical support was that it dials the cynicism up to 11; if someone calls tech support, either the product or the customer did something stupid. Therefore, no matter how good the products or smart the customers, it starts to feel like all the products suck and all the customers are idiots.

Yeah there's a lot of negativity you have to combat.

Everything is a "problem", and the executives at the company, often feel that way about support itself.

Sounds sadly typical. I wonder how many fields there are where "everyone who's actually good at field X eventually goes into related field Y instead because it's higher paying, more respected, better atmosphere, etc".

Yeah no doubt that's a thing.

Everyone values support when they talk about it... don't want to actually pay for it.

Products are optimized for those who sign the bills, not necessarily users. Flashy colorful design, useless charts, all that stuff.

>a well-intentioned UX Designer at a large high-tech company who was given a new project: Redesign an internal control panel that was ugly [...] It lasted one month before the company was forced to retire it. Users absolutely hated the new system. Sure, the old system was ugly, but it had everything they needed, right at their fingertips! Their jobs were incredibly fast paced—they worked in a tech support call center and were rated on productivity metrics. They didn’t have time to click or scroll to find information while the clock was literally ticking.

This same exact story of a UI disaster happened at a Fortune 100 company I was at in 2005. They had a legacy app (think DOS character mode talking to a mainframe) for entering accounting documents.

To replace it, a high-priced consulting firm installed a "web portal" technology. (Unifying a company's various enterprise applications behind a single web portal was a hot endeavor back then.)

When it was rolled out, the accounting department fell behind on their work. Nobody noticed that the constant UI banner at the top of the of the web portal browser window was forcing users to always use the mouse to scroll up and down to look at information. In the old DOS system, they could just enter info from invoices quickly without even looking at the screen. But the new system broke the users' fluid familiarity.

The UI disaster was so bad that the consulting company had to have their consultants come in on Saturday to help the client's workers catch up on all their data entry. Imagine an army of $150k consultants doing the work of $10/hour clerks because the web portal's UI was never really field-tested with a real-world workload! If just one UI web developer actually shadowed one of their users for a day, they would have noticed the usability problem.

I can't believe how many times I've heard your story but in different companies.

I feel like there is an opportunity to make a graphical user interface framework that mimics old terminals. Full screen apps that leverage use of the keyboard shortcuts or hell even a custom keyboard specifically made for industrial use. Basically a IBM 400 system but running on modern software stack. Airlines have stuck with their UI and for good reasons.

Being easy to use and easy to learn are not necessarily the same thing. GUI's are generally easier to learn, but not necessarily the most productive once a typical user reaches the plateau of the learning curve. A UI designed to minimize hand and eye movements may have a longer learning curve than a GUI. The ideal solution may thus depend on staff turnover rate.

I think you'd be surprised how quickly people can pick up on an interface that is as simple as the kinds of TUIs we're talking about. These kinds of things were very common for all sorts of tasks throughout the late 80s and early 90s and I don't think I've ever heard of the learning curve being a problem.

Shift+F5 F10 F10 code Return.

How to look up unsold inventory on the system at the first job I worked in 1999.

There people there who could navigate 5 screens without looking until the system returned the result they wanted.

People are smarter than many give them credit, the computing revolution in business really started taking off in an era when computers booted to something like.

I’m not suggesting we throw out guis but we could do much better in some areas.

Those old green screen apps (CICs etc) supported enormous key stroke rates all right, with nary a mouse in sight.

But productivity was not as high as a rosy colored view of the past might suggest.

Operators had to be highly skilled. Entering a record for the East coast sales team would require remembering the code ESALES03. There were no helpful UI affordances of the modern age, e.g. fuzzy or free form searching.

So combine the two, there isn’t intrinsically a reason you couldn’t do either with a TUI.

I work on enterprise systems and try hard to keep things consistent, it’s amazing how much enterprise web stuff I’ve run into that doesn’t even handle tab order correctly on a form that is pure data entry.

It’s hard to go all in on keyboard because browsers are somewhat inconsistent on which key combos do what though.

Not sure the lesson here in going back to CLI. What designers need to do is to conduct research - interviews, observational studies, etc - to understand how and why people use their software and then create design alternatives.

Ignoring a learning curve for the sake of argument, the most effective UI's tend to be command-oriented. If you memorize the abbreviated commands, you don't have to traverse menu trees. Command-line interfaces can still have menus for newbies.

For example, pressing Enter or giving the command "m" or the fuller "menu" at the command prompt may give a menu similar to:

   1 - Search for employees (SE)
   2 - New hire (NH)
   3 - Department transfer (DT)
   4 - Etc.
   0 - Back to prior menu [app-wide convention]
   Command: __
Here newbies just enter menu numbers; but next to each menu is a shortcut command, such as "DT". After they get experienced, they start using the shortcut commands to jump across the menu tree as needed, they are usually global. It's like a Go-to (gasp!). The prior stuff is still on the screen for reference because they wouldn't get a menu when using the shortcut commands; it only shows up if you ask for one.

And the shortcuts may take optional parameters, such as "SE gar" to search for all employees with a last name starting with "Gar". (Without the parameter, they get a typical search form.)

Before GUI's, I worked with users directly to gradually fine-tune such gizmos, and after a while their productivity screamed. They loved me and even forgave my lack-luster people skills.

Many emacs modes use something akin to this (see magit as a stellar example). This makes learning it relatively easy (it's discoverable), but becoming a power user is still possible.

Yup. Magit is a stellar example of UI that's both discoverable and ergonomic. It shows you a popup with a list of options available to you at a given stage, with plainly visible keyboard shortcut. But it doesn't block or slow you down with this.

Say you're trying to show git log. The first time around, you'll press "?" to show the top-level popup, notice "l" is for logging, press "l", see the popup for logging commands, notice you need to press "l" again, press it. The next time around, you'll just press "l l" without thinking, and Magit will react as fast as you can type.

There are custom keyboards, they're just hard to find. The Devlin KMX-144 or the Logic Controls LK1800 come to mind. I'm sure there are others. You can use (n?)curses to make a terminal user interface.

I still prefer the web - just with the keyboard as a first class citizen.

I don’t think webapps can ever make the keyboard a first class citizen. The browser already has a bunch of keybindings.

Personally, I’ve never used a web app that I actually liked or trusted. Maybe it’s just me, but I’m always worried the page will time out or refresh or something.

Like imagine emacs or vim in a browser window, it would be horrible!

I wasn't going to mention qutebrowser[0] since I didn't think it was relevant, but it works well. Most of the keys in the browser can actually be rebound. With keyboards like I mentioned, the additional keys can be mapped to special key combos like `Alt+Shift+D` to avoid collisions.

It's also possible to map most or all of Chrome's (not sure about other browsers - but we're talking within the enterprise) keys can be rebound. Check out keycode.info - every key even ones like `Alt+D` and F1 and even `Ctrl+R` can be rebound and prevented from doing their normal function in place of something else!


Try vimium, I've been using it for years - as long as the HTML is semantically correct a surprisingly amount of the web is navigable.

No. Just mimic the speed, information density, and task-centricity.

Even a web app could do that in a pretty straightforward way with proper handling of keyboard events and tab order and a compact layout. "Press 1/2/3/4 to select a tab" is entirely doable in a web view.

Re: Everyone agreed it needed modernization—it looked like it was from the early 2000s, after all!

My goodness, Flintones even. The fashion chase is becoming obsessive and wasteful. As I've ranted about many times on HN, UI faddism is a huge time and resource drain and the industry should just say no or see a therapist.

It sounds strange, but desktop UI's around 2000 pretty much reached the pinnacle of business UI's. The web slid us downhill with its stateless ways, unpredictable layout results, and now wasting screen space while copying touch-screen-oriented design for mouse users who don't need swollen boundaries. Use 5-pixel lines to visually segregate panels, saving you about 20 pixels of width versus white space. ("Web" pixels, not nec. actual pixels.)

(The only exception is perhaps drill-down link-heavy lists/reports/charts. The web served these well.)

I’m convinced this happens everywhere, at almost every software company. As a developer, the most demotivating part of my job was the endless redesigns-for-the-sake-of-redesigns that kept happening. It’s ultimately what drove me away from being an individual contributor software engineer.

And it’s always for goofy vague reasons: “It looks dated!” “It needs more pop!” “It’s not fresh enough!” (What are we making? Software or food?) Nobody is willing or able to prove with numbers or measurement that the old UI is bad and the new UI is better. It’s usually just the designer’s hunch! Yet if I want to change the search algorithm we are using I have to prove the new one is faster with research...

Nobody ever talks about the psychological toll this takes on developers, and also on the overall software quality. If you are just re-building the same UI over and over again because "everyone is now doing it in Django / Angular / Vue / React / {insert future hyped framework}", no developer will go the extra mile to produce a stable, high-quality code base anymore. Why should they, if they instinctively know that they are just coding for the garbage bin? What you get is a team of depressed, cynical developers and low-quality software that barely works, which will then be re-implemented 12-24 months lather in some other framework, possibly by another team of developers because the old team has left in frustration or been fired for lack of motivation. It is a vicious circle that consumes the most productive age of an entire software engineer generation, and (although I am sure some of you will heavily criticize this) I am deeply convinced that the only way out of this is to just stick to basic tools and programming languages that have been around forever. Avoid any framework that is advocated like a religious cult.

Eventually, one of those current frameworks will "have been around forever". My bet is on React or one of its descendants, because viewed as a generic API it's a pretty good philosophical refinement of preexisting non-web-specific UI frameworks.

For example, there's now a framework that implements the React API for general-purpose terminal rendering, without actually involving any web stuff at all: https://github.com/vadimdemedes/ink

> My bet is on React

Exactly, it is a bet. A bet in which you can win nothing more than a refined résumé, or lose a lot of time.

In the context of web development, in the past 10 years I have seen other developers and myself write wrappers for the same JavaScript libraries again and again and again in so many frameworks and for so many CMS I lost track and count (incomplete list: typo3, Drupal, Wordpress, GWT, jQuery, AngularJS, React). This usually included weeks of work, after which it was possible to write web applications which could've been written with vanilla JavaScript on a static, handwritten HTML page in a single afternoon. From a macroeconomic point of view, it was all just an incredible waste of time. But the customers of the various companies I worked at as a student and after finishing university loved hearing the name of the frameworks. I am pretty convinced that it actually would've been enough to just write bare JS code and a HTML page by hand and sell it to them as "written in bootstrapped AngularJS". This would've saved hundreds of man hours.

> This usually included weeks of work, after which it was possible to write web applications which could've been written with vanilla JavaScript on a static, handwritten HTML page in a single afternoon.

You can have a website up and running (not just locally, but live on the Internet) within literally 5 minutes using React and Heroku, netlify, now.sh or whatever. If it takes weeks to do that, you're doing something fundamentally wrong.

It did not weeks to write the website, sorry if that was not clear from my original post. It took weeks to port existing JavaScript libraries into the ecosphere of the respective framework, to a point where it was indeed possible to write the website we wanted in 5 minutes.

> You can have a website up and running (not just locally, but live on the Internet) within literally 5 minutes using React and Heroku, netlify, now.sh or whatever.

Of course, I am not disputing this! But it is equally possible to have a website up in literally 5 minutes using vanilla JS + HTML + CSS and an nginx Server, without taking the dangerous bet that the framework you have chosen won't be obsolete in 2 years.

> without taking the dangerous bet that the framework you have chosen won't be obsolete in 2 years

That's why I specifically mentioned React and its API, as it's generic enough to have drop-in replacements or even frameworks that apply its basics to completely different kinds of rendering (https://github.com/vadimdemedes/ink). I find it unlikely that the basic idea of component trees, efficient one-way rendering of updated data, and JSX rendering will go away anytime soon, and none of that depends on the specific project named "React".

> A bet in which you can win nothing more than a refined résumé, or lose a lot of time.

I strongly disagree. Perhaps if you dont really have a problem that needs React to solve it. I understand you already had extensive expertise solving this problem in JS without React et all.

Everyone is afraid of being "left behind" and not being able to get a job. Keeping one's resume marketable trumps being productive.

I'm starting to look forward to the days when I can just work on old projects in semi-retirement, where all of this stuff doesn't matter, and the languages and frameworks are the ones that I grew up with.

This isn't to say there's no new good stuff. The problem is that there's also all the new fads, and it's a very rare job when you can get the good without the fads.

Not only does it happen almost everywhere but is has been going on since the beginning. There were people in the 90’s who did nothing but study UI’s, what happened to them??

The web happened. And now people use the web GUI to make destkop and mobile applications.

They are called UX researchers and they exist alive and well today. There is a huge difference between design backed by research and just doing things to keep up with times.

Wow, I kinda wish I worked somewhere with so few real problems they had to invent new ones just to keep busy.

Also remember: you MUST kill any Java-based enterprise app (Java is old and not modern) and replace the backend with Node.js. Then you can reuse all your server code in the frontend!

And remember to use Angular or React... actually, now you must use Vue. And create polyfills for your webpacks (and vice versa).

I wish more web apps would give a bit more choice on information density and layout - remember desktop software 15 years ago? You change all the colours, fonts, layouts (sometimes) so it suited you.

White space is great for new users to help not overload them, but after a few weeks of use, most should be able to go to their options and change the layout to save all this pointless mouse wheel scrolling.

I am impressed at the responses in this thread - I honestly thought I was in the minority about this, but hopefully the fashion moves a little more towards functionality

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact