Humanization is no different from any other design technique
Like many other design approaches, humanizing an interface has advantages and disadvantages and as such, is correspondingly prone to overuse and misuse.
I'm not a fan of humanizing as a goal. Websites are not humans, and trying to humanize a website is useful only if it actually improves user ...
No. It is not always appropriate to minimize cognitive load.
Minimizing cognitive load is not the goal of usability, human factors, UX, or the user centered design process in general. It is about "good design", and good design is not always the simple design.
To clarify the rationale, let's make sure we have a definition for "cognitive load".
I would say it's too humanized if it hinders the users in finding the information they visited the site for in the first place.
I once visited the website of the local supermarket to find out their opening hours on a holiday. I entered every menu option i could see, but couldn't find the opening times. Instead, I found a lot of pictures of smiling employees,...
Reducing UX friction/cognitive load is only helpful if it accomplishes some design goal. Usually, low-friction UX is desirable because it can help users accompish tasks faster, with greater efficiency/productivity, etc.
However, sometimes designers introduce deliberate cognitive load for legitimate reasons.
Here are some examples of deliberate friction ...
Option 2 leaves the modified content in place and visible. It means that your users don't have to recall the data they just submitted / modified.
Inline notification (Option 2):
Does not make the user recall/remember the data.
Keeps the modified data visible, allowing the user to catch any mistakes they may have made
Keeps the state indicator ('Saved') in ...
TL;DR: Top, or both.
Nielsen notes that consistency breeds familiarity, so you should comply with conventions to meet user expectations:
This consistency means that people know a breadcrumb trail when they see one, and immediately know how to use it. Consistency breeds familiarity and predictability, which breed usability. This again means that you must ...
There are already some good answers in this thread. As mentioned, it depends on the system and the context of use.
That being said, I would like to take another viewpoint and highlight a case where users preferred cognitive load over a simplistic design.
The Bloomberg Terminal
The Bloomberg terminal looks like this and people say it's hideous.
One question to ask is: Is the user aware of the benefits of upgrading / activating? How am I improving their life?
In the current state, you have a card list, other than the button label, I can't differentiate between the two. I also don't really see the benefits, and 'Activate' could mean a committment before I've learned what it's doing for my company.
Indicating the caps lock is on is a design pattern used for passwords. When the passwords are hidden and every character is only represented by a dot, users might not know they're typing capitals where they shouldn't.
It's easy to overlook the fact your caps lock is on. For example, I'm used to typing with ten fingers. While typing my elbows are set quite ...
Include the 404 — problem solvers will appreciate it
There’s no better or more concise way to communicate the nature of the problem to experts who may have to help your user.
“404” on your error pages is not harmful
Just to get this out of the way, including the error code is not bad, confusing, or annoying. If it were, major web companies like Google and ...
It depends on what behavior is being changed
Milton Glaser created the following illustration he calls "The Road To Hell", which shows gradients in design ethics:
For most cases in The Road to Hell, the design objective is to convince users to buy something. But the illustration shows that the nature of the product and the type of designed ...
Option 2 is better, as discussed by Mike M. I would actually recommend a third option, similar to Option 2. I would replace the "Submit" and "Cancel" buttons with the "Saving" message and spinner. This ensures the first thing the user sees is the "Saving" message. When a user presses the button, their eyes will linger there until something else catches their ...
An experience is overly personal when it shares irrelevant details that get in the way of the message. Humanizing is just explaining things in terms of people rather than systems, not telling someone’s life story for no reason.
Although I like your solution of naming the buttons differently (manage vs activate) but I did not noticed the difference in vocabulary right away. In my experience, I like ghosting the unavailable containers and perhaps a little snipe in the corner. Allow the entire box to be clickable.
If you're looking for something that symbolises the word 'remove' then why not just use the word 'remove'?
It's not especially large a word. And you have plenty of space in that UI to fit it in there. Plus it removes any ambiguity as to what it means.
The drop down has a disadvantage compared with the radio-buttons and the slider-toggle. The user has to click on it to see the possible options. On mobile (if this is the case) drop downs are not easy to use.
I agree with Owen Hughes about the toggle.
In this case, I would go with the radio buttons. But there is an alternative: You could use a segmented ...
Within a task-completion context:
Yes it should
I'm sorry to be an outlier, but I think a proper answer to this should be a bit more comprehensive.
As a cognitive-scientist-turned-uxer friend on mine who read this question asserted:
If you need to make things harder for the user, you need to make it harder.
But a no answer is dangerous.
The core reason that you don't want to do this is because, as a general rule, any time you override the standard behavior of a users device, you open yourself up to a bad user experience . . . particularly if you do it without any kind of notification.
Overall, within your application, standard control behaviors should continue to behave the way that the ...
A new WCAG 2.1 success criteria is "2.5.5 Target Size", but it's a AAA conformance.
The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
Inline: The target is in a sentence or block ...
What I've found works best for my use case is to, like @Hugo-Viallon suggests, put the spinner in the save button and disable all other buttons. After completion I show a toast if the user isn't redirected.
Without the toast I had users saving multiple times just to make sure it worked, a small confirmation helped prevent that.
You have to be careful when using words. If you internationalize a word you may end up with an equivalent word with many more characters than your intention. If you use a graphic then you are language independent and character independent (which means spatially you are in the known) but there are still considerations based on culture and other factors.
The worst thing to do is to redirect a user to a different page after a time-out. It's best to keep them within the same page and present them with a lightbox that informs them that their session has expired. This gives them the opportunity to re-login to continue working before being redirected to a different page.
Regarding the discard of changes, this ...
When it begins to feel disingenuous, which is nearly always.
In fact, most attempts at 'humanization' result in absurdities that people are so numb to by now they just ignore it. It's just noise at this point. Why generate more noise? Do something more productive.
"Hello! Welcome to our site! What would you like to do today?"
This is, for some reason, ...
I think you should also try a card layout. For example:
This layout provides multiple benefits:
Aids quick scanning
Cards are easier to scan compared to tables.
Easily adapt to small screens
Cards will work better on mobile/smaller devices in this case compared to tables, as they can be organized to scroll in a single column.
Edit/delete buttons are ...
I've used Twitter Bootstrap button groups in the past for this same idea. Since they are actually buttons, and not parts of a slide, I don't think the selected states are confusing (and you can style them to be as unambiguous as you want).
I think the bigger question to ask is whether it meets your needs and what you are trying to solve by implementing ...
"If I had asked people what they wanted, they would have said faster horses." - Henry Ford
I understand the dilemma. I do agree with @Jamezrp. We as UX designers/engineers are between the function of the system, business objectives of the firms we consult/work with, and the most importantly the user who is going to use the system to meet his personal goal. ...
Some suggestions on improving the dropdown:
1. Change continent grouping to more general list
Asia and Oceania
This list requires less mental efforts in selecting the target item, it's more rough, but more efficient. Your original list requires good knowledges in geography and for some users it will be hard to select appropriate ...
As you say "I don't think the average user knows or cares what 404 signifies" so it doesn't matter to him.
But to the technical user the 404 gives extra information.
So if the decision is between displaying and extra sentence or not, displaying it gives some information to a minority of users, while it doesn't bother the majority (average user).
Given the examples you've given for gradual changes and Beta Version, I would say Beta Version makes more sense. I tend to see Beta Version as a good way to transition into a completely new design. This allows for the user to try to use the new design to do what they normally do but be able to fall back the previous version if they really need to or to ...