The Web as Intended

Created: Thursday, 24 July 2008 Written by Gary Elsbernd

One of the podcasts I listen to - Boagworld by Paul Boag - had an interesting feature this week about context - about how where we are influences what we want from a website. Paul listed five contextual considerations for developing for the web; Environment, Device, Comfort, Mood, Time.  He makes good points about them, especially the lack of traditional input tools on most mobile devices, but doesn't go far enough into motivations.  This tied into many things I've been thinking about with the release of the 3G iPhone.

Like most people, 99% of my browsing is done from a laptop or desktop sitting on a desk.  For these times, traditional websites are fine, and even optimized for the experience.  I have an expectation that I can browse, dig deeper and see layouts on a computer with high-bandwidth, full browsers and plugins and a high-resolution, large screen as they were intended by the designer. From design to implementation to interaction, everything about the web browsing experience has been optimized for my viewing pleasure in a relaxed setting.

My mobile surfing experience has been on a Palm Treo.  The screen is much smaller, the input is more awkward (no mouse) and the speeds are much, much slower. When I surf on my phone, I generally need specific information such as an address, geocache description or a sports score. The experience is much different in many ways, and not just that the hardware is less capable and I may be outside.  I also want to use the mobile for different things.

When you are at a desk, you have the opportunity to browse.  The idea of "surfing the web" came from the idea of skimming the top of the ocean of information, going where the wave takes you and finding things through serendipity.  When you are mobile, you are much more targeted on a specific need.  I don't want to look at a company's brochures or product demos on a phone.  I don't need all of your pretty branding and themes if I am browsing over a 3G or Edge network. There is a greater sense of urgency and focus.

The solution used to be a WAP (wireless access protocoal) site that is optimized for the mobile browsing platform - it has scaled back images, floats into a narrow column that can be read on a 320x240 screen, and has large links and buttons for tapping.  A good example is ESPN for getting game scores and play-by-play: http://wap.espn.com/ You can within three clicks find any college football game on a Fall Saturday and watch see short play-by-play descriptions on an automatically refreshed page.  On a regular computer, the interface is hideous compared to what we've been led to expect, but on a phone, the load times are lightning quick, and interactions and decision points are crisp, getting you where you want to go quickly and with a minimum of fuss. Compare this with their regular doorway of http://www.espn.com/. The mobile site features next to none of the graphics, advertisements and animations of the website.  It allows you to dig deeper into the stories you want to see, but leaves out many of the feature stories and options that wouldn't translate to the mobile web.  ESPN knows what their mobile users want and how that differs from what they want when they sit down at a computer, and delivers.

The iPhone and the new 3G iPhone started to change the thinking around mobile browsing.  Having the Safari browser installed and their zoom features lead developers to think there is no longer a need for a WAP.  Users can browse their entire traditional site on their phone, so we don't have to change a thing.  The missing factor in this equation is still intent.

In my work in the insurance industry, I have often wanted to develop a WAP application, to see how it's done and experiment.  The problem is, no one wants to work on their insurance while they're mobile.  Reviewing insurance is a more reflective task, requiring paperwork, comparisons and details that cannot be easily supported in 320x240.  I will find a way to do this, as our sales force is mobile, but other than basic communications covered by email, twitter, SMS and actual phone calls (do phones still make phone calls?), I haven't found the killer application yet that is targeted, a short duration, requires minimal entry and can be done without a lot of reference materials at hand.

Give me time.

 

When getting better makes things worse

Created: Monday, 30 June 2008 Written by Gary Elsbernd

When you change things, people will resist.  When you change things for the better, people will still resist.

Often, just being better isn't as important to acceptance of a new design as conformity with the conventions in place.  Take, for example, the control panel in Windows Vista.  Arguably, the configurations and applications are better organized, better labeled and easier to find.  Easier, that is, if you haven't already been trained to find them in different areas and under different labels in earlier versions of Windows.  There are twice as many controls in the Vista control panel, giving the user more granular control over the settings and configurations.  That should be a good thing, right?  Not if you are used to finding configurations buried under other objects and have just accepted the fact and moved on.  Now you are being asked to relearn where things are and will spend time fumbling around, especially if you have some legacy computers running different versions of Windows. While this reconfiguration will benefit new users, experienced users don't see enough marginal benefit to accept the change gracefully.

