Let’s talk about icons now. They’re an essential part of many user interfaces. The thing is: more often than not, they break clarity.
An older article about Why the Flat Design Trend is Hurting Usability, got me thinking about this subject again.
I agree with some of what the article is saying, though I feel saying flat design is hurting usability is a bold statement. I would say instead that designers use of flat design can sometimes be taken too far. When this happens the whole reason to use “flat” as a design technique can backfire and will created the opposite visual advantages, making the design harder for someone to use.
I’ve written about this before, but I believe the answer lies somewhere in the middle of skeuomorphism and flat.
Google does a great job of this I believe. They have flat looking designs but when needed aren’t afraid to use a drop shadows, gradients and strokes for depth and separation of objects.
I personally feel this technique isn’t skeuomorphic nor is it 100% flat. I’ve ran into more instances where a slight separation is needed to make something stand out of a design or separate it from another element.
As a designer it’s my job to make solve a problem for a user. If the solution is a slight gradient on a button to make it look like something that is active and requires action, then there is NO harm in doing so and if done well, doesn’t date the design or make it look non-modern.
If you haven’t already, now is the time to prioritize your website’s design considerations for tablet functionality. Ignoring this could negatively impact your website’s overall conversion rate, return visits, sales and more.
A typical usability test may return over 100 usability issues. How can you prioritise the issues so that the development team know which ones are the most serious? By asking just 3 questions of any usability problem, we are able to classify its severity as low, medium, serious or critical.
This site looks a bit dated but the info in here is priceless and full of useful content.
and the list goes ON AND ON. It’s a great reference.
I’ve been thinking a lot lately about e-commerce sites and found this article. It’s an older article but I think it’s still relevant in this day…
The ISO 9241 standard defines website usability as the “effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.” When using a website, users have a particular goal. If designed well, the website will meet that goal and align it with the goals of the organization behind the website. Standing between the user’s goal and the organization’s goals is very often a form, because, despite the advances in human-computer interaction, forms remain the predominant form of interaction for users on the Web. In fact, forms are often considered to be the last and most important stage of the journey to the completion of goals.
check out the full Extensive Guide To Web Form Usability @ Smashing UX Design.
There are many things we can do to improve the design of Web forms. But what can we do to really boost conversion? Here’s a few case studies that illustrate how the removal, clarity, and even indication of requirements can have a real impact on form conversion.
check out What Impacts Web Form Conversion? from LukeW.
Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?
We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.
We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.
What we found was really interesting. Less than 5% of the users we surveyed had changed any settings at all. More than 95% had kept the settings in the exact configuration that the program installed in.
This was particularly curious because some of the program’s defaults were notable. For example, the program had a feature that would automatically save your work as edited a document, to prevent losing anything in case of a system or program failure. In the default settings for the version we analyzed, this feature was disabled. Users had to explicitly turn it on to make it work.
Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,” several of the participants told us.
We thought about that and wondered what the rationale was for keeping such an important feature turned off. We thought that maybe they were concerned about people running off floppies or those who had slow or small disks. Autosave does have performance implications, so maybe they were optimizing the behavior for the worst case, assuming that users who had the luxury to use the feature would turn it on.
We had friends in the Microsoft Office group, so we asked them about the choice of delivering the feature disabled. We explained our hypothesis about optimizing for performance. They asked around and told us our hypothesis was incorrect.
It turns out the reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.
Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled. The users’ assumption that Microsoft had given this careful consideration turned out not to be the case.
We also asked our participants for background information, like age and occupation, to see if that made a difference. It didn’t, except one category of people who almost always changed their settings: programmers and designers. They often had changed more than 40% (and some had changed as much as 80%) of the options in the program.
It seems programmers and designers like to customize their environment. Who would’ve guessed? Could that be why they chose their profession?
(Big takeaway: If you’re a programmer or designer, then you’re not like most people. Just because you change your settings in apps you use doesn’t mean that your users will, unless they are also programmers and designers.)
We’ve repeated this experiment in various forms over the years. We’ve found it to be consistently true: users rarely change their settings.
If your application has settings, have you looked to see what your users do? How many have changed them? Are the defaults the optimal choice? Does your settings screen explain the implications of each setting and give your users a good reason for mucking with the defaults?
The first version of Usaura lets you do one test: a click test. What’s a click test? Basically, you upload a screenshot of your interface, or even just a mockup, and provide instructions to the testers, e.g. “Click on where you think you can learn about the pricing for this product.”
Honest usability techniques when applied properly will expand your site layouts beyond the elite in web design. When you can open your mind to new ideas it’s possible to manifest brilliant visions into your web pages. This hierarchy plays double for user interface objects and forms.
Good read and important findings.. like this:
For example, the study found that users aren’t crazy about using their iPad devices to deal with complicated forms that require lots of user input, especially if those forms are found in non-optimized websites, rather than housed in an app. Users would skip registrations processes rather than deal with inputting information in many cases. The solution to such a problem would be to make forms simpler, requiring less information, and reduce the need for repeat entry of information (so apps that offer to remember login details are better, for example).