The problem with this article is that there are lots of different kinds of enterprise software.

If you are building a piece of software that is The Software that your user will be using most of the day, I think this is good advice. But there is tons of enterprise software that this doesn't apply to:

* When the primary users of enterprise software are in high turn over jobs, they are unlikely to develop expertise in your tool.

* When users need to use once a month or once every six months, they won't be able to develop expertise in your software. Think about HR systems for updating contact information (which only happens at major life events) or updating benefits (which happens during open enrollment once a year, or during major events). Or maybe a portal you log in once per month to pay a bill.

* When your software is used often, but it is one of many tools that your users context switch between, they are unlikely to develop expertise in your software. The switching between different pieces of software means that there isn't enough time for things like muscle memory for keyboard shortcuts to develop.

Enterprise UX design, like all UX design, should start with understanding the customers and their needs.

> When the primary users of enterprise software are in high turn over jobs, they are unlikely to develop expertise in your tool.

Just to add onto this, this can often mean that the users are learning from other users who themselves learned from other users. Workflows with the tool can get very cargo-culty.

The student information system at my university where you managed all your courses etc had this clearly very often-used link front and center on the first page: "my name has changed".

Been there. I used to design (overly) complex applications for enterprise researchers. I partially agree with the article, but here are some thoughts:

There is a big difference between having a captive audience or not. By that I mean, complex applications reward commitment, and if your users have another alternative they can to switch back to, which they already know how to use to get their work done, good luck getting them to switch.

This is not advice to burn bridges behind you, this is to warn you from learning the wrong lessons. People hate a lot of the software they use every day. They only use it because weren't given a choice, not because they got over the hump and started to love it.

If you've got a complex application, orientation is important, so make don't make it an afterthought. Also, give people ways to learn without breaking things, and make sure they can undo their mistakes. Also, justify the value of investing their time: make sure your application is better than a bash script, and that users know why.

I learned this as a consultant in the room with people looking at three vendors for a solution for a specialized tool management software.

I gravitated to the tool that looked like it was the easiest to use, but the users gravitated to the ugliest one because they could just use the keyboard and get their job done. It had more on the page and it was designed for experts.

Ease of use is different than ease of learning, but the key is to understand the use case for your user. What does your user need, and what do they think they need? Attractive interfaces are only one part of it.

>Make me think. Little learning curve is OK..

The same argument I used to hear when User Interface was transitioning from command line to GUI for many enterprise applications. The inherent flaw in the article is that the author assumes that enterprise users are "power users". Most often they are not, their job is to sell a product or monitor a process or ensure that bugs are getting fixed on time so that a product can be shipped.

They use software to achieve a particular objective, software is a tool not the goal. Tool should be as easy as possible and as idiot proof as possible.

And also, it is not that enterprise employees are lifer. There are attrition, people leave jobs, new ones come in, process changes, new methods are introduced etc.

> However, while Wizards and guided tours are an excellent solution for casual users, it’s not necessarily the case for power users

There is literally a multi $billion company who makes guided tours for enterprise software.

WalkMe is seeing increased growth as of late.. it is now valued at or more than about $2 billion. And, the startup said it surpassed $100 million in annual recurring revenue (ARR) in the second quarter. Meanwhile, in the third quarter, its new business bookings grew 100 percent year-over-year. https://news.crunchbase.com/news/walkme-raises-90m-for-dap-e...

Using social pressure can solve this problem more effectively than being a clever designer. Take your lead or primary developer and move them to sit next to the people using the software. If they have any kind of human empathy, many of these problems will solve themselves.

Agree with many points in this article. However, there are some enterprise software tools (Salesforce for example) that have terrible UIs for both casual and power users, and offer no performance upside despite longer term usage.

JIRA used to be this bad too, but over the years I've found their UI to improve bit by bit as they adopted more consumer UX standards around their interfaces + adding workflow rules. These improvements have seemed to work well for casual and power users alike.

I think HN crashed Adam's site. Here's a backup link: https://web.archive.org/web/20201124131007/https://adamfard....

The trading example is perfect.

Something like a Bloomberg Terminal is overwhelming to a novice, but having everything in one place is fantastic.

On the other hand, a simple information view like Apple’s “Stocks” on an iPhone is also useful.

Depends on the situation.