When people ask me what I do, I usually start out by telling them that I make websites easy to use. Little do they know what superfluous rant is heading their way. I can’t help it. I love what I do.
I start geting excited that someone is actually truly interested in the nerdiness of researching, sketching, designing around mental models and expectations, iterating after testing in a bubble room with a lab coat and developing the structure, styles and behavior of the thing only to integrate with the “back-end.” Whew!
Usually, in this situation, I get a few nods, sometimes smiles but always a “You’re pretty much speaking another language to me” at the end. Leaving the poor soul on the other end of the conversation looking like a dear in headlights, somewhat sorry they asked me to elaborate in the first place, and mostly looking for a way to change the subject.
Usually, in this situation, I get a few nods, sometimes smiles but always a “You’re pretty much speaking another language to me” at the end.
This conversation dynamic is something I always try to keep in mind when I’m thinking of different page elements or interactions I apply to interfaces. I feel like this exactly the type of conversation that happens between an application and the people using it, a give and take. A trial and error. A meeting or complete missing of expectations, feelings and emotions being exerted and a intended or more often than not, unintended result.
One method I like to use when trying to reduce the amount of mental processing users need to bring to the conversation, is the V.I.M.M. model. I was introduced to this when I took training classes at Human Factors International to become certified as a Usability Analyst.
The V.I.M.M. acronym stands for Visual, Intellectual, Mental and Motor cognitive loads placed on users during this conversation. There are often trade offs and decisions to be made where you can increase the amount of thinking a users needs to perform in any of these areas in order to reduce another area. But the design methodology helps me think of the intended purposes of basic design principles in visual design, organizational structures in both IA and code, and implementing conventional interaction design patterns.
Visual cognitive load is increased every time a border, background, alignment of content, text, imagery, or any other piece of content is added to the interface. I could keep going, but I’m sure you get the idea.
My approach to visual design is to think of adding visual elements only to communicate the priority or grouping of content in order to facilitate the information architecture and interaction design decisions made in previous design steps. Visual clutter is subjective to the project and audience. The audience’s visual expectations of content load on ESPN.com versus BostonGlobe.com are vastly different.
A great way to reduce the visual load is by starting your designs from an established grid from a development framework.
Intellectual cognitive load refers to the amount of processing it takes to understand what is happening, where one is and what to do next. In other words, how much do we require our user to think when using our websites or applications?
This is the one area that the most serious usability problems arise in usability testing. Confusing labels that users must interpret, confusing and downright wonky user flows and unconventional usage of interaction design patterns are a few examples of what increases the intellectual load of interfaces.
User interviews and research will help quite a bit with the tone and language of the site. Pair that with a copywriter and you’ll be pretty golden for the first iteration of the design. However, it takes a good couple sessions of usability testing to fix most of the usability issues you originally introduce into the design.
We put a memory processing load onto our users when we require them to use their short or long term memory. Relying on recall versus recognition. Providing clear navigational affordance and sensible defaults are an easy way to reduce the amount of memory the user needs to make during interaction.
The physical demand we place on the users because of switching devices (keyboard & mouse), presentation of small, hard to hit targets, large distances between targets and excessive clicking and scrolling make up high cognitive motor load. In productivity application software, high motor loads are extremely serious. Thinking about the tasks users have to perform day in and day out, hundreds, sometimes thousand times per day are the tasks where you really try to reduce the motor load where carpal tunnel risks are much higher.
Next time you’re designing a site or application, think about the amount of cognitive load you are placing on your users when making design decisions.