Well, this is a list of nothing but truisms. Take each of the "foundations" and do a simple test: state the opposite and check if it makes any sense; if it doesn't make sense at all, then it probably means they aren't really saying anything worthy.
The said "foundations", stripped down of verbosity, are:
* Consistency;
* Convention;
* Ask for minimum input;
* Load and react fast;
* Use animation to communicate changes;
* Avoid clutter;
* Avoid content which screams "fake".
Now, would anyone advocate for the opposite of consistency, convention, minimizing user work or being fast/giving feedback? This is pretty much the same as saying that the foundation of flying a plane is to not crash said plane. True, but not very helpful.
I think there's still value in this list of principles - they are so often violated that it seems that they are less than self-evident!
I've seen lots of engineers advocate for the opposite of consistency or convention in the past, when building particular features. Things like consistency; the attitude that your app doesn't have to follow the rules of the platform and act the same way as others do is surprisingly common!
Similarly, minimising clutter is often overlooked. How often do you see an engineer add a knob or checkbox to control a function without proper consideration of where that should appear in the workflow and whether or not it clutters the user's view? I definitely see that quite often.
So yeah, nobody will actively state that convention is bad, but many will treat it as being less important than it is. So it's definitely worth bearing these principles in mind, IMO.
When you put it like that, sure. But there are often tradeoffs where something and its "opposite" may both have appealing characteristics, and you need to pick one. I've heard reasonable people argue for things that are in conflict with these principles. For example (in the same order):
* Build user interfaces that are suited to a particular task. Don't sacrifice the optimal interface for a task for consistency between different parts of your site.
* Use your company's brand color throughout your app. This gives your app a consistent visual theme and makes it easy for users to find it.
* Make it possible to accomplish all common tasks in as few screens as possible. Don't force users to go through multiple steps to enter information.
* Don't waste time optimizing your code for fast loading before you know which areas your users are spending their time on.
* Show changes as quickly as possible. Don't make the user wait through extraneous animations to see what changed.
* Make sure all important elements are visible "above the fold". If this means reducing padding a bit, so be it.
* Photos lend your app warmth and increase user engagement. Stock photos can be a cost-effective way to do this.
You're right. But I think this is pretty common theme in design; you'll bend the rules many times, but you should know the rules extensively beforehand, to know how and when to break them.
"Now, would anyone advocate for the opposite of consistency, convention, minimizing user work or being fast/giving feedback?"
Of course not, but nobody said anything about intentionally deciding against good UI principles. You might be surprised how often these things are simply overlooked.
Quite to the contrary, I thought the article contained a great list. I see these mistakes all the damn time, and for that reason, it's clear that there's not a universal understanding of how to get them right.
This high-level "here's a few tips" view of the common ways to improve the low hanging fruit (sorry) turns out to be really useful.
> Quite to the contrary, I thought the article contained a great list.
It's not a great list and it's not clearly illustrated. A good starter list would be a combination of Molich and Nielsen's heuristics and Don Norman design principles. But, really, these lists put the emphasis on details, and design should be holistic. If there's a starter advice to give is to study people and their context. There's really little value in having a consistent UI that doesn't map to the user's mental model.
> I see these mistakes all the damn time, and for that reason, it's clear that there's not a universal understanding of how to get them right
You're right, obviously there's not.
However, that doesn't indicate that this list is good or even remotely useful; it's - for me - an indicator that people don't want or don't try to educate themselves and, even worst, IT people are oblivious of design's scope and importance.
> This high-level "here's a few tips" view of the common ways to improve the low hanging fruit (sorry) turns out to be really useful.
There are really many useful - better, clearer, sounder and validated - resources on UI design, UX and usability. The real problem is people doing UI work without education and knowledge, not the lack of resources.
> This high-level "here's a few tips" view [...] turns out to be really useful.
Do you really think spelling out "consistency makes your UI easier to comprehend" is gonna stop people from designing inconsistent UIs? I'd argue it's much more useful to give low-level examples of what makes a UI look/feel/behave consistent.
Well, you and I can disagree on the usefulness of this article then. By that analogy, I see quite a few concrete and "useful" details on how not to crash the plane, here.
It's just a nice summary of some common errors, with suggestions on how to avoid them. It's not the end-all utility to stop them from happening, but it's a good high level view.
Without even a single reference to "get to know your users"? Sorry, but no. It's not a nice summary; it's actually what I wouldn't give to students or someone wanting to get a grasp on UX.
This kind of "guidelines-based" approach is detrimental to UX, as it enforces the idea of focusing on details instead of considering UX as a whole.
I've found wanting to help the user and accidentally confusing them is a common UI anti-pattern. Even after 14 years, I still like Joel Spolsky's posts on UI design: http://www.joelonsoftware.com/uibook/fog0000000249.html.
So, do you always do what is obviously right? I certainly don't, and I think most people are like me. Being reminded to not do things that are obviously wrong, even when I know they're wrong, actually does help keep me from doing them.
I have a problem with "Hungry makes me stupid". If my blood sugar gets low, my judgment slips. And the first thing that slips is the judgment that I need to stop and eat before I do Just This One More Thing. A large number of people in my life are under standing orders to make me stop whatever I'm doing and eat something if they see my judgment impaired. Simple, stupid, obvious. And missing it is pretty much hardwired in me.
> So, do you always do what is obviously right? I certainly don't, and I think most people are like me. Being reminded to not do things that are obviously wrong, even when I know they're wrong, actually does help keep me from doing them.
This would depend on the obviousness at stake. I don't know what your daily job is, but I imagine that there are things so basic that don't really need "remembering". Imagine a programmer being told how a "if" works; that's the obviousness level at stake in this article.
I should obviously not get so caught up in reading that I miss my train stop, but I often do (or I get on the wrong train).
Consider, for a programmer, the obviousness of not using hardcoded values. But we do all the time, as a placeholder while we finish a bigger picture thing. We fully intend to fix it later, but we don't, until it bites us in the ass. That's just one example. Most programmers I know do things they know they shouldn't do, all the time, because it gets them through that particular moment.
I'd be careful with recommending animations. Getting animations right is extremely difficult. And it's dangerous: if you get an animation just slightly wrong, the experience will be worse than a sudden change.
Our brains are pretty good at coping with sudden changes.
What's more important than animating changes, is to make sure the user expects the change. For example, if extra form fields appear after the user clicks a button labelled 'show advanced settings', nobody will be surprised. However, if form fields appear and disappear automatically as you are typing, you'll startle the user wheter you use animation or not.
My recommendation would be: keep UI as static as possible, make changes predictable. If you really want to use animations, put a lot of effort into testing them to make sure they are beneficial. Hastily added animations can do a lot of harm.
Not sure I agree about stock photos. Not all stock photos are headset hotties and bespoke photography is expensive. Even large organisations use stock photos, so I think it makes sense for a small company, especially if it isn't a core competency.
My philosophy is that stock photos are bad when you could be using that space to visually give visitors information about your product/site/organization/whatever.
I work on software for apartment communities, and a huge offender I see is stock photos of smiling people being used on property websites. Do you want to see fake people on an apartment website? No, you want to see photos of the actual property.
You’re right, good catch! The reason is we don’t consider Unsplash to be a conventional stock photo repo, since the style and quality of photography digresses so much from the usual stock photo sites. We probably should have pointed out what we meant by stock photo- the article is targetting sites such as Shutterstock, iStock, Dreamstime, and the like. We love Unsplash, it has a very personal twist on similar subjects, making the photos available there that much more relatable and honest.
For example: the color red is associated with danger and prohibition as established by social convention. Talking about the environment in red colors will confuse users and distract from the message trying to be communicated
How much weight does this really carry if your product is good ? My guess, negligible. Websites just pick a theme color and go with it e.g. Facebook/twitter : blue, Youtube/Google+/Pinterest : red, etc.
If your product is strong enough that people can link colors, shapes and typography directly to your brand, I think you need a pat on the back! For the rest of us, it’s good practice to be careful with established cannon when dealing with potential ambiguities. It’s known that certain color schemes respond to certain conventions, so as long as your brand doesn’t go against them you can use whichever color you want and still be able to communicate your message. The products you mention don’t go against any particular convention, so they can establish their brands within those color schemes.
What do you think about consistency between a mobile app and a website? Logos and other such assets aside, is it valuable to keep the colour scheme the same, and keep UI elements such as buttons the same?
Hi! I’m Vicky from the Codelitt team and author of the blog post, thanks for your question! Consistency is a very important factor when trying to communicate your brand values and setting a clear message for your product, and color schemes shouldn’t be treated differently. Brands have core color palettes that help communicate and keeping those consistent throughout platforms will only strengthen the relationship between the user and the product. However, keeping everything in the UI the same is a bit tricky: there are limitations to how much desktop and mobile platforms should share in terms of UI, as each of them have a set of rules individual to them. While working within those rules, you should try to keep as many constants as you can. For example, if you’ve decided to make any major CTA red with a white font, you should keep that constant for every platform you develop. Consistency in such elements will help ease of use when your users jump from one platform to the next (think of picking up where you left off when switching from desktop to your phone). Menus and navigability, on the other hand, might differ from one platform to the next.
The said "foundations", stripped down of verbosity, are:
* Consistency;
* Convention;
* Ask for minimum input;
* Load and react fast;
* Use animation to communicate changes;
* Avoid clutter;
* Avoid content which screams "fake".
Now, would anyone advocate for the opposite of consistency, convention, minimizing user work or being fast/giving feedback? This is pretty much the same as saying that the foundation of flying a plane is to not crash said plane. True, but not very helpful.