Jim Nielsen’s Blog
Preferences
Theme: This feature requires JavaScript as well as the default site fidelity (see below).
Fidelity:

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Text as UI

Years ago, Cameron Moll wrote a post describing what separates good design from great design. One of the things he talked about, which has stuck with me through the years, is the idea of treating text as UI. This is most aptly described by an image Moll used in his presentation:

Text as content and text as UI from Cameron Moll

When desinging applications, which primarily exist to present sets of dynamic information, presenting text as UI (instead of merely content) aids users because it sets up expectations around information intpretation: “these things are important, these less-so”. You can leverage design principles like sizing, color, and white space to provide an interpretation of the text. This simplifies the cognitive overhead for the user because the interface is providing an interpretation on the text, like what information is important and what information is related.

A Real-world Example

When I started at Insight, one of the first design problems I solved was accomplished by treating text as UI (and not just as content). Let me frame the problem I was given.

Before I arrived, a new feature was developed that gave users the ability to search the system for any item they needed.

Old search UI

Users reported the following problems with this interface:

  1. Functionally the dropdown was a suggestion of key results based on user input (along with a few other factors). However, users didn’t appear to realize that the search dropdown was merely a suggestion of results. They thought it was the “full” list of results.
  2. The search results being returned were comprised of two primary types: quotes and policies. It was important to users that they be able to differentiate between the two types, but the textual results did not make that clear.

Based on this feedback, I took the exisiting UI and came up with this new design:

New search UI

Here’s a quick overview on the reasoning behind my design choices:

New search UI with description

The original iteration of this UI treated text as content: the search results were merely bits of information concatenated into strings of text. My new design did not even require changes to the server. Instead, I treated the content being returned from the server as textual UI rather than textual content. This provided an interpretation of information that more clearly aligned with users’ mental model of the data they were interacting with. It made the information more parseable, understandable, and functional.

Here’s a comparison between the old and the new UI:

Comparison between old and new UI