Three easy-to-make mistakes for enterprise UX design
It’s been about four years since I started as a UX designer. I made many design mistakes along the journey and some of them even repeatedly. When focusing on a specific domain area or when end-users wear a professional hat, we tend to view users more like a group, a role, and less as individuals. This changes our understanding of the users. It is way more tentative to assume that they know certain things, they understand certain things, and they can deal with certain things. However, that is far from true. After I joined RingCentral, I was lucky to work with some very experienced colleagues who possess great empathy for users and a deep understanding of our product and industry. Working with these folks has helped me recognize these easy-to-make mistakes and has allowed me to continuously reflect on them. Here, I’ll list my top three and share it with you all.
Count clicks
I have always believed that efficiency is one of the most critical things for enterprise app end users. They have some tasks they need to finish; they want to do it quickly and then go home enjoying their time with their families. From my past working experience, we worked on transforming an old web app to a responsive app design. The table actions were designed to put two primary actions present at all times while all else was hidden in the overflow menu. The older version shows all of them upfront, listed side by side in one row, as many as possible. In the new design, we prioritized the actions so necessary and frequent actions were all readily within reach, the rest hidden in an overflow menu. However, in the new design, users complained that many actions were now one click away, and they couldn’t find the actions they needed. If users need to repeatedly come back to this page and do the same tasks, they know what they need and where to find it. So putting all this information upfront largely improved their efficiency even though designers think it looks messy and crowded. With this lesson learned, we continued to emphasize the importance of efficiency, even though we had to sacrifice visual simplicity in favor of fewer clicks. But as it turns out, this lesson doesn’t apply in all cases.
Later on, I started at a new company with different users and workflows. I attempted to apply this same rule of reducing clicks. However, it did not apply to may of the new situations. A guided flow or wizard is a classic example of displaying the right info at the right time. Showing everything upfront can only overload users cognitively than helping them saving one click. Display ONLY the appropriate information ONLY when users need it. When it compares with pausing and pondering, one natural click is not that big of a deal. As it’s pointed out by Susan M. Weinschenk in her book “100 things every designer needs to know about people”, motor/movement uses much less load than a cognitive task.
To give you an example. When a user needs to select an item from a list, and there are complex validations(use cases) or limitation(backend issues). Unless these validation criteria can be written out in extremely easy and simple words that it is guaranteed to be understood by end-users, showing this info upfront is a cognitive disaster. Let the user choose and give an error, a specific reason, and a way to fix it. Don’t try to save them from an error(one click) but overload them with unnecessary information.
👉 Always ask yourself, is this piece of information absolutely needed on this screen, will users understand them at this page? Reveal only the right information as long as it’s natural and intuitive to perform one or two “extra click(s)” to reveal the other info that is needed.
Reveal technical terms to end-users
The more in-depth knowledge a designer has about the technology or domain area, the more likely he is to throw what is supposed to be hidden from the user directly onto the users’ face. And he believes the user should know the product as much as he knows and understand how to use it.
Recently we wanted to support country C to be able to use the local carrier phone numbers for inbound and outbound calls. For the end-user, he only knew that he can make phone calls using his old number. For the admin(A), he needed to add these individuals to a gateway device, which makes the magic happen. The admin(B) who set up the gateway device most likely may not be the same person who is adding users. Initially, we had this concept of a gateway user and the team soon got comfortable with the term. The user story can be described as when the admin(B) was to set up a user, B chose if a user is a gateway user and then chose a gateway device to route the calls. Then this user will be able to make calls in country C using a local carrier number. Seems straightforward. But if you think about it a bit more… What is a gateway user? Why do I need to choose a gateway device? Does the end-user need to know anything about it? Of course NOT. Does the admin(B) really need to know this and truly understand what is going on? Not really. He only needed to decide whether this user wanted to use the number from his own local carrier. If he chose yes, then we gradually guided him and tell him to select a gateway device( which is already set up by someone else) and tell him why he needed to do so.
👉 Focus on the key real-life purpose(make calls in country C) instead of some technical new term(gateway user).
When there are terminologies used, ask yourself one more time, do users need to know this? Will they be comfortable seeing it? Don’t simply assume they can understand it. Test the design and guide them through the concept with easy and straightforward language.
Design based on the most complex use cases
As we all know, for enterprise services, because the processes of different companies vary, needs differ, the applications often can be very complicated. Certain features can be on-demand only. Roles with separate permission have access to different features. So the UI has many different variations depending on account and role. Experience designers need to work with PM to sort through the various possible use cases, and to smooth out the most complex and unlikely edge use cases.
Think through all complex use cases, but don’t design based on the complex one. A lot of information is not needed for a “happy path,” and it can cause confusion.
For example, in our admin portal, admin can add more users. For enterprise companies, the happy path is many will choose from their inventory, and there is no payment or billing involved. Just confirm the order, and it’s done. However, in the case of two roles with different permission(one purchasing, one provisioning), when internal communication or execution is not that smooth, the billing admin may have filled the stock but IT admin misuses the number inventory, which can result in a weird use case that IT admin needs to purchase additional numbers that are supposed to be included when there are enough digital line licenses.
Originally, we tried to list these different assets all out, building a purchasing summary for them as guidance. We thought it was clear. However, for more than 80% of the time, numbers were included and listed them out separately threw the participants off during the user testing. The final solution was that we only mentioned these additional numbers purchase when there was such a situation, and we had a help text close to it says: What’s the charge for. The user can hover or click to learn why they need to pay and what is it. In other use cases, there was no need to mention this information.
👉 Focus on 80% of use cases to ensure that the happy path is clear and concise. Complex edge use cases are treated as special cases; additional information should be revealed only in the necessary situation. Do not try to explain everything all upfront.