This concept should be considered in all design projects.  While you might have a better way of doing things, decide if it's enough better to force all of your users to change their mental maps.  It's amazing what people can get used to (imagine some of the legacy systems in use today), but unless you can provide compelling reasons to change, people won't.  Your choices are to follow conventions, thereby further cementing that design in the minds of the users, shift them radically and force the transition, or introduce the changes gradually through evolution.

One thing is certain.  No matter how you make changes, some users will complain. The key is to provide enough benefit that they get over it quickly.

For another perspective, see Gery's Law.

 

Systems Training

Created: Tuesday, 03 June 2008 Written by Gary Elsbernd

Gloria Gery once told me that all systems training is compensatory for poor design.  In other words, if the design is perfect, no training is needed.

"Just remember: you're not a 'dummy,' no matter what those computer books claim. The real dummies are the people who–though technically expert–couldn't design hardware and software that's usable by normal consumers if their lives depended upon it." - (Walter Mossberg)

This thought has stuck with me as I've designed every increasingly complex systems.  I've decided I agree with her, and that it's not a bad thing.

Before you start sending emails, this doesn't say:

  • All training is unnecessary in every case.  Training is necessary to incorporate new employees into a business.  Domain knowledge about the business you are in, corporate attitudes, principles and guidelines must be learned, along with key procedures in case of emergencies.  What this does imply is training should be focused on value-added information that is best transferred person-to-person, instead of rote procedures and facts about systems.
  • People should be able to walk up and use a system to its fullest.  The system should be built so that given a user knowing WHAT he or she is supposed to do, HOW to do it is evident.  Shortcuts and other productivity enhancements may be learned over time, but their absence should not inhibit or prevent performance of the task.
  • Designing systems that require no training is possible, or even desirable in all situations.  Such explicit systems require a great deal of knowledge of the performance environments, users, motivations, business needs and capabilities.  The time spent to develop a training free system may not be justified by the benefits.  If a short tutorial or instructions and system help within the application can help the user grasp the essentials, it may be a better use of resources to go this way.Additionally, ease of learning does not always equate with ease of use.  A system that is easy for anyone off the street to use is rarely one that "expert" users can use productively.  Consider most "wizard" interfaces.  An interview style interface walks the user through decision points and gathers information.  The wizard presents the decisions along with explanations of the implications of the step.  These systems can be used by nearly anyone because the domain knowledge and how it is represented in the system are explicit.  If an expert user does not require such handholding, a single screen interface with just the data fields may be sufficient to perform the task much more efficiently.  Familiarity with the business and a system allows experts to rapidly perform tasks such as data entry at a speed that would be impossible in a wizard-like interface.

As a designer, I strive to design the most intuitive systems and applications I can.  I go into a design knowing some training will probably be necessary, but I don't give in to the temptation to say, when faced with a design compromise, "Oh, that will be covered in systems training."

My approach has been to design a system as intuitively as possible, and then, based on user feedback during testing, add instructions to the screens and information to reference and training.  The key is frequent and iterative testing.  Get a design out in front of as many people as possible.  When faced with an issue, either integrate a solution into the application, add on-screen instructions, add online reference or training, or add it to a training class curriculum.  This "Frequently Asked Questions" method of systems documentation and training allows the trainers to focus on issues that realistically come up instead of spending time and effort documenting functions and behaviors that are well accepted by everyone.

Now you may let the emails fly.  :)

Elsbernd's Hierarchy of Needs

Created: Thursday, 17 April 2008 Written by Gary Elsbernd

