The UX of Data

The UX of Data

In my previous UX Magazine article, The Coming Zombie Apocalypse, I discussed how small, Web-connected devices are overturning our old-school assumptions about devices and applications. It was a general introduction to the trend, and I'd like to drill deeper in this article by focusing on a core building block of this new order: the ability to store user data in "the cloud."

I assume most readers are familiar with the concept of cloud computing, but it's a very broad concept encompassing a wide range of technologies. This article will focus on a core aspect, the storage of a users' data outside of their personal devices. This is a very disruptive shift that enables user experiences that would be impossible with only local storage, and creates a new facet of design: the UX of data.

Breaking Down "User Experience"

How can something as basic as data actually have a user experience? At first glance, it seems rather silly. Part of the problem is in how we understand the term "user experience." In the book The Simplicity Shift, I wrote about how the term "user experience" is too imprecise. It can be used to describe everything from deep technology trends down to the aesthetic of an icon's design. When people ask for a "simple UX," there are too many ways this can be interpreted.

I suggest that we understand user experience as comprising three broad levels: the presentation, task, and infrastructure layers.

The presentation layer

The presentation layer is the visual/graphic layer—how the application looks, the choice of color schemes, use of whitespace, and the visual design language.

The task layer

The task layer is about actions and user models, how the application operates and flows. What are the core concepts the user must understand in order to use the product? A classic example is the difference between the DOS C:\ prompt and the Macintosh Finder. Both manipulate files but they have vastly different task layers: remember and type, versus click and drag.

The infrastructure layer

The infrastructure layer is the base technology the product it built upon. Is it battery powered or plugged into the wall? Does it use Bluetooth or Wi-Fi? Does the low-level network code return detailed error conditions or just a single, cryptic failure? While these may seem like "just technology issues," the point is that these choices enable or, just as likely, hinder what is possible in the UX. For example, if a portable product has only a ten-minute battery life, no amount of task layer interaction or pretty presentation layer graphics is going to keep the customer from being frustrated.

Data Is Infrastructure

There's lot to discuss about these three layers and their roles in the communication of design. However, the key insight from this three-layer model is that the most profound impacts on the UX usually come from innovations in the infrastructure layer.

This has been true throughout history as a new disruptive change in technology goes through a predictable set of stages: innovation, execution, and acceptance. Carlotta Perez writes about this in her book, Technological Revolutions and Financial Capital. She shows that it takes time for any new technology to be understood, accepted, and then actively experimented with to find out what it's ultimately capable of achieving. She documents how this is a sociological phenomenon as much as a technical one. Just because something is possible doesn't mean it is widespread, and it certainly doesn't mean that people are willing to use it.

We are in the middle of this social change. Cloud data has been around for quite a bit but we are still tinkering around the edge, not really understanding and accepting what it has to offer. It order to talk about a UX of data, we need to first understand that data storage, cloud-based or otherwise, is an fundamental part of the infrastructure layer, and we need a more robust vocabulary to describe how it impacts UX design. The move from file data to cloud data unlocks UX possibilities that need to be discussed in more detail.

From File to Cloud

Historically, data was typically stored locally using proprietary formats. This was a profoundly isolating, inefficient approach that required users to store, organize, name, back up, and even manage version control all on their own. Data was so siloed, in fact, that discussing broader issues such as collaborative editing was a bit like the two-dimensional characters in Flatland talking about the three-dimensional spheres. For example, if in the 1990's if you wanted to create that collaborative word processing application it would involve writing custom server software, using proprietary formats and protocols, and almost certainly only working on a local network. It was tried by a few companies, of course, but for the most part it was a fool's errand. The infrastructure challenges were so great that acceptable UX wasn't even practical.

One of the first major applications to break out of local storage and move to cloud storage was the Web-based email service Hotmail. By liberating email data from a single device, it enabled an entirely new usage model. This is when the UX of data started to grow.

The move from locally based data to cloud-based data enables many deep new advantages in products.

Advantage 1: Device independence

This is the obvious and initial win of cloud based storage. You could now use nearly any computing device to access all of your data. This initially appealed to people who travelled frequently, but the value became even clearer once device prices fell and many people routinely started using multiple computers and smart mobile devices. All of these devices could now access and read the same data, even simultaneously. Unfortunately, this is where most people stop, thinking this is the only significant advantage of cloud data.

Advantage 2: State as data

But what we think of as "data" needs a bit more exploration. For example, with email it's tempting to think of the data as just the headers and body of each email. But if I have my email inbox open in two browser windows, as I read unread messages in the first window, they also becomes marked as read in the other window. Thus, data pertaining to the read/unread state of my inbox is synchronized as well.

This is a fairly subtle point, but a deep one. This meta information about the email is just as much data as the headers and body, and the way this meta information is displayed, changed, and propagated between screens is a critical part of the user's experience. We need to move from thinking of data as old-school bits in a file to understanding that dynamic display states that need to be shown, manipulated, and updated are important data and experiences unto themselves.

Another example comes from two somewhat related music products, Pandora and Sonos. Pandora is an application that streams music to devices: TVs, phones, laptops. Sonos plays music much the same way as Pandora, but to a distributed set of speakers throughout the home.

These two products have vastly different concepts of state. Pandora treats state as a client-side attribute so I can have three Pandora devices in my home each playing different music independently. They are effectively islands from each other. Sonos, on the other had, puts the music state fully into the cloud, so each client controls a single play state for my house. If I pause my music on client 1, and can resume it on client 2.

Neither one is better; they are just different UX approaches. I'd argue that the Sonos model is more sophisticated and shows how state, not just data, is becoming a core aspect of UX design.

