UXtraordinary: everything is UX.
find your way around

Posted by on Sep 3, 2010 in design, taxonomy

Simplicity is not a goal but a tool

Simplicity in design is not a goal but a tool. The goal is the need of the moment: to sell a product, to express an opinion, to teach a concept, to entertain. While elegance and optimal function in design frequently overlaps with simplicity, there are times that simplicity is not only not possible but hurts usability. Yet many designers do not understand this, and over the years, I’ve seen the desire to “keep it simple, stupid,” lead to poor UX.

I was therefore glad to see Francisco Inchauste’s well-thought, longer version of Einstein’s “as simple as possible, but no simpler” remark.

From the column:

As an interactive designer, my first instinct is to simplify things. There is beauty in a clean and functional interface. But through experience I’ve found that sometimes I can’t remove every piece of complexity in an application. The complexity may be unavoidably inherent to the workflow and tasks that need to be performed, or in the density of the information that needs to present. By balancing complexity and what the user needs, I have been able to continue to create successful user experiences.

Plus, as I’ve commented before, messy is fun!

Read More

Posted by on May 14, 2010 in design, psychology, taxonomy

The biggest barrier to UX implementation

My personal experience has been that ignorance is the largest barrier to UX implementation. While there are many exceptions, too often do developers, marketers, executive management, or others with a large level of control over UX strategy and tactical development feel that user experience is simply “common sense.” They believe that they are users, and therefore they have insight into the process. This is natural.

It’s the responsibility of UX professionals to educate them and evangelize the value of user experience. (Though it’s nice if you can get executive support, it’s frequently not there.) At my current company, I approached this from several angles:

  • I held one-on-one meetings with stakeholders and others, seeking to understand their needs and start a conversation about possible UX solutions.
  • I wrote and presented brown bags, open to all, on subjects like Why Taxonomy Matters: Taxonomy and the User Experience, in order to promote understanding of UX and its considerations.
  • I introduced concepts designed to make people think more from the user perspective. For example, like many sites we’re interested in user-generated content (UGC). I expanded this to user-generated experience, or UGX, a concept I’d already developed from previous social media work and user analysis. UGX consists of both user-generated content and user-generated activity (UGA). I began tracking, reporting on, and discussing UGA whenever I mentioned UGC. This simple taxonomic switch (making UGC a subset of UGX, and adding the category of UGA) changed the context dramatically. It led people away from thinking about how to increase bits of stand-alone content, and got them thinking about user activity, which automatically increased awareness of things like user flow and perspective. Eventually key stakeholders and others were talking about UGA as a matter of course, and we even discovered ways to convert some UGA into UGC.

This was successful enough that UX became a standard consideration in not just design, but product strategy. It is of course beyond your control what others do with your information—but you have to provide it!

People understand success. Show your co-workers and management how UX solves their problems. Provide numbers, using performance indicators that matter to your audience. Present before/after case studies. Remember to focus on solutions, not problems (never show a problem for which you don’t have a suggested solution). In short, provide the best possible user experience for your internal customers.

This is from my response to a LinkedIn UX Professionals question, Why they don’t like to spend or invest in the User Experience tasks?

Read More

Posted by on Dec 11, 2009 in design, psychology, strategy, taxonomy

Historicity and UX

Most people, if they had to think about it, would probably define historicity as historical authenticity. Not surprisingly, Philip K. Dick had a different take on the concept. From his alternate history The Man in the High Castle:

She said, “What is historicity?”

“When a thing has history in it. Listen. One of those two Zippo lighters was in Franklin D. Roosevelt’s pocket when he was assassinated. And one wasn’t. One has historicity, a hell of a lot of it. Can you feel it?” He nudged her. “You can’t. You can’t tell which is which. There’s no ‘mystical plasmic presence,’ no ‘aura’ around it.”

“Gee,” the girl said, awed. “Is that really true? That he had one of those on him that day?”

“Sure. And I know which one it is. You see my point. It’s all a big racket; they’re playing it on themselves. I mean, a gun goes through a famous battle, like the Meuse-argonne, and it’s the same as if it hadn’t, unless you know. It’s in here.” He tapped his head. “In the mind, not the gun.”

Dick’s character felt disillusioned by the concept, as if the mental associations a person had with an object were meaningless if not measurable in some external manner. But what humans associate with things is exactly what matters.

historicity example
Click for larger image.

What does this have to do with user experience?

Historicity can be thought of as shared cultural meta-data. It’s a type of mental model, and designers can leverage this virtual meta-data to enrich user experience. I’d like to take Dick’s concept a step further, and think in terms of the personal historicity everyone brings to any given object.

Understanding historicity helps us understand what gives anything relevance; not just an object, but a product, a piece of user-generated content, a site, an app. Examples of personal historicity, brought by a user to a site:

  • A pregnant woman surfing for baby products, also carrying within her associations with a favorite toy, memories of helping her parents with her younger siblings, the kind of stroller she rode in when she was very young.
  • A person reading a news article about a major disaster, a tsunami, remembering a friend who drowned, a moment they were at the beach and felt the tug of a rip tide, even images from an action movie.
  • A person playing Freecell online, remembering the feel of cards when they played the gin and poker with their family, the elasticity of a childish brain at play, recalling the self-validation of their highest score.

In a sense, the associations of personal historicity are the self-created virtual meta-data of your site’s users. Provide a context that unlocks and leverages the virtual taxonomy in their minds. You’re interacting with a person at some point in their personal narrative; help them tell that story. Whatever you are designing, it pays to consider the experience users bring with them to your product, not just the experience you are offering.

Read More

Posted by on Nov 24, 2009 in taxonomy

Lolcat-inspired naming conventions

We all know that consistent, meaningful names are helpful in planning database architecture, but I wanted to bring to your attention this stunning, simple example of good naming convention at work:

funny pictures of cats with captions

Note the two key elements, helpful in developing nearly any taxonomy:

Highly usable mixed case

The mixed case of “Cheetah” makes text more readable. (The bucket was clearly labeled by someone other than the all-caps writer of the “ALL BUCKETS…” command.) No doubt a more detailed name would be in CamelCase, e.g., FelineCheetahKitten. (Any other ex-Pascal programmers out there? You’ll recognize this as Pascal style.) Naturally, naming conventions can vary from CamelCase and still be highly useful—much depends on the needs of the team and application being used.

Please note: if you’re naming web pages or directories, you might want to avoid mixed or CamelCase, as most users type URLs in lower case, and browsers are case sensitive below the domain level.

Meaningful text

The bucket identifies what’s in it simply and clearly, making it easier for others working in this architecture to know what to expect. No one will look for walruses in this bucket!

The goal in choosing a naming convention for your tables, columns, classes, directories, etc., is to make it clear what’s happening. It may be necessary to:

  • Implement a controlled vocabulary, to avoid misunderstandings.
  • Establish reserved words, to avoid confusion. For example, Active Directory reserves terms such as Users, World, Terminal Server, and Null.
  • Disallow specific characters. At my previous employer, HBX Analytics used to become confused by the pipe ( | ) character, so we stopped using it to separate browser title sections at an old workplace.

Whatever you’re working on, it’s good practice to establish a basic naming convention at the outset, readily understandable by current and new team members.

Read More

Posted by on Nov 11, 2009 in design, taxonomy

Evolutional UX

I subscribe to the school of evolutional design. In evolution, species change not to reach for some progressively-closer-to-perfection goal, but in response to each other and their ever-changing environment. My user experience must do likewise.

Rather than reach for pixel-perfect, which is relatively unattainable outside of print, (and is probably only “perfect” to myself and possibly my client), I reach for what’s best for my users, which is in the interests of my client. I expect that “best” to change as my users change, and as my client’s services/products change. This approach makes it much easier to design for UX.

Part of evolutional design is stepping away from the graceful degradation concept. The goal is not degraded experience, however graceful, but differently adapted experience. In other words, it’s not necessary that one version of a design be best. Two or three versions can be equally good, so long as the experience is valuable. Think of the differences simply resizing a window can have on well-planned liquid design, without hurting usability. Are the different sizes bad? Of course not.

This approach strongly supports behavioral design, in which design focuses on the behavior and environment of the user. You might be designing for mobile, or a laptop, or video, or an e-newsletter; you might be designing for people being enticed to cross a pay wall, or people who have already paid and are enjoying your service. You might be appealing to different demographics in different contexts. Evolutional UX thinks in terms of adaptation within the digital (and occasionally analog) ecology.