A constant among psychology and instructional design classes is Maslow's hierarchy of needs. Whether you agree with the criticisms of Wahba and Bridgewell or not, Maslow's theory still provides a valuable framework for describing and evaluating individual motivations.  The notions of hierarchical needs wherein one set of needs must be satisfied before the next set can be prioritized can be applied to system design as well, and is described by the blatant ripoff, er, homage, Elsbernd's Hierarcy of System Needs.

What do you want in a system?  The answer depends on what you need to do and how you are accomplishing that goal currently.  In the early days functionality was enough as long as the system allowed you to do something you couldn't do before, users would suffer through horribly obscure and arcane coding to complete their tasks.  Witness the costs, time and effort involved in old punchcard computers, yet because it allowed them to do something new, companies endured it.

For a time, functionality is added, but functionality eventually loses it's glow.  When users are forced to wait while systems are down or slow, system developers are tasked with making it faster and more powerful. The need for performance comes to the top of the priority list.

At some point in the system's evolution, a sufficient level of functionality and performance is reached, and the next competitive advantage becomes usability.  The ability for users to complete tasks with a minimum of training and in various contexts becomes a selling point when all functionality sets are comparable.  Ease of learning and ease of use allows less skilled workers to complete tasks, or skilled workers to focus less on the system and more on their work.

Aesthetics is the final enhancement, in that if the system is usable, it can also be enjoyable or pleasant to use.  Aesthetic features, such as enhanced graphics, animations, sound, layout and balance on the page all impact the user experience.

Of course, all of these features exist to some extent in every system.  The balance between these four factors is what can make or break system success, based on the hierarchy of system needs.

Maslow's Hierarchy of Needs

Maslow's hierarchy of needs is often depicted as a pyramid consisting of five levels: the four lower levels are grouped together as being associated with physiological needs, while the top level is termed growth needs associated with psychological needs. Deficiency needs must be met first. Once these are met, seeking to satisfy growth needs drives personal growth. The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. Once an individual has moved upwards to the next level, needs in the lower level will no longer be prioritized. If a lower set of needs is no longer being met, the individual will temporarily re-prioritize those needs by focusing attention on the unfulfilled needs, but will not permanently regress to the lower level. For instance, a businessman (at the esteem level) who is diagnosed with cancer will spend a great deal of time concentrating on his health (physiological needs), but will continue to value his work performance (esteem needs) and will likely return to work during periods of remission.

Elsbernd's Hierarchy of System Needs

A similar model is proposed for the evolution of software development.

Deficiency needs - These needs are required for success, but as soon as the needs are met, they are taken for granted.  Their absence causes dissatisfaction, but otherwise they are invisible to the common user.

  • Functionality - features and capabilities relevant to the task at hand, are the fundamental need for systems.  If the system doesn't do anything you need to do, it has no value.
  • Performance - the system must respond in a reasonable time, provide secure access and access when expected.

Growth Needs - These needs are not strictly required for task completion, but they improve the user experience to build loyalty and positive perceptions of the system and tasks.  This delight can improve satisfaction, retention and morale among users.

Usability - Usability makes the system accessible to a wider group of users.  Whereas early word processing and desktop publishing tools were only used by trained users in specialized departments, now everyone has one of these tools on their desks due to improved user models built into the systems and integration with their other tasks.  The systems are more intuitive through the use of common ui conventions and affordances (the design of the system controls suggests their use).

Aesthetics -  People like well-designed systems.  Attractive systems are perceived as faster, better performing and more effective than unattractive systems.

Just as in Maslow's Hierarchy, systems develop from the bottom of the hierarchy up.  The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. If a change in process or product causes one of the lower needs to become unfulfilled because the current system can no longer meet the needs, the functionality or performance needs will be reprioritized over usability or aesthetics until functionality and performance are restored.

The final factor not represented in the current document is cost.  Cost is a limiting factor of how much time and effort is expended getting to higher levels, to achieve and maintain the level of satisfaction or delight demanded by the users.  Organizations must determine the cost of achieving the next level and the competitive advantage it will bring.

More Articles ...