Advantage 3: Sharing with people

When data is in the cloud, sharing becomes much easier. This is, of course, trivially obvious when it comes to such things as blogs or a YouTube video. But that collaborative word processing application I discussed earlier, which was nearly impossible in the 1990s, is now being done by many companies. This new product type has been enabled by a new form a data.

In fact, the ability to share data so easily has left people drowning in an excess of shared media, such as email, wiki pages, Google docs, online todo lists, and other cloud-based data. Companies (Asana, for example) are even being built around the UX of data, finding new, creative ways to share and link data to make it easier to associate, organize, and browse.

Advantage 4: Sharing with computers

Once you have the ability to share your data with other people, it's just a short jump to share that data with computers. For example, Evernote is a product that allows you to capture information such as text, photos, and web pages and store them all up in the cloud. Evernote is a clear example of the advantages of device independence and sharing with friends, as every device now has access to the same data, and it can be easily shared with friends.

But Evernote adds a clever new twist: data is also shared and processed by their computers. Evernote takes photos and automatically scans them for any text that may appear in the photo, and then attaches the text to the photo as keywords. This allows you to search for "STOP" to find all uploaded photos of stop signs.

Sharing data with computers lets them modify and augment the data, effectively making the data improve over time. Evernote just adds tags, but you can imagine all sorts of other services, from face recognition, to sorting, to related searches, all processing and enhancing your data with little effort on your part.

Advantage 5: Devices as data generators

The next logical step is to move past sharing and have computers, or more likely small devices, actually create the data for you. New products like the Spot, which plots your GPS location onto an ever-updating map, is a simple example of this. The user is responsible for creating a shared map, such as one for a four-day hike in Yosemite Park. The user's role is to create a purpose for the map and to put in key, high-value locations such as start and stop points. A Spot device is then tasked with taking care of the fairly mundane task of plotting the user's location in great detail whenever turned on.

This active data model allows users to delegate. Users take care of the big picture aspects of the data, and an array of devices collects lower-level raw data that that fills out the picture and adds precision. We've moved from a model where users create all of the data to one where the data is co-produced with a collection of devices.

Note that what enables this is that the data model, in addition to being shared, allows write access to other devices. This data model is encouraging new product concepts that were practically impossible a decade ago.

Conclusion

Too often "the cloud" is discussed only in terms of the technologies used to engineer it. When discussing its impact on UX, most people can only name device independence. This article has discussed how just data storage in the cloud is a deeply enabling shift and listed four additional advantages, and there are certainly more to come. But we need to stop talking only in terms of technology; there is a UX of data, we are only now beginning to discover what it can do. Our first step is to appreciate how important it is and then to break free of our file-based thinking of what data is, and how it should behave.

ABOUT THE AUTHOR(S)

Scott Jenson was the first member of the User Interface group at Apple in the late 80s, working on System 7, the Apple Human Interface guidelines and the Newton. After that, he was a freelance design consultant for many years, then director of product design for Symbian, and finally managed the mobile UX group at Google.

Add new comment

Login via:

Your name *

E-mail *

The content of this field is kept private and will not be shown publicly.

Comment *

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as click-able links.

Comments

March 9, 2011

Not to be too general, but it seems there's a split between those capabilities afforded by cloud data that can be described as descriptive (declaration of a "read" vs. "unread" state, for example), and those that anticipate intent (passive scanning of photos for embeded characters). The former are wonderful but later often run amuk.

Anticipating user intent may ultimately rob us of our freedom of action especially the freedom to be creative in our actions.

Though the model is a bit schematic for something so human as experience, I do agree with UX as "presentation, task, and infrastructure layers." And the UX of data is too often overlooked, surprisingly, even as "AJAX" has become expected.

State as data is very interesting as well. I think it needs more exploration. Perhaps in a sense the network is beginning take on life-like attributes, or at least as we experience it, as a flow of states. The challenge for designers now, it seems, is to make data flows and the states they--hopefully--present, more apparent, apprehensive, and discernible, thus manageable by "users" (people).

Only qualm is with UX as describing the "aesthetic of an icon's design". Um, no. Even you appropriately linked to a definition of visual design: http://uxmag.com/archive/visual-design which is merely one facet of UX, among many, including "data", and database architecture too. The UX of Database Design. Now that would be an interesting book, wouldn't it?

This is all about data availability through new devices and better connectivity. It's also about thinking about data differently, exposing it in ways that allow it to be consumed by applications you haven't thought of yet.

"The storage of users' data outside of their personal devices," as described here, is really just the old client-server model. Hotmail did not "move to the cloud," they just kept your mail on their servers. The paradigm shift they were a part of was moving application interfaces to the Web. This meant your mail was available from anywhere on the Web, which was so important and novel that people started emailing themselves their own documents just to have them permanently and globally available.

Cloud computing has to do with application-agnostic infrastructure. A variety of distributed applications share common resources like processors, memory, storage, and bandwidth, and can be scaled independently and dynamically to use more or less of those resources according to demand. It can mean other, related things to different people, but I don't think any of your examples have to do with any sense of cloud computing. I'm not really sure what cloud data would mean.

One thing that's new about many of these examples is their distributed nature. Distributed applications aren't new, but certainly the range of devices and domains has expanded - distributed applications mean something new when they're also in your pocket. To the extent that data, including UI state, is synchronized across devices and servers, and that those devices and servers all present similar user interfaces, the UI itself feels distributed, and that's interesting.

Good insight, especially Advantage 5. Development here should facilitate urban navigation also. Given start and end locations, a user should be able to find a fast route, short route, route with a coffee shop, etc. Here's my view of what it might look like on a college campus: http://ow.ly/41Q23