Do you create products or organize events for UX professionals or manage a UX team that’s hiring? Sponsor UXmatters and see your ad or logo here! Learn moreLearn More



























December 2006 Issue

By Jonathan Follett

Published: December 18, 2006

“Of all the objects that occupy our digital spaces, there are none that capture the imagination so much as icons.”

Of all the objects that occupy our digital spaces, there are none that capture the imagination so much as icons. As symbols, icons can communicate powerfully, be delightful, add to the aesthetic value of software, engage people’s curiosity and playfulness, and encourage experimentation. These symbols are key components of a graphic user interface—mediators between our thoughts and actions, our intentions and accomplishments.

In conjunction with information architecture, icons guide virtual wayfinding and help users to perform specific tasks efficiently. While the term wayfinding typically refers to orienting people in physical space—using graphics, text, signs, and other design elements—it’s useful to examine the use of icons through the lens of digital wayfinding, as a way of generating a fresh perspective on how users perceive and interact with their virtual spaces.

In Steve Caplin’s book Icon Design, Susan Kare, the artist who created the icons for the original Mac desktop and applications said:

“In general, I believe that icons should work a bit like traffic signs; they should convey information without distracting the user, without competing with the data in an application. Ideally, they should suggest something about the functionality. If it is not completely evident, then the function should be easy to remember if the user is told only once.” Read moreRead More>

By Richard F. Cecil

Published: December 18, 2006

“It’s possible to devise a process that is both user-centered and agile.”

Agile software development [1] has become fairly popular in the last few years, leaving many UX professionals wondering how user-centered design (UCD) can fit into an extremely fast-paced development process that uses little documentation. User-centered design can involve a variety of techniques that provide insights into users’ wants, needs, and goals, including ethnography, contextual inquiry, contextual interviewing, usability testing, task analysis, and others. But all of these take time—time that an agile development process might not allow. There is hope, though. Agile and UCD methods are not completely at odds with each other—and in some cases, agile development can even enable a more user-centered approach. By taking the time to understand the differences and similarities between agile development and UCD, it’s possible to devise a process that is both user-centered and agile.

Similarities Between Agile and UCD Methods

Let’s start by exploring the similarities between the two approaches.

I particularly like Alistair Cockburn’s comparison of an agile development process to a cooperative game: “Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.” Thus, according to Cockburn, an agile development method, at its core, is about delivering useful software. According to Rassa Katz-Haas, user-centered design is about understanding people’s needs—so we can provide useful software. She writes: “[User-centered design] places the person (as opposed to the thing) at the center…. UCD seeks to answer questions about users and their tasks and goals, then use the findings to drive development and design.” Read moreRead More>

By Dirk Knemeyer

Published: December 4, 2006

Part Two: Dimensions, Needs, and Desires

Part One of this series introduced a design framework for meeting human needs and desires and defined five States of Being that represent the different degrees to which products and experiences affect and motivate people in their lives. This second part explains three Dimensions of Human Behavior, as well as specific needs and desires for which we can intentionally design products. The third and final part of this series will explore the relationships between different human needs and desires, talk about how designers can put this framework to use, and share some examples that will hopefully help make this approach of practical value to you.

The Three Dimensions of Human Behavior

Typically, we design products for a specific end state. For example, someone has an idea that a large beanbag can function as a chair. Or someone imagines how improving a paperless payment system can work more effectively than a manual system that is currently in use. Or customer feedback leads to the optimization of a Web site workflow that helps people complete their tasks more quickly. But in each of these examples, the focus is on things other than the essence of the actual people who will use the products—whether that focus is on the application of a particular material, on using technology to make a process easier, or responding to customers’ feedback to keep them satisfied. As I previously described in Part One of this series, the intentional attempt to satisfy people’s internal needs and desires simply isn’t there. Read moreRead More>

By Luke Wroblewski

Published: December 4, 2006

“Simplicity doesn’t come easy.”

Though many business strategies and publications continue to trumpet the power of simplicity in the design of digital products, for lots of companies and product teams, simplicity doesn’t come easy.

“Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.”—Charles Mingus

While there are many reasons why keeping things simple is difficult, I’ve encountered the following three causes quite frequently:

  • Perceived simplicity can often conflict with actual simplicity of usage.
  • Actions that provide real value—and drive revenue—often have formidable learning curves.
  • Gradual engagement, the most frequently cited solution for managing complexity, is actually quite difficult to design and build.

Read moreRead More>