Ideas with Action

Created: Monday, 22 June 2015 Written by Gary Elsbernd

To quote a Japanese proverb, vision without action is a daydream.

I was working on dashboards within a logfile collection last week, when I was challenged how to determine the right components for the dashboard, and had several insights.

  • There is not one "dashboard" - there are dashboards for each stakeholder. The data of interest to each stakeholder depends on his or her entry perspective.
  • Dashboards are meant to provide a synopsis, not the whole story.  A user needs to be able to identify issues at a glance, with as little involvement as possible.  Pie charts, bar charts, and averages all provide a high level indicator that can be drilled down if something looks amiss.
  • The level of information isn't the same across stakeholders. Trends over time may be significant to an executive, but an engineer may need specific details at the transaction level. A system wide response time number is relevant to a user who knows tolerances and expected values, but a global number may mask small components within the average. Drill-downs, trends and thresholds are all contextual to the user viewing the dashboard.
  • It isn't enough for the data represented to be interesting. Seeing where in the world our users are connecting from may be interesting, but have no impact on me or my plans. I have to be able to act on the information, or I am just presenting trivia.

This leads me to my overarching recommendation on dashboards:

"Identify the highest level of visualization for each stakeholder that provides meaningful information, leading to action."

Easy to Learn vs Easy to Use

Created: Saturday, 09 May 2015 Written by Gary Elsbernd

Designing an application is a balance between making it easy to learn and easy to use.  Something easy to learn may require additional instructions, work breakdown or examples.  Something easy to use, on the other hand, assumes mastery of the domain knowledge an tool, and attempts to streamline the task at hand.

Consider tax preparation software – for the novice who does their taxes once a year (infrequent task, high consequence of failure), a wizard walks through a series of questions complete with “What is this important” and instructions about where to find the required information.  A CPA, on the other hand, can go directly to the forms and fill them out quickly, having already mastered the domain knowledge and completing the task frequently.  Each of these users would be lost or frustrated with the opposite interface.

Designing for the user requires knowledge of their context (domain mastery, frequency of task, how the task presents itself) which can only be found through upfront contextual inquiry.  Sometimes you may have to create multiple interfaces for an application, or bolted on wizards to support the normal users and “pros”.

Where to Start in UX

Created: Monday, 18 May 2015 Written by Gary Elsbernd

If you work in the field of User Experience, you have to know about the following resources. I will keep adding to this list.

Krug, S. (2013), Don’t Make Me Think: A Common Sense Approach to Web Usability, Berkeley, CA: New Riders

This book includes Krug’s Laws of Usability:

1. “Don’t make me think.”

2. “It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.”

3. “Get rid of half the words on each page, then get rid of half of what is left.”

Norman, D. (2013), Design of Everyday Things: Revised and Expanded Edition, New York, NY: Basic Books

Formerly known as “Psychology of Everyday Things”, this book introduces the ideas of affordance and mental models. If you see anything by Donald Norman, get it and read it.

Beyer, H and Holtzblatt, K. (1997), Contextual Design: Defining Customer-Centered Systems, Burlington, MA: Morgan Kauffman

While this hasn’t been updated in far too long, this book supplies the techniques and tips to conduct thorough and effective user studies to identify “real users, doing real work, in their real environment.”

Ertmer, P., Quinn J. and Glazewski, K. (2013) The ID CaseBook: Case Studies in Instructional Design, Old Tappan, NJ: Pearson

This is a series of open-ended instructional design case studies that strengthen and encourage successful problem solving, and conceptual, procedural, and analytical skills to be used with a variety of real-world clients and the execution of creative solutions. Oh, and by the way, I co-wrote one of the case studies.

Also, Performance Consulting, by Robinson and Robinson, and Metaphors We Live By, by George Laikoff.


Consistency is the Hobgoblin of Little Minds... or Is It?

Created: Wednesday, 13 May 2015 Written by Gary Elsbernd

In my career, I have heard the quote “Consistency is the hobgoblin of little minds” when a client or business owner wanted to do something new, often for the sake of doing something new. The full quote by Ralph Waldo Emerson is ““A foolish consistency is the hobgoblin of little minds.” There is a very important distinction there.

Consistency is essential to reducing the cognitive load of your interface – the mental effort required to complete a task. When a design is consistent, every interaction feels smooth and frictionless. When it is too inconsistent, the user must expend unnecessary effort figuring out the interface instead of completing the work.

Design patterns, like cliches, are used over and over again because they speak to an underlying truth. UI patterns are design solutions to common usability problems. Patterns benefit everyone – users already recognize how to use them from previous exposure, and designers don’t need to reinvent the wheel. Knowing where to find a home button, or how links are styled, or how to interact with a list builder are important to a user because few people sit down with an express goal of “I want to use this interface.” Instead, they want to complete a task, and your interface is either the tool that allows them to accomplish their goal or the roadblock keeping them from getting things done.

On the other hand, inconsistency is not all bad. You need to know when and why to break the consistency without leading to design chaos. There are several reasons you may wish to be inconsistent within your established style or conventions and patterns in the market.

All established patterns were once new. Without stretching our designs, we cannot progress. Doing the same things over and over will yield boring, uniform designs. Sometimes experimentation is necessary to see if social assumptions still hold true. When I first started developing CBT courses, the first module was always “How to Use a Mouse.” Times have changed and many advanced interaction patterns are now considered commonplace.

Sometimes the goal is to slow the user down. A friend of mine, Dr. Steve Fedorko, once floated the controversial idea that sometimes an organization should deter or prevent learning in order to force the user to slow down and contemplate their decisions. Actions with extreme consequences may be designed to change from use to use, so a user cannot mindlessly blast through without considering the consequences.

Intentional inconsistency can draw attention to your site for novelty, but must match the context – having a parallax slider and infinite zoom interface may be flashy, but would not work well for most purposes in a tax preparation organization. For that organization, reducing cognitive burden, streamlining performance and minimizing risk of error has to outweigh a “really bichin’ interface.”

The key, as is most often the case in design, is balance. Consistency does not equal uniformity. Design shouldn’t be a game of templates, but should reflect the usability advantages of existing patterns.