Evolutional UX also reminds the designer that she herself is part of an evolving class of worker, with many species appearing and adapting and mutating and occasionally dying out. We must adapt, or fall out of the game—and the best way to do that is to design for your ever-changing audience and their ever-changing tools.

And now, some words of wisdom from that foremost evolutional ecologist, Dr. Seuss. Just replace the “nitch” spelling with “niche” and you’ve got sound ecological theory, as every hermit crab knows.

And NUH is the letter I use to spell Nutches,
Who live in small caves, known as Nitches, for hutches.
These Nutches have troubles, the biggest of which is
The fact there are many more Nutches than Nitches.
Each Nutch in a Nitch knows that some other Nutch
Would like to move into his Nitch very much.
So each Nutch in a Nitch has to watch that small Nitch
Or Nutches who haven’t got Nitches will snitch.

Read More

Posted by on Aug 9, 2009 in taxonomy

Shakespeare on taxonomy

Shakespeare, discussing the value of a certain level of granularity in taxonomy design. From Macbeth:

1st Murderer: We are men, my lord.

Macbeth: Aye, in the catalogue ye go for men; as hounds, and greyhounds, mongrels, spaniels, curs, shoughs, water-rugs, and demi-wolves are clept all by the name of dogs: the valued file distinguishes the swift, the slow, the subtle, the housekeeper, the hunter, every one according to the gift which bounteous nature hath in him clos’d; whereby he does receive particular addition, from the bill that writes them all alike: and so of men.

An occasional challenge in designing a taxonomy, whether for back-end architecture, user permissions, catalog searchability, or any complex schema, is deciding how much detail to track. Too little, and like Macbeth, you find yourself unable to distinguish the good from the bad, the useful from the unwanted. Too much, and the relevant is hidden by the irrelevant, discouraging users.

How to know what to do? Like everything else, start with the user.

user-driven granularity

One of the simplest means of determining granularity is to leave it up to the user. There are several approaches, any or all of which can be helpful.

  • Conduct an audit of search terms, internal and external. Navigation flow should also be compared to path analysis. Observing how users look for information provides valuable insight into their internal categorization. The user’s mental model probably operates as an ideal level of relevant granularity.
  • Grant users the freedom to develop their own folksonomy via tagging. Many content management systems allow this with minimal effort. For large-scale enterprise endeavors, platforms such as Endeca can meet a broad variety of producer-driven and user-driven needs. User-generated metadata (UGM) is typically highly relevant.
  • If possible, perform concept testing. As always, design to test for purpose (as opposed to stimulus-response testing), and give the users every opportunity to do instead of say. Good techniques include structured brainstorming and user-driven card sorts. Insight into the user’s categories is your goal.

standards-driven granularity

User-driven research is not much help when you’re developing a taxonomy from the ground up, with a built-in need for shared elements, and no opportunity for user research. So, turn to those who have already solved the problem for their own users.

  • Is there an industry standard? Sometimes it’s simple. Library databases, for example, have a specific minimum of elements all items must be cataloged against, as well as optional metadata. If your product has an established standard taxonomy, chances are your users will expect it and you should incorporate it. This is not a recommendation of slavish adherence to tradition—rather, tradition can be a springboard for you, and a clue into the level of granularity your product will require.
  • If there is no industry standard, look to information management for inspiration. For example, the Dublin Core Element Set provides a highly useful metadata minimum standard.

refining granularity

Once you’ve fleshed out a basic schema, testing and observation will help refine it to the appropriate level of granularity. Don’t fit it all into one menu. Too much detail, and users will be overwhelmed by the options and abandon your site.

Instead, parcel out information into appropriate locations:

  • A global navigation for key areas, common to the entire site.
  • Anchor links within a section or page.
  • A search interface. There are advantages to offering different approaches. A simple search box can reveal interests you didn’t know your users had, and allow you to prompt them with recommended results for expected keywords. An advanced system (such as that used in a library, or a periodical) can be a good way of introducing your user to leverage key metadata. If your audience consists of expert users (researchers, for example), this could be ideal approach. You will definitely want to conduct research to optimize this search approach. And a faceted search can allow them to easily filter their options. This, paired with a simple text box search, meets most needs.
  • Tagging.
    This allows depth of granularity within the appropriate context, so that unlike Macbeth, your users can find exactly what they need, when they need it.
Read More