UX

The Cognitive Costs of Bad UX

| Jorge Arango

Mark Wilson, writing in Fast Company:

According to a new research paper published by the analyst firm Forrester—for which researchers interviewed nearly 200 design teams and dozens of frontline workers in fields like retail—the enterprise software we use at work is slowing us down, and for all sorts of reasons, from individual components of the UI to the workflows that take us from one piece of software to another.

We connected with Andrew Hogan, Forrester’s principal analyst specializing in design, who led the research. He points out some of the biggest problems he sees in these tools and offers critical insight on how some companies are fixing enterprise UX.

Hogan discusses several issues with enterprise software, including slowness, unclear workflows, and — my favorite — bad labels. The article also covers some reasons why enterprise software tends to suck.

Continue reading →

Discoverability in the Age of Touchscreens

| Jorge Arango

When I was first getting started with computers, in the late 1970s, user interfaces looked like this:

Visicalc, the first spreadsheet program, required users to learn commands. Image: Wikipedia (https://en.wikipedia.org/wiki/VisiCalc)
Visicalc, the first spreadsheet program, required users to learn commands. Image: Wikipedia

Getting the computer to do anything required learning arcane incantations and typing them into a command line. While some — such as LOAD and LIST — were common English words, others weren’t. Moving to a new computer often meant learning new sets of incantations.

As with all software, operating systems and applications based on command line interfaces implement conceptual models. However, these conceptual models are not obvious; the user must learn them either by trial and error — entering arbitrary (and potentially destructive) commands — or reading the manual. (An activity so despised it’s acquired a vulgar acronym: RTFM.) Studying manuals is time-consuming, cognitively taxing, and somewhat scary. This held back the potential of computers for a long time.

Continue reading →

Platforms and Environments

| Jorge Arango

Last week I had an interesting conversation with a product management researcher. I told him why I think “product” is the wrong framing for many digital things and we discussed the concept of information environments. He asked a good question: Why call them environments instead of platforms? After all, “platform” is a well-understood concept in the context of UX design.

While the two terms share a similar intent (getting designers and stakeholders to think more systemically about the work to be done), there is an important difference between them: “platform” implies a technology-centric view of the system while “environment” implies a people-centric view. A platform is something you build upon. An environment is where you have experiences. This is a key distinction as we move to make user-centered design more systemically aware.

I realize the word “environment” brings with it connotations that may court controversy. This is not unintentional. We exist within environments. They host our activities. Our long-term survival hinges on the viability of our environments. It behooves us to develop an attitude of responsible stewardship towards them — whether they are made of stuff or of information.

The Object of Experience Design

| Jorge Arango

The object of music is a sequence of sound tones and pauses that stirs feelings in us.

The object of industrial design is a composition of materials that is useful and mass-reproducible.

The object of architecture is a relationship between spaces and forms that gives us shelter and the ability to perform certain functions.

The object of graphic design is a semiotic composition that moves us to action.

What is the object of experience design?

People, Not Users

| Jorge Arango

Visitors
Guests
Customers
Patients
Students
Readers
Moms
Listeners
Watchers
Job-seekers
Fans
Passengers

Nobody comes to your information environment with the goal of “using” anything. They come because they want to buy an airline ticket, or transfer money from one account to another, or understand their medical bill.

The more specific you can be when referring to the people who will use the things you design, the easier it’ll be for you to empathize with them.

Consistency and Coherence

| Jorge Arango

I’ve heard designers use these words as though they’re interchangeable. They’re not.

Consistency (n): 1) conformity in the application of something, typically that which is necessary for the sake of logic, accuracy, or fairness, 2) the way in which a substance, typically a liquid, holds together; thickness or viscosity

Coherence (n): 1) the quality of being logical and consistent, 2) the quality of forming a unified whole

Consistency can create coherence. But thoughtless, overly rigid consistency can create incoherence. For people to successfully derive meaning from an information environment, the environment must be coherent above all — even if that calls for some inconsistency.

Aim for coherence.

(Definitions from the macOS Dictionary app.)

How to Design New Information Environments That Don’t Suck

| Jorge Arango

In systems design there is a rule of thumb known as Gall’s law. It states:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
— John Gall

Information environments (websites, apps, etc.) are systems, so this law applies. (I’ve seen it in action.) We acknowledge this when we talk about starting with a minimum viable product (MVP).

One of the main challenges teams face in such projects is arriving at agreement at what constitutes the “minimal” feature set. Designers can — and should — help teams clarify the product vision upfront. This helps make the process less painful.

Once a clear vision is agreed upon, the designer’s role shifts to defender of the vision. This is necessary because there will always be forces pulling things away from the minimal feature set — often for valid reasons.

When the product is real and can be tested, it can (and should) evolve towards something more complex. But baking complexity into the first release is a costly mistake. (Note I didn’t say it “can be”. It’s guaranteed.)

So:

  1. Clarify vision,
  2. define minimal,
  3. defend minimal,
  4. launch,
  5. evolve.

3 Placemaking Lessons From the Magic Kingdom

| Jorge Arango

If you design software, you need to know about placemaking. Why? Because the websites and apps you design will create the contexts in which people shop, bank, learn, gossip with their friends, store their photos, etc. While people will experience these things primarily through screens in phones, tablets, and computers, they actually perceive them as places they go to to do particular things.

Your users need to be able to make sense of these information environments so they can get around in them and find and do the things they came for, just as they do with physical environments such as towns and buildings. People need to form accurate mental models of these environments if they are to use them skillfully.

As a discipline, software user interface design has only been around for about sixty years. However, we’ve been designing places for much longer. There’s much we can learn from architecture and urban design to help us create more effective apps and websites. This article is a short case study in the design of a particular physical environment that has valuable lessons for those of us who design information environments: Disneyland.

Continue reading →

Leaving Our Mark

| Jorge Arango

This post is based on a speech I wrote for two back-to-back keynotes delivered in November 2016 at Interaction South America (Santiago, Chile) and the Italian IA Summit (Rome). The U.S. election was decided on the eve before I flew to Rome.

When architects tour Rome, one of the things they learn is that buildings can last a long time. When I was younger, I had the privilege of studying architecture for two semesters in the city, and one building stood out for me: the Basilica of San Clemente al Laterano, a beautiful church built during the middle ages. I was struck by the fact that the basilica had been built on top of an earlier building: a 4th century church which you can visit by descending to a basement under the main structure. That church, in turn, was also built atop an earlier building which was used by followers of the cult of Mithra, and which you can also visit today. The Basilica of San Clemente has been used as a place of worship for almost twenty centuries. When you visit it, you have a tangible experience of the evolution of Western spiritual practice over that span of time.

Buildings serve more than mere utilitarian purposes, such as keeping us dry from the rain or giving us a safe place to rest. They’re also physical manifestations of the political, social, and cultural environments that produced them. Buildings tell stories about who we are — and who we were — as a people. As an architect, I often think about the longevity and cultural import of buildings and how it contrasts with what I currently design: software. If buildings are among our longest-lived cultural artifacts, apps and websites are among our most ephemeral. Software is changing all the time, sometimes in big ways. For example, iOS 7 introduced a completely new visual design to the iPhone’s operating system. From one day to the next, the feeling of the entire information environment changed. Perfectly functional applications that didn’t immediately implement the new style suddenly looked old and out-of-place. This change was experienced by millions of people, literally overnight.

Continue reading →