Mar 23

Practical CSS Grid: Adding Grid to an Existing Design

Source: A List Apart

Understanding and using CSS Grid is easier than you might expect. The day Grid support shipped in Firefox 52, I decided on the spur of the moment to convert the basic layout of my personal site to use Grid. And it was a fairly simple process—five minutes to write the grid styles, then 15-20 spent troubleshooting

Grid allows us to literally define column and row grid lines, and then attach elements to those lines in any order we choose. That may sound like tables, but Grid is so much more than tables ever dreamed.  It means more responsive layouts, far more accessible documents, and far cleaner markup than even floats and positioning ever afforded us.

It’s been decades since CSS first emerged, but it’s never contained a system anything like this. And Grid is already supported in both Chrome and Firefox, with Safari coming soon (its Technology Preview releases support Grid as of this writing). A new era in digital design is dawning right now.

The way things used to be

Before we get to the Grid, allow me to take just a moment to explain the markup structure of meyerweb’s main pages, and the positioning-and-margins approach I’ve been using for, um, about 12 years now. Here’s how the markup is structured:


<body>
   <div id="sitemast">…</div>
   <div id="search">…</div>
   <div id="main">…</div>
   <div id="extra">…</div>
   <div id="navigate">…</div>
   <div id="footer">…</div>
</body>

Some of those IDs are idiosyncratic holdovers from my early-2000s view of layout and naming conventions. #extra, for example, is what most of us would call #sidebar. #sitemast stands in for #masthead. And #footer is from the days before the actual <footer> element

The divs (which should probably be sections these days, but never mind that now) are arranged the way they are so that if the CSS fails to load, or a speaking browser is used to browse the site, then the site’s masthead is first, the ability to search the site is second, and the main content of the page is third. After that, extra materials, site navigation, and the footer follow.

All of these were stitched together into a layout by absolutely positioning the navigate and search divs. The sitemast was set to be 192px tall, and both the navigate and search divs were given top: 192px; to show up just below it. In order to leave space for them to land, top margins were applied to the main and extra divs. (Fig. 1)

Screenshot of web page
Fig. 1: meyerweb’s home page (foreshortened)
 

Constructing the grid

So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort.

Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication. And then, March 7th, 2017, it shipped to the public in Firefox 52. I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass. After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout. It took me less than five minutes to come up with the following:


body {
   display: grid;
   grid-template-rows: 192px min-content min-content 1fr;
   grid-template-columns: 1fr 20em;
}

#sitemast {
   grid-row: 1; 
   grid-column: 1 / span 2;
}

#search {
   grid-row: 2; 
   grid-column: 2;
}

#main {
   grid-row: 3; 
   grid-column: 1;
}

#extra  {
   grid-row: 3; 
   grid-column: 2;
}

#navigate {
   grid-row: 2; 
   grid-column: 1;
}

#footer {
   grid-row: 4; 
   grid-column: 1;
}

That’s not all I had to do, but it’s the core. Let me break it down for you.


body {
   display: grid;
   grid-template-rows: 192px min-content min-content 1fr;
   grid-template-columns: 1fr 20em;
}

This part of the CSS sets the body element to be a grid container and sets up the grid lines. When you make an element a grid container, all of its children become grid items. (If you’ve worked with flexbox, then this pattern will be familiar to you.) So with that display: grid, I turned all of the child divs into grid items.

Next come the rows in the grid. The values in grid-template-rows actually define separation distances between grid lines (the same is true of grid-template-columns, which we’ll get to in a moment). So the value 192px min-content min-content 1fr; means: “Go 192 pixels down from the top of the grid container and drop a grid line. Then drop another two such that they provide enough vertical space for the contents of the rows they define. Finally, leave one fr (fraction) of distance between the third grid line and the bottom of the grid container.” (Fig. 2)

Screenshot of web page
Fig. 2: Defining the rows
 

The value min-content is pretty cool. It means just what it says: “Take up the minimum amount of space needed to fit the contents.” So for the second row, the one that will contain the navigation bar and search field, it will be as tall as the taller of the two, and no taller.

Ditto for the third row, the one containing the main and extra divs. On the homepage, the main div will be taller. On subpages, that might not always be the case. In all circumstances, the row containing those two divs will always be tall enough to contain them both.

With the rows figured out, next come the columns. I decided to keep things simple and just set up two. If you look at meyerweb’s home page, it appears to have three columns, but that’s only true of blog posts—a substantial but minority part of the site—and the left-side “column” is more of a sidebar inside the main column.

In the original design, the sidebar (#extra) is 18em wide, with some extra space to keep it away from the main column. But the column also has to fit the search box, which is a bit wider. After some experimentation, I settled on a width of 20em. The rest was left to flex as 1fr. (Fig. 3)

Screenshot of web page
Fig. 3: Defining the columns
 

Now that I’ve used the fr unit twice, a few words of explanation are in order. fr stands for “fraction,” and means “a fraction of the available unconstrained space.” In this grid, there are two columns. One of them has an explicit width of 20em, which is thus constrained—there’s no room for flexibility. The rest of the column space is unconstrained—as the width of the grid container changes (say, due to changes of the browser window) the unconstrained space will change to be the container’s width minus the 20em of constrained space.

Imagine for a moment I’d decided to split the grid into four columns, with the rightmost being 20em wide and the rest being equal, flexible widths. That would have looked like:

grid-template-columns: 1fr 1fr 1fr 20em;

Alternatively, I could have written it as:

grid-template-columns: repeat(3, 1fr) 20em;

In any event, that would have caused the unconstrained space to be divided equally among the first three columns. If the grid container were 65em wide, the last column would be 20em wide, and the other three 15em each. (3 x 15 = 45; 45 + 20 = 65.) Shrink the grid container down 50em wide, and the first three columns would shrink to 10em each.

In my case, I wanted that first column to take all of the space not given to the constrained last column, so it got 1fr. The final result is shown in Fig. 4.

Screenshot of web page
Fig. 4: The complete grid
 

Placing the items

With the grid lines set up, now it’s just a matter of attaching grid items to the grid lines. This can be done automatically, using the grid-flow algorithm, but this is a case where I want to place each item in a specific place. That leads to the following:


#sitemast {
   grid-row: 1; 
   grid-column: 1 / span 2;
}

#search {
   grid-row: 2; 
   grid-column: 2;
}

#main {
   grid-row: 3; 
   grid-column: 1;
}

#extra {
   grid-row: 3; 
   grid-column: 2;
}

#navigate {
   grid-row: 2; 
   grid-column: 1;
}

#footer {
   grid-row: 4; 
   grid-column: 1;
}

For each of the six divs, I simply said, “Pin your top edge to this row line, and your left edge to this column line.” I used line numbers because that’s all I gave myself—it’s possible to assign names to grid lines, but I didn’t. (But stay tuned for an example of this, later in the article!)

So, to pick one example, I set up the #main portion to start on the third row line and the first column line. That means it will, by default, fill out the space from the first to second column lines, and from the third to fourth row lines.

Almost all of the divs were set up in this way. The exception in this case is the #sitemast. It starts at the first column and row lines, but since I wanted it to go all the way across the grid, I set its column value to 1 / span 2. That means “Start at column line 1, and span across two columns.” I could have gotten the same result with the value 1 / 3, which means “Go from column line 1 to column line 3.” (Fig. 5)

Screenshot of web page
Fig. 5: The grid items’ placement
 

But realize: that’s just a diagram, not the actual layout situation. Not yet, at any rate.
Something I want to be clear about here is that while you can explicitly assign all of your grid items to specific rows and columns, you don’t have to do so. Grid has a flow model that allows grid items to be automatically assigned to the next open grid cell, depending on the flow direction. In my case, I could have gotten away with literally just these rules:


#sitemast {
   grid-column: 1 / span 2;
}

#navigate {
   grid-row: 2; 
   grid-column: 1;
}

That would have ensured the masthead was two columns wide, and that the search and navigation divs were placed in the exact grid cells I wanted. That would have left the second row filled by navigation and search, and the rest of the grid cells open.

Given that, the unassigned items would be flowed into the grid in source order. The masthead (#sitemast) would be placed in the first two-column row it could find, which turns out to be the first row. The search div would flow into the next open cell, which is row 2, column 2, because row 2, column 1 is already occupied by the navigation div. After that, the main div would flow into the first open cell: row 3, column 1. Extra would go into the next cell: row 3, column 2. And then the footer would be placed into row 4, column 1.

The end result would be exactly what’s shown in Fig. 5. The difference would be that if I had a special page where another div was added, it could throw off the whole layout, depending on where it appeared in the HTML. By explicitly assigning my layout pieces to the places I want them, I prevent a stray element from upending everything.

Given the styles I wrote, if a child element of the body is added to a page, it will become a grid item. If I don’t give it an explicit place in the grid, it will end up flowed into the first available grid cell. Since the lower-right cell (row 4, column 2) is unoccupied, that’s where the extra element would be placed…assuming it isn’t set to span two columns. In that case, it would end up at the bottom of the grid, in an automatically-created fifth row.

Accommodating the past

It’s easy enough to set up a grid, but when you drop grid items into it, they bring all of their existing styles in with them. That might not be a big deal in some cases, but in mine, it meant all of the margins and padding I’d used to keep the layout pieces apart from each other were now messing with the placement of the grid items. You can see this in Fig. 6, created using a local copy of the site.

Screenshot of web page
Fig. 6: Grid + legacy = yoinks
 

Ouch. It was time to override the pieces of the legacy layout styles I didn’t need in Grid, but did need to keep for browsers that don’t yet understand Grid.

So I wrapped the whole bit in an @supports block. Since I wanted to constrain the grid layout to wider displays, I put an @media block just inside @supports, and then proceeded to zero out or otherwise change the various margins and padding I didn’t need in a Grid context. Here’s how it turned out:


@supports (display: grid) {
   @media (min-width: 60.001em) {
      body {
         display: grid;
         grid-template-rows: 192px min-content min-content 1fr;
         grid-template-columns: 1fr 20em;
      }

      #sitemast {
         grid-row: 1; 
         grid-column: 1 / span 2;
      }

      #search {
         grid-row: 2; 
         grid-column: 2;
         position: static; 
         padding: 0.25em 0 1em;
      }

      #main {
         grid-row: 3; 
         grid-column: 1;
         margin-right: 0; 
         margin-top: 1.25em;
         padding-top: 0;
      }
   
      .hpg #main {
         margin-top: 0; 
         padding-top: 0;
      }

      #extra {
         grid-row: 3; 
         grid-column: 2;
         position: static; 
         top: 0;
         margin-top: 0;
         padding-top: 0.5em; 
         margin-left: auto;
      }

      #navigate {
         grid-row: 2; 
         grid-column: 1;
         position: static; 
         margin-top: 1px; 
         padding-bottom: 0;
      }

      #footer {
         grid-row: 4; 
         grid-column: 1;
         margin-right: 0;
      }
   }
}

I probably could refactor that to be more efficient, but for now, I’m going to leave it as-is. It makes clear what had to be done to which grid item—which ones needed to override position so their absolute positioning didn’t interact weirdly with the grid, which margins and padding needed to be changed, and so on. Let’s look at the end result (Fig. 7).

Screenshot of web page
Fig. 7: Grid + @supports = yowza!
 

You might be forgiven for thinking that this was much ado about not very much. Why go to all that effort just to make it look the same? The real power here, in what is admittedly a simple case, is how I no longer have to worry about overlap. The footer will always be below the main and extra divs, no matter which is taller. When I was using positioning, that was never guaranteed.

Similarly, the navigation and search will always maintain a shared height, making sure neither will overlap with the content below them—and thanks to min-content, I don’t have to guess at how tall they might get. Grid just handles all that for me.

And remember, the layout still functions in old browsers just as it always did, using positioning. I didn’t “break” the site for browsers that don’t understand Grid. The more capable Grid layout is there, waiting for browsers like Chrome and Firefox that understand it.

If you want to see all this live for yourself, head over to meyerweb.com and inspect elements in Firefox 52 or later. There you’ll see a little waffle icon next to the display: grid declaration on the body element. Click it, and Firefox will draw the grid lines on the page for you to scrutinize. (You can also enable a more powerful layout tool in Nightly builds of Firefox; see my post “ Grid Inspection ” for details.)

Naming conventions

I mentioned earlier that it’s possible to name grid lines. I didn’t do it for my own styles because the grid I defined was so simple, but for more complicated grids, naming the lines might be useful.

Using the stripped-down version of the styles, the one without all the legacy overrides, naming the grid lines would look something like this:


body {
   display: grid;
   grid-template-rows: [masthead] 192px [navsearch] min-content [mainextra] min-content [footer] 1fr;
   grid-template-columns: [left] 1fr [middle] 20em [right];
}

Each of those square-bracketed words is assigned as a name to the corresponding grid line. (Fig. 8)

Screenshot of web page
Fig. 8: Named grid lines
 

Once those names are defined, you can refer to them in your grid-row and grid-column properties. For example:


#sitemast {
   grid-row: masthead; 
   grid-column: left / span right;
}

#search {
   grid-row: navsearch; 
   grid-column: middle;
}

#main {
   grid-row: mainextra; 
   grid-column: left;
}

#extra  {
   grid-row: mainextra; 
   grid-column: middle;
}

#navigate {
   grid-row: navsearch; 
   grid-column: left;
}

#footer {
   grid-row: footer; 
   grid-column: left;
}

Much like class names, you can assign multiple names to a grid line by supplying a space-separated list. Try this one for size:

grid-template-columns: [start left] 1fr [middle sidebar] 20em [right end];

You can then refer to any one of those names in your grid-column declaration. There’s no defined limit on the number of names, but remember what comes with great power.

In case you were wondering, you can mix grid line names and numbers, so something like grid-row: navsearch; grid-column: 2;} is completely fine. You can use any name the browser can parse, which means you can specify just about anything Unicode and your CSS file’s character encoding will allow.

Grid and Flexbox

A question you may have is: now that we have Grid, do I throw away Flexbox? Absolutely not! The two can and do work very well together.

Consider the navigation bar of my design. For years, it’s been laid out using an unordered list and float: left for the list items. Simplified a bit, the CSS and markup looks like this:


#navlinks {
  float: left; 
  width: 100%;
}

#navlinks li {
  float: left; 
  list-style: none; 
  margin-left: 1px;
}


<div id="navigate">
   <ul id="navlinks">
     <li><a href="…">Archives</a></li>
     <li><a href="…">CSS</a></li>
     <li><a href="…">Toolbox</a></li>
     <li><a href="…">Writing</a></li>
     <li>><a href="…">Speaking</a></li>
     <li>>><a href="…">Leftovers</a></li>
   </ul>
</div>

Why not display: inline-block instead of float: left? Because that literally wasn’t an option when I wrote the CSS for the navlinks, and I never got around to updating it. (You may be sensing a theme here.)

Now I have two much better options for arranging those links: Grid and Flexbox. I could define a grid there, which would go something like this:


#navlinks {
  display: grid;
  grid-template-columns: repeat(6,min-content);
}

#navlinks li {
  list-style: none; 
  margin-left: 1px;
}

That would essentially get the same result, only in a grid, which is far more robust than either floats or inline blocks.

On the other hand, I’d be using Grid, which is a two-dimensional layout system, for a one-dimensional piece of layout. It’s certainly possible to do this, but it feels a little like overkill, and it’s not really what Grid was designed to do. Flexbox, on the other hand, is designed for exactly these kinds of situations.

So I might write the following instead:


#navlinks {
  display: flex; 
  justify-content: flex-start; 
  flex-wrap: wrap;
}

#navlinks li {
  list-style: none; 
  margin-left: 1px;
}

Again, that would be basically the same result, but in a more robust fashion. In addition to keeping the links all lined up, the wrap value will let the links go to a second line if need be. And because the flexbox sits inside a grid item that’s part of a grid row whose height is min-content, any increase in height (due to line wrapping or whatever) will cause the entire row to become taller. That means the rows after it will move down to accommodate it.

And now that I look at the markup again, I’ve realized I can simplify that markup without needing to touch any grid styles. Instead of wrapping a list with a div, I can drop the div and reassign its ID to the list. So the markup can become:


<ul id="navigate">
  <li><a href="…">Archives</a></li>
  <li><a href="…">CSS</a></li>
  <li><a href="…">Toolbox</a></li>
  <li><a href="…">Writing</a></li>
  <li><a href="…">Speaking</a></li>
  <li><a href="…">Leftovers</a></li>
</ul>

After adjusting the selectors in my CSS from #navlinks to #navigate, the resulting layout will be exactly as it was before. The ul will become a grid item and a flex container. That is a thing you can do.

The downside in my case would be dealing with any interactions between that change and my legacy layout, but it’s not a huge issue to solve. It’s just a matter of doing it.

Letdowns

So what are the down sides?  Not many, but they do exist.

Most fundamentally, there’s no way to define an overall page grid that has all items relate to it. In other words, if I say:


body {
 display: grid;
 grid-template-columns: repeat(16, 1fr);
}

…then that sets up a 16-column flexible grid for the body element only, and its child elements are the only ones that can become grid items. I can’t reach down into the document tree and assign elements to be placed on that body grid. That’s the main reason I didn’t try to put the little sidebar bits on my blog posts into a shared grid: I literally can’t, at this point, unless I resort to ugly CSS or HTML hackery.

The capability to do such things is known as subgrid, and it hasn’t been implemented by any browsers as yet. There are questions as to exactly how it should or shouldn’t work, so there’s still plenty of hope that everything will work out in the end. It’s a disappointment that we don’t have it yet, and that lack restricts the full range of grid’s power, but hopefully only for a short while.

In the meantime, I’m sure people will come up with ways to work around this limitation. A basic workaround in this case: I could define a grid that applies to every blog post individually, and arrange the pieces of each post on those nested grids. The CSS would look something like:


div.post {
  display: grid;
  grid-template-columns: [meta] 10em [main] 1fr;
  grid-template-rows: [title] min-content [main] 1fr;
}

With that, I could place the metadata, the title, and the post’s body text into the defined grid cells, using either grid line numbers or the grid names I set up. Something like:


div.post h3 {
  grid-column: 2; 
  grid-row: title;
}

ul.meta {
  grid-column: meta; 
  grid-row: main;
}

div.post div.text {
  grid-column: main; 
  grid-row: main;
}

The drawback is that the metadata is then constrained to be a specific width, instead of my being able to set a column that all metadata shares, and size it by the longest bit of content.  That’s no worse than right now, where I’m setting the floated metadata to an explicit width, so this doesn’t lose me anything. It’s just a (temporarily) missed opportunity to gain something.

Another limitation, one that may or may not be addressed, is that you cannot directly style grid cells. Suppose I’d wanted to put a box around the #extra sidebar, completely filling out that cell. I’d have to style the div. I can’t do something like this:


@grid-cell(2, 3) {
  background: teal; 
  border: 1px solid;
}

I mean, I’m not even sure the syntax would look anything like that (probably not), and this sort of capability is only now starting to be debated by the Working Group. If you have use cases for this sort of capability, definitely share them with the world and the folks at www-style. The more real-world cases there are, the stronger the case for supporting them.

And there will, inevitably, be bugs to fix. For example, as I was finishing this article, I discovered that in some situations, Chrome 57 can suffer from a page-blanking bug when using Grid. It appears to be caused by having absolutely-positioned elements removed from a Grid page, and can be triggered by extensions like Window Resizer and LastPass. The good news is that a fix has been accepted for Chrome 58, so it should be fixed by the end of April 2017 at the latest.

Grid power

I hope this exploration of applying Grid to a live site has given you a taste of what’s possible. But I want to warn you that it’s just a taste, and a minor one at that. I was only able to scratch the surface of what the Grid syntax makes possible, so if this has captured your imagination, I strongly encourage you to experiment and then to dive into the Grid specification to see what else is possible. (Grid gaps! Dense grid packing! Inline grids! Auto-filling rows and columns!)

But even more, what I explored here was the barest wrinkle on the outer edges of a scratch on the surface of everything that Grid will make possible. Sure, it can make our existing designs more flexible, robust, and simple to maintain. That’s pretty great. It also makes possible layouts we’ve never even dreamed of, because they were impossible given the tools we had available. There are new techniques, even new art movements, waiting to be discovered. We haven’t experienced a phase shift this profound since the original move from tables to CSS. I hope you’ll be a part of exploring this new realm.

Resources

As I said, this is at best an introduction. Want to know more? Here are some great resources to get you going:

 


Read the full article

Mar 22

This week’s sponsor: HIRED

Source: A List Apart

HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.


Read the full article

Mar 10

Practical Design Discovery

Source: A List Apart

A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Dan Brown’s new book, Practical Design Discovery, available now from A Book Apart.

One of the hardest design problems I ever worked on was for a company that helps IT groups manage risk. Their product focused on open-source components—inexpensive and widely supported by an enormous community, but often vulnerable to security flaws.

What made this design problem hard was the complexity of the product’s underlying structure, a triangle of interrelated abstract concepts. To work through the problem, we created a series of sketches that helped us understand it.

The outcome ended up being a relatively simple prototype, a model of the overall structure of the application. Though we were chartered to create a detailed design, our client later admitted that they knew we wouldn’t get there, but that they highly valued our efforts to solve the underlying structure. Those efforts set the direction for everything else on the product.

Direction-setting assertions

Much like when we frame problems, we can make assertions that set direction and describe decisions about the design. These decisions will be pretty high-level, meaning they’ll deal with a holistic view of the site or product. Decisions about details come later, though you’ll see that some assertions get pretty specific as a way of clarifying and testing the direction.

There are three kinds of assertions you can make about design direction:

  • Principles define what the design should or shouldn’t do. These statements are grounded in research, and may be referred to as implications when you can tie them to research.
  • Concepts establish an overall approach for the product, expressed as a central theme or idea.
  • Models describe the product in an abstract way, showing the underlying architecture, structure, flow, or approach. They offer a sense of how the product will work (without actual functionality).

If you try to make tactical decisions too early, you may set a precedent without understanding how it influences what comes next—it’s difficult to trace low-level decisions back to a specific objective or problem statement. Why is the button blue? There’s no project objective in the world that can justify such a decision.

Instead, you’ll make a few low-level decisions alongside your assertions, using samples to illustrate, clarify, and demonstrate the application of the high-level decisions. For example, you might arrive at the design principle that the site’s tone should be friendly without being too casual or informal. You would demonstrate that through sample screen designs and content, showing messaging that says “Thanks!” instead of the too-formal “Thank you very much” or too-casual “You rock!”

Exploring the big decisions through examples might encourage you to reconsider them, or to find places in the product experience that need variation. Perhaps the color palette is insufficient for everything you need, or the authoritative voice isn’t appropriate for certain pages.

By venturing a solution, you’re not just asking, “Will this work?” You’re also asking, “Do I have enough knowledge to know whether this will work?” That is, steps toward solving the problem may trigger additional insights, or questions, about the problem. Great discovery entails providing just enough shape and definition so the team can get aligned behind them as direction for the product.

Principles and implications

Principles are rules that help designers evaluate their decisions about the design. They provide guidance in the form of absolute statements about what the design should or should not do. That said, no set of principles can be exhaustive. They read, sometimes, as commandments: rules that may be applicable to many different kinds of design decisions, and therefore open to interpretation.

There’s no industry standard on how to write design principles, so you won’t be violating some ordinance if you use pictograms or write a dialogue. But principles are usually just one sentence, often written in the imperative:

Do more with less (Microsoft Design Principles)

Design for the customer and instill confidence (Intuit)

Use data to make and improve decisions (Principles for 21st Century Government, Code for America)

I like these, but they don’t feel specific to the product or company. Principles are most powerful when they’re directly relevant. These use more elaborate phrases that closely relate to the product:

More than boxes on a screen (Google Calendar)

Transitional interfaces are easier to learn and more pleasant to use (MapBox)

Time matters, so build for people on the go (Windows User Experience Design Principles)

Sometimes, you’ll find principles rendered as one- or two-word noun phrases, as if to complete the expression, “The Principle of ______.”:

More Contrast (10 Principles of Codeacademy.com)

Consistency (First Principles of Interaction Design, Bruce Tognazzini)

Principles are sometimes followed by deeper descriptions and examples. My favorite variation of this comes from the Windows User Experience Design Principles. These principles include questions for designers to ask themselves about design decisions:

  1. Personalization, not customization
    • Does the feature allow users to express an element of themselves?
    • Have you made the distinction between personalization and customization?
    • Does the personalization have to be a new feature, or can it make use of existing features and information (such as the user’s location, background picture, or tile)?

Regardless of the approach you take in framing the principles, use consistent language and structures, if only to make them easier to remember and use. If you lead with a verb, always lead with a verb. If you write a pithy phrase or a complete sentence to express the principle, always do that. If you write single-word principles, well, there’s a special place in purgatory for you.

In my practice, I phrase principles as direct consequences of what we learned in research. I call them implications, and I prefer them because they fit into the narrative: “We learned that users often lose their place in the system. The implication is that the UI should prioritize clarifying context.”

Implications answer the question, “So what?” You’ve generated a lot of data, and now need to explain why it all matters. I typically document this in a spreadsheet that identifies project questions, answers I’ve uncovered, and the resulting implications (Fig. 1).

Table of three columns and five rows, with a list of questions in column one, answers in column two, and implications in column 3
Fig. 1: Gathering activities generate answers to questions concerning context or requirements.

Ultimately, principles and implications do the same thing, so I won’t belabor the distinction between them. In both cases, they make an assertion that, yes, guides the designer, but also provides a test: designers can compare an idea to the principle and determine how closely it adheres to the guide.

There’s no standard for design principles, though there are lots of suggestions out there (the Resources section includes a few of the best). Here are my suggestions for crafting design principles.

Be specific

Principles should be as specific to the product as possible. “Easy to use” isn’t a meaningful principle, because it could apply to anything.

For the project with the risk-management company I described at the beginning of this chapter, we used a number of principles. In early versions of their product, users complained that it was easy to lose their place, so they couldn’t keep track of what they were working on. This led us to the principle:

Always display the user’s context within the system, so they know where they are and what they’re working on.

Context became something we talked about a lot. It forced us to think carefully before moving information to a different screen, or triggering a dialog box for taking action. Because of this principle, we often asked ourselves, “Can the user tell where they are? Is loss of context here okay?”

Question your choices

Good principles go beyond specificity: they issue a direct challenge to designers. They force you to take a second look at your work: does the principle invalidate any of your decisions? Done right, principles should make you squirm a little.

In the risk-management product, the complexity of its requirements inevitably produced dense, esoteric designs. Elaborate displays attempted to capture every nuance, pack in every detail. At the same time, our client had heard their users didn’t like the dense displays. We had to walk a fine line, and so we relied on this principle:

Show just enough information to support essential decisions—no more, no less.

The principle’s borderline self-contradiction provoked us to reconsider what stayed on each screen as users worked through the process. Did we take out too much? Is everything on this screen absolutely necessary? On one hand, we wanted users to feel confident about where they were, but on the other, we didn’t want the page overwhelmed by navigation devices irrelevant to the current task.

We also constantly asked ourselves, “What is ‘just enough information?’” and “What are the ‘essential decisions?’” Every iteration of the design tested the meaning of these key phrases.

Inspire your team

Specific and provocative principles may seem like whip-cracking: Do this, and do it this way. But a good principle also inspires you, pointing you to even loftier goals. It opens up possibilities by encouraging you to explore—and providing rationale for where you end up.

In Luke Wroblewski’s summary of a 2009 talk by Stephan Hoefnagels of Microsoft, he writes, “Goals are the mountain peaks you are trying to get to. [Design] principles are the path we use to get to the top of the mountain.”

One of the driving principles for my client’s product rested on the insight that the product was focused on bad news: every display was about what was going wrong in the IT department that day, how bad it was, and what wasn’t getting done. Like most interactive products, though, this one was meant to be a pleasure to use. In short, we needed to balance the gloom and doom with the satisfaction that comes from understanding the nature and extent of the bad news. We relied on this principle:

Build confidence by clearly stating risks and making the data actionable.

We knew the goal was to help customers manage risk. This principle acted as the path to the top of the mountain by inspiring us to focus not just on reporting the bad news, but also on ensuring customers could do something about it.

Link principles to research

Principles grounded in research make for stronger statements. The death knell of any principle is arbitrariness: if a principle comes from the subjective preference of the Chief Something Officer or because it reflects the (dysfunctional) way the organization has always worked, designers will ignore it. Your principle can be otherwise perfect, but if its source is suspect, the team won’t take it seriously.

The team’s participation in all discovery activities is crucial here, too. Since they helped with the research, they can also help with writing the principles. By participating in crafting principles, your team will internalize them. Seeing the principles later will trigger memories of user observations, which they can integrate into their work more readily.

The Windows User Experience Design Principles came directly from research. In reading some of these principles, you can almost hear supporting quotes from users:

  • Reduce concepts to increase confidence
  • Small things matter, good and bad
  • Be great at “look” and “do”
  • Solve distractions, not discoverability
  • UX before knobs and questions
  • Personalization, not customization
  • Value the lifecycle of the experience
  • Time matters, so build for people on the go

You might argue that these lack specificity. When you take into account the scope of the project, however—an entire operating system—they’re sufficiently provocative and inspirational. “Solve distractions, not discoverability” is a bold statement, offering clear opportunities to refine the design without dictating a particular solution. It opens up conversations, and steers them, too.

Concepts and big ideas

One of my favorite scenes in Mad Men, the television show about advertising agencies in the 1960s, is the pitch to Kodak at the end of the first season. Kodak is introducing a new product, a circular tray that makes it easy to store and show photographic slides. They call it “The Wheel,” admitting, “We know wheels aren’t seen as exciting technology.”

Creative director Don Draper, the show’s main character, explains that this product isn’t about the technology: it’s about tapping into our memories and emotions. The agency then pulls the veil off their concept for the campaign: the carousel.

By establishing a central concept, a team (whether in advertising or web design) has a singular source of inspiration, a template for considering ideas. And while principles can serve as guideposts, only a concept can establish a vision. With both of them in your toolkit, your team has a potentially interesting tension to draw from.

Using a carousel to describe a slide projector creates a metaphor brimming with meaning and possibility. It shows two ways we can express a big idea:

  • How the product makes you feel: carousels evoke the joy of reliving happy memories.
  • How the product works: the spinning carousel mimics storing and displaying photographic slides from a wheel.

Either approach can help us express the big idea behind our digital products and websites. (Though I’ve never worked on a project that gave us a central concept as elegant as the carousel, which employs both approaches!)

How the product makes you feel

The purpose and function of interactive products offer ripe opportunities for metaphors, but metaphor isn’t the only way to express a central concept. For one web application project, my team expressed the essence with the phrase, “Power with flexibility.” Doesn’t quite roll off the tongue like the word carousel, but it evoked the desired feeling: that the app should make users feel like they can do anything.

We elaborated with descriptions of how people would experience unconstrained power with the product:

Provide users up-to-date status so they feel in control

Lower barriers to entry

Allow different styles of creating new content

We also described what “Power with flexibility” meant from the user’s perspective:

  • Knowledge: having the right data to shed light on immediate needs
  • Responsiveness: being able to provide answers to stakeholders immediately
  • Accomplishment: getting up to speed on a crucial tool right away
  • Control: being able to fine-tune their content to suit different needs in different situations
  • Comfort: seeing the application as an extension of one’s own thought process

Since this essence was a succinct idea, a little elaboration helped it to resonate with both the client and the project team.

How the product works

Complex interactive products benefit from a central idea that describes how they work. This usually means employing a big idea to convey the underlying structure.

Shopping cart, for example, is a popular metaphor used on ecommerce sites. You could use it even if you weren’t working on an ecommerce site. The idea of “adding stuff to the cart” is a familiar metaphor that conveys a site’s underlying structure. We even relied on this metaphor on our career-guidance site: students would “add careers to their cart” after taking an assessment.

There are a few other tried-and-true frameworks for describing the structure of a website. For web applications, there are two common ones beyond the shopping cart:

  • Hub-and-spoke: This is perhaps the most common pattern for structuring a website or digital product. The hub-and-spoke metaphor implies that the web application has a central screen, from which users may trigger all other functions.
  • List-detail: Another typical approach consists of a list of items from which users can select for more detail—like your email inbox.

Do you have to use one of these structures? Of course not. But if your site lends itself to one of these approaches, you have your big idea that the rest of the functionality revolves around. (That wasn’t a carousel reference. I promise.)

For sites that focus on delivering content (rather than transactional functionality), the tried-and-true frameworks deal more with how the content is organized:

  • Topics: what the content is about, or the subject matter
  • Actions: what tasks the content supports (like researching products versus troubleshooting products)

These aren’t the only structures for categorizing content, but they are my go-to starting points.

None of these is a fully fledged design in and of itself. They are well-understood frameworks that serve as the backbone to a much larger design. They are big ideas that describe how the product works.

You don’t have to rely on an abstraction or metaphor (like the carousel) to convey the big idea, but instead draw from the emerging library of understood frameworks. That they are becoming part of web design lingo is a testament to their power and flexibility.

There’s more where that came from!

Check out the rest of Practical Design Discovery at A Book Apart.


Read the full article

Mar 08

Design for Fingers, Touch, and People, Part 1

Source: UXMatters – <p class="author">By <a href="http://www.uxmatters.com/authors/archives/2012/04/steven_hoober.php">Steven Hoober</a></p>

<p>People have now read and referred to my 2013 column <em>How Do Users Really Hold Mobile Devices?</em> almost too much for my comfort. Why? Because, since I wrote that column, I have continued to do research, put my findings into practice for real products, written additional articles, and presented on that topic. In the years since then, I’ve learned a lot more about how people hold and touch their phones and tablets—a lot of which I did’t expect. And that’s the problem with my old columns. I made some assumptions that were based on observations of the usage of desktop PCs, standards for older types of interactions, and anecdotes or misrepresented data. However, through my later research and better analysis, I’ve been able to discard all of those erroneous assumptions and reveal the truth.</p>
<p class="sub-p">All too often, I see people referring to my oldest, least-accurate columns on this topic. Sometimes readers combine my obsolete data with other out-of-date information, then draw their own incorrect conclusions. I hope put a stop to that now with this updated overview of everything I know about how people interact with touchscreen devices and how you can use that information to design better digital products. <a href="http://www.uxmatters.com/mt/archives/2017/03/design-for-fingers-touch-and-people-part-1.php" class="read_more_link">Read More</a></p>
Design for Fingers, Touch, and People, Part 1

Mar 08

Experience Design: Beyond a Simple ROI

Source: UXMatters – <p class="author">By <a href="http://www.uxmatters.com/authors/archives/2017/02/corinne_wayshak.php">Corinne Wayshak</a></p>

<p>Executives want to know the return on investment (ROI) for the products and solutions their company creates. They typically want to know the ROI for user-experience efforts, too. However, while many UX leaders would love to be able to create a reliable ROI model to justify their team’s resource needs and communicate its value, a product’s user experience is so pervasive that trying to determine isolated UX metrics is futile. It’s always difficult to come up with <em>atomic</em> ROI assessments, but this is especially true for the user experience, which, in fact, represents the entire product.</p>
<p class="sub-p">For example, even if a call-center application’s user experience were outstanding and saved five minutes per call, it would not be possible to isolate the direct impact of the UX team that designed the application. Engineering and Product Management have also contributed to the application’s excellence, so what percentage of that savings would it be logical to attribute to User Experience? Conversely, if the intended user experience of that application had instead degraded during development, making calls take longer, to what team should you assign the additional cost of calls? <a href="http://www.uxmatters.com/mt/archives/2017/03/experience-design-beyond-a-simple-roi.php" class="read_more_link">Read More</a></p>
Experience Design: Beyond a Simple ROI

Mar 08

Conducting Qualitative, Comparative Usability Testing

Source: UXMatters – <p class="author">By <a href="http://www.uxmatters.com/authors/archives/2009/10/jim_ross.php">Jim Ross</a></p>

<p>Although UX designers usually consider various different design directions early during projects, they typically choose one design to develop further—long before conducting the first usability test. However, testing multiple designs early in a project can provide much more useful information than testing just a single design solution. When participants can experience two or more designs during testing, they can provide better feedback. As a result, you can gain greater insight into the elements of each design that work well and those that cause problems.</p>
<h2>What Is <em>Qualitative</em>, Comparative Usability Testing?</h2>
<p>When you read the term <em>comparative usability testing</em>, you might think it refers only to benchmarking the usability of an existing user interface against that of its competitors. In this type of comparative usability testing, you’d compare existing user interfaces with each other, using quantitative metrics such as task-completion and error rates and time on task. Therefore, participants perform test tasks without interruption and do not think aloud. You might also compare participants’ responses to a questionnaire. <a href="http://www.uxmatters.com/mt/archives/2017/03/conducting-qualitative-comparative-usability-testing.php" class="read_more_link">Read More</a></p>
Conducting Qualitative, Comparative Usability Testing

Mar 08

Conference Review: O’Reilly Design Conference 2016

Source: UXMatters – <p class="author">By <a href="http://www.uxmatters.com/authors/archives/2005/11/pabini_gabriel-petit.php">Pabini Gabriel-Petit</a></p>

<p>The inaugural O’Reilly Design Conference took place at Fort Mason in San Francisco, January 20–22, 2016. O’Reilly Media formed its conference division in 1997 and currently hosts nine different conferences for software-development professionals, in various locations around the world. O’Reilly has extensive experience organizing professional conferences and a stable of 55 authors who have written O’Reilly books on user-experience topics, so this was bound to be a very good conference.</p>
<p class="sub-p">In this review, I’ll provide an overview of the conference, including its</p>
<ul>
<li>organization</li>
<li>content and presenters</li>
<li>proceedings</li>
<li>venue</li>
<li>hospitality</li>
<li>community <a href="http://www.uxmatters.com/mt/archives/2017/03/conference-review-oreilly-design-conference-2016.php" class="read_more_link">Read More</a></li>
</ul>
Conference Review: O’Reilly Design Conference 2016

Mar 08

Value, Quality, Respect: Getting the Most Out of Technical Writers

Source: UXMatters – <p class="author">By <a href="http://www.uxmatters.com/authors/archives/2017/03/rebecca_firestone.php">Rebecca Firestone</a></p>

<p>In over 25 years as a technical writer, I’ve experienced both good and bad clients. The good ones know what they’re doing, treat writers with respect, value quality beyond paper metrics, and appreciate the value of technical communication. The bad ones end up wasting everyone’s time and shooting themselves in the foot.</p>
<p class="sub-p">In this article, I’ll discuss how you can get the most out of your technical writers by creating a healthy business environment, in which value, quality, and respect reinforce one another, as I show in Figure 1. <a href="http://www.uxmatters.com/mt/archives/2017/03/value-quality-respect-getting-the-most-out-of-technical-writers.php" class="read_more_link">Read More</a></p>
Value, Quality, Respect: Getting the Most Out of Technical Writers

Mar 02

Long-Term Design: Rewriting the Design Sales Pitch

Source: A List Apart

We run our client service businesses just like door-to-door salespeople hawking vacuum cleaners. That may seem unfair, but it’s exactly how we sell design. We’re focused on short-term wins—but we’re teaching clients to see our work as disposable.

I want to believe we’re better than that.

We spend our entire careers knocking on doors and shilling our services. It’s just how we do business. Even if a potential client’s old design is working just fine, we might go for the hard sell. But that’s damaging, both to us and to our clients. This practice perpetuates the idea that design is only valuable when new.

Consider the salesperson’s pitch:

Your [design/vacuum] is old. Other people have newer ones. You’re going to lose out if you don’t buy a new one. Your family/business might even be unsafe with your current one.

We believe that being a designer requires cycling through clients and booking new projects. Instead of talking about dust or maneuverability around furniture legs, the designer’s pitch is more like this:

Your current design is not allowing your brand to resonate in the marketplace. It looks dated, and your competitors all recently launched new branding. You could lose market share to competitors without a more modern design.

Short-term engagements are bad for our clients

We write articles in phenomenal publications like this one about how design isn’t just about aesthetics—design should be a fundamental part of how a business operates, conducts market research, and creates products and services. Design is powerful and important. So we preach the doctrine of Design Thinking. We work to improve accessibility and web standards for the good of all. We preach user advocacy.

However, when we pitch design work to clients, so often we’re only selling the aesthetics. And, when we book the gig, we try to ship that design and get that final invoice paid so we can bring in the next client.

We designers rarely stick around to see how well the design works. We begin each project with design thinking, but rarely maintain it. And because of that, each client goes shopping for another new design (or succumbs to the pitch of another designer) much sooner than they need to.

Design requires time in order to deliver its full value. For example, when a new website launches, we can measure changes in analytics immediately. But that design also carries the potential for further improvements—enhancements that can be unlocked through A/B testing, analysis, and optimization.

Unfortunately, the vast majority of sites are never optimized. They launch, sit for a year or two, then get replaced. Our clients aren’t getting the full return on their investments.

And if you think about that even further, this “cycle of redesign” makes design less valuable. In other words, if design is only valuable when new, it isn’t very valuable in the first place.

New, cheaper solutions are encroaching upon our profession, such as logo-designing software, theming algorithms, and drag & drop design tools. We fear we are being replaced by these alternatives or that the perceived value of design is decreasing. And in the next breath, we tell our clients “Let’s make a fresh, new design for you.”

We can’t blame clients for trying affordable new options; we’re the ones who taught them to value “new” design in the first place.

Cycling through clients is less lucrative

Finding a constant stream of new clients takes a lot of effort and is a constant challenge for many designers and agencies. Freelancers spend countless hours crawling job boards and submitting their portfolios in hopes of getting hired. Agencies spend considerable resources responding to RFPs, and many employ sales staff and account managers.

When designers enter more senior-level positions, they eventually face the frustration that more time is spent selling, meaning less time to design.

Sales isn’t bad and will always be necessary to some degree. That said, when we spend more time on sales than we need to, compensation suffers. Naturally, reducing the time and effort on sales so we can do more design work would be more lucrative. To do this, we only need to stop knocking on new doors and instead continue to serve the clients we already have. We need to change how we structure our services and start supporting clients over the long term.

Long-term work can be personally and professionally satisfying

Designers have a certain obsession with making new designs, and you might think that working with the same client for a year sounds boring.

I’ll admit it: making new designs is fun. I love the act of creation and the satisfaction of making something fresh and cool. However, by cycling through clients, we’re missing out on some of the most satisfying design work there is.

Few projects are as challenging or gratifying as redesigning a responsive web app that has four tiers of navigation. That might sound horribly tedious and painful at first, but solving a difficult design problem brings incredible satisfaction.

Further, witnessing people benefit as a direct result of your design can be powerful and rewarding—much more rewarding than the temporary thrill of making something new. You see your design taking an active role in growing a business or in improving a person’s daily work. You see other people recognizing your design’s value. That’s a great feeling.

This is often only possible when you stick around and serve the client over the long term.

What it’s like working with clients over the long term

For me, the idea of a long-term structure for my design services started when a client said this:

I’m tired of signing a contract every 6 weeks. Can I just pay you every month instead?

Now I only do retainer work. All my current clients have been with me for more than a year.

In the early days of running my solo consulting business, I spent a lot of time crawling job boards, writing proposals, scheduling “nice to meet you” calls, and booked only a small fraction of projects. Some weeks, I only did sales work and didn’t get to spend even a minute on design.

Fast forward a couple of years, and I can’t even remember the last time I glanced at a job board. I don’t do sales calls. I don’t respond to RFPs, search for leads, or write long proposals every week. I do more design work than ever. And, I rarely do revisions on my work because my clients trust me. My design business is completely different now that I work with clients for the long term. I find more satisfaction in my work. I solve difficult problems and enjoy seeing my clients thrive.

I make more money this way, too, because I get paid for more of the time I spend at work. (I don’t bill by the hour, but another way to put this is: I’ve increased billable hours and decreased non-billable hours.)

How to set up long-term client relationships

If you are tired of needing a constant flow of new clients and investing in the long view sounds like a plan, here’s how to start.

Look for long-term needs. Most design projects conclude when we deliver the design and the client pays the last invoice. It seems final. But this can be terrifying for the client. Many clients don’t know how to use the tools we produce for them—they don’t know how to use a website or marketing campaign, and they struggle to determine whether it’s successful.

By offering support and advice after the first project concludes, you not only show that you are committed to helping the client succeed and get value from the investment (which is good for the client), but you are opening the door to future projects with that client (which is good for you).

There are many, many opportunities for continuing design work with clients who have profitable and growing businesses. Long-term work doesn’t have to consist only of small updates and maintenance; it can include supporting new business initiatives and keeping the brand and assets in line. You can position yourself as a design director and advise on strategy and brand consistency. These are extremely valuable services to our clients and protect their investment in the original project.

Most clients don’t know how to match all of their marketing efforts to the new brand you created for them. Or, they may want to launch a new feature or product, or weave a new ad campaign into the design you’ve created. These evolutions need design support. By sticking around after the first project and showing the value of your partnership, you can position yourself to get hired repeatedly.

To be clear, long-term work is not unpaid work. Delivering a design doesn’t mean a designer should be on the hook for free support indefinitely. Depending on the client and the kind of work you do for them, there are many possible ways to structure a long-term relationship, such as:

  • Monthly retainers
  • Additional project phases, such as conversion rate optimization (CRO) and user testing
  • Scheduling a check-in call a month after launching a new design
  • Including a written analytics report in the project fee.

Clients might see these as attempts to increase fees and the project scope. That’s because long-term structures can be as unfamiliar to clients as they are to designers. To address those concerns, designers need to educate our clients about the benefits and value of long-term engagements. Great ways to begin the conversation include:

  • Explaining that optimization will help the client see the most return from their investment
  • Explaining that optimization will help avoid the need for a redesign later.

Design’s “old money”: Big agencies and bigger accounts

Long-term client service is old hat to big ad agencies; they’ve been operating like this for decades. If you read AdAge.com, you’ll see announcements about big agencies landing accounts from bigger companies to the tune of hundreds of millions of dollars. Of course, the agency doesn’t get to keep all of that—much of it goes to TV networks for ad time, and websites and print media for ad placements. But it usually means everyone gets to keep their jobs for a year.

When a big account changes hands, it’s news. As in, the kind of news serious journalists cover.

Agencies pour a ton of resources into landing big accounts, and, when they do, they get a year to prove their worth. Changing agencies is a major decision for big companies because it is a big investment and substantially impacts marketing success.

While I don’t advocate replicating every aspect of the big agency model (especially not spec work), small agencies and even freelancers can offer long-term services to smaller clients in the same way. Consistent income and long-term relationships aren’t only for huge agencies that date back to the Mad Men era. Even operating on a smaller scale, the benefits to both designers and clients are the same.

Practical freelancing concerns

For me, personally, there was a lot to learn when I decided to try long-term engagements. That investment has paid off by providing me a more consistent freelancing income, reducing administrative and sales tasks and increasing my total income.

That said, there are risks and complicating factors in long-term relationships.

For freelancers, the risk of working with clients over the long term is that if you lose a client, you will have to work harder to refill your work schedule because your lead pipeline for new clients is slower. Worse, if you only work with a single client for a long period, it’s like putting all your eggs in one basket. Losing your only client is obviously a serious concern.

Because of that risk, keeping several engagements active simultaneously is important for earning consistent income and protecting yourself if you do lose an important client.

Additionally, long-term freelancing carries tax implications. The legal distinction between a salaried employee and a full-time contract worker, or even an independent contractor, varies in many countries, and some countries, such as the UK, are suspicious of long-term, full-time contract work because it can be used as a strategy by companies to avoid tax liability or to avoid providing legally required benefits.

If not just for the financial stability, but also to avoid tax headaches, I recommend keeping several long-term client relationships active at once or limiting full-time engagements to shorter periods that then transition into part-time work for each client. And, of course, consult your tax advisor.

If you’re working full-time for a client for a long period, such as six months to a year, you deserve benefits. While long-term work is stable and attractive for many reasons, don’t let it become a way for someone who is essentially an employer (as opposed to a “client”) to withhold compensation you deserve.

Finally, writing contracts for long-term work can be complex, especially for structures like retainers. It’s always a good idea to consult a lawyer and to buy errors and omissions and general business liability insurance to protect yourself.

Respect for designers and profit for clients

With long-term optimization, design works better and better. And when clients see their profit increasing and that business goals are being met, they place greater trust in their designers.

A long-term partner who works month after month to support a client’s business is vastly different from the door-to-door salesman.

When designers behave as long-term partners, we prove the value of design and earn more respect. It also sets the stage so we can make great money while avoiding the less desirable sales work that so often invades our calendars.


Read the full article

Feb 24

Big Data Visualization with Meaning

Source: A List Apart

The web is not the traditional home of data visualization. You might come across a bar chart here or there in your online journey on any given day, but they’ve never been an artifact of web history. It seems like that’s been changing.

With the world becoming increasingly data-driven, we’re seeing more and more visualizations make their way onto our web pages and into our design briefs. They help us tell stories that better engage our users, and can even get them to take some kind of meaningful action.

The problem is that these datasets—sometimes so large they’re literally called “big data”—can make visualization with meaning difficult. But that’s something we as designers are equipped to tackle. We just have to know what our users are hoping to gain from viewing and interacting with visualizations, and what we have to do to make their effort worthwhile.

Data has a very strong power to persuade—powerful enough to change users’ everyday behavior, especially when data is informative, clear, and actionable. We should be putting data visualizations to work on our sites, enhancing our designs to show users how data is in service to the story they’ve come to learn about.

Data visualization on the web can be meaningful through allowing people to discover the smaller stories that resonate with them, customizing their user experience instead of putting them on a predetermined path.

Users attempting to interact with large and generally disconnected sets of data while navigating a site or trying to access relevant information end up facing a difficult, if not impossible, task. Our sites lose a certain measure of usability if they aren’t well-designed, even though the web is a natural medium for delivering truly interactive data. 

As with all design, the approach we take when creating a user-minded visualization is based on the context and the constraints we have to work with. Good data visualizations—those with meaning—need to be accessible and human even though data is rarely described with those words.

Telling a story

The key to designing visualizations is to focus on something in the dataset that is relatable to and resonates with your users. I stumbled upon this while creating a visualization from the publicly available Open Food Facts dataset, which contains crowd-sourced information on food products from all over the world.

Although the dataset covers an extensive range of information (even down to packaging materials and number of additives), I chose to focus on comparing average sugar consumption among different countries (Fig. 1) because I was personally concerned about that topic. It turned out to be a concern for others as well and became the most popular project for the dataset on Kaggle.

Bar graph depicting quantities of sugar consumption by country
Fig. 1: Average national sugar consumption

Even though I didn’t make extensive use of the dataset in my rough and ugly visualization, what I chose to focus on told a story that resonated with people because most were from the countries listed or had a growing general awareness of high sugar consumption and its effect on health. In retrospect, what’s more personal and important than your health?

Selecting data points that strengthen a story with a positive result (whether that’s eating less sugar or reducing large-scale chemical emissions) can be great, but it’s important to present a story that is as unbiased as possible and to make ethical decisions about which parts of the data we want to use while telling the story.

But what exactly is a story in the context of a data visualization? We can’t kick it off with “once upon a time,” so we have to approach the idea in a different way.

Whitney Quesenbery and Kevin Brooks provide these definitions of a story in their book Storytelling for User Experience:

  • Stories describe the context of a situation
  • Stories can illustrate problems
  • Stories can be used to help people remember
  • Stories can be used to persuade and entertain.

And I would add to the list:

  • Stories can make you question the state of a situation.

Addressing some or all of these attributes is a particular challenge for big datasets because the sheer amount of information can make finding a narrative difficult. But big or not, the principles remain the same. Visualizing any kind of data-driven story that resonates can have a powerful influence on users’ decisions.

It also stirs other questions the user might ask.

For instance, why do certain countries consume higher quantities of sugar? Are they the ones we expected? The information could challenge an assumption or two someone may have had prior to seeing the results. Just remember that visualization can be a stepping stone to further discovery, increasing the user’s knowledge and possibly affecting their everyday choices going forward.

If you’re trying to embed meaning into a large visualization through the story of a dataset’s subsection, it’s important to:

  • Discover what your users care about in the dataset. Make it relevant to their personal needs, desires, and interests.
  • Focus on that subsection ruthlessly. Get rid of anything that doesn’t further the story your visualization is telling.
  • Take care to make ethical, unbiased decisions about which data points you use to create visualizations that might influence your users.
  • Be careful not to give people all the answers; allow them to ask their own questions and make their own discoveries about the data.

This approach allows you to create something that not only resonates at a personal level, but also presents meaning in a way that encourages and allows users to take action.

But we already have a story

Though large, some big datasets already revolve around a single story. An interesting way of dealing with this particular issue is to simultaneously display different aspects of such a dataset, allowing the user to discover that meaning. This is called the “small multiples” technique. (Fig. 2)

Assorted graphs visually illustrating data as seen from memory view, code view, and process view
Fig. 2: Memory stall visualizations from the Rivet project at Stanford.

The cluster of visualizations above, for example, deals with the “story” of memory stall issues on a computer. What I find interesting about the cluster is that the heading of every visualization starts with some variation of “memory stall time.” Despite being separate visualizations, they are linked by the single story they tell and they’re presenting it from simultaneous, distinct perspectives.

It’s possible for perspectives to look completely different from one another if they visualize different kinds of data. For instance, bar charts and area charts can harmoniously coexist if the representations are appropriate for the data they’re showing. The Australian Census Explorer illustrates how this might work (Fig. 3). It allows the user to establish their own narrative through choice of topic, such as language or place.

Screenshot of the native languages list in the Australian Census Explorer
Fig. 3: Given freedom to explore, users inherently craft a personal narrative.

Framing visualizations around a personal topic (like someone’s native language) affects all associated small multiples appropriately; reframing serves to personalize the data. (Fig. 4)

Screenshot comparing two horizontal bar graphs depicting gender and age data for Australians and English-speaking Australians
Fig. 4: Comparison of gender and age data for Australians and English-speaking Australians
Screenshot depicting Country of Birth data, listing percentages for various countries and a global map with lines linking from Australia to each country
Fig. 5: Country of Birth breakdown for Australian citizens
Screenshot comparing two vertical bar graphs depicting income ranges by gender for Australians and for English-speaking Australians
Fig. 6: Income ranges by gender for Australians and English-speaking Australians

Storytelling through interaction

It can be very useful with this approach to include an interaction in one design that is capable of affecting the others—something to help the user see relationships between data points they might not have considered before. This example from essay site Polygraph shows all Kickstarter projects across space, organized here by category and American city. (Fig. 7)

Dot graphs depicting categories, number of projects, and size of projects in a selection of American cities
Fig. 7: Well-designed data visualizations can convey multiple concepts and information in parallel

The visualization is particularly interesting because it allows users to view the relationship of one variable (in this case, the project category) to others, such as American cities or project sizes. (Notice the prevalence of music projects in Nashville and game projects in Austin and Seattle). 

The Lens does something similar in its visualization of the human genome (Fig. 8) by allowing users to change views by way of various filters.

Horizontal bars aligned with their respective segments of a human genome sequence
Fig. 8: Data can be filtered to display different views of the human genome.

This can be even more effective for small multiples shown across time. Fig. 9 shows how this approach is used on a fund manager’s website. Changing the time period of an investment fund’s performance also shows how risk rating and the growth of an investment change during that period. By leveraging intuitive web animation, we can view snapshots of the data at precise moments in time.

A stack of overlaid line graphs illustrating different tracking items, plus a vertical slider that reveals changes in the tracking items when moved to different points along the line
Fig. 9: Interacting with one “small multiple” affects others, revealing relationships at distinct points of time

If the dataset is already centered around some kind of overarching story, it can be a good idea to:

  • Display different parts of the dataset in separate visualizations simultaneously
  • Treat these separate visualizations as individuals tailored to the data they’re presenting. (Bar charts and area charts can live together in harmony if the data makes it appropriate.)
  • If there is interaction, ensure that it affects the entirety of your visualization approach so that the relationships between data points are more apparent
  • Apply well-considered web animation techniques to ensure that the interaction is intuitive.

There are too many stories

What do we do when a dataset doesn’t have a single, big story to tell, yet we still need to visualize everything in it?

Although some datasets lack a specific focus (e.g., “memory stall time,” “fund performance,” or “all-Kickstarter-projects-ever”), data points may have internal relationships that reveal bite-sized stories. How do we create actionable meaning for those visualizations?

Simply showing data as-is, even in a visualization that seems to fit, rarely works well. In Fig. 10 we see relationships between Python code packages, but in a way that’s just as messy and incoherent as the data in its natural state. The lack of focus and narrative is notable. (That said, the dataset is extremely large, so a single narrative isn’t actually possible.)

A chart illustrating numerous types of data, with lines from type to type to show relationships
Fig. 10: This visualization presents nothing actionable, despite the tremendous amount of data

Since a single story isn’t possible in this situation, a better approach is to allow users to discover their own story. Your job is to facilitate that via the interaction design of the visualization.

This browser-based design in Fig. 11 (you can explore it here) visualizes code package relationships, too (in this case, JavaScript), but gives users what they need to explore the data in a meaningful way.

A computer-generated 3-D depiction of data relationships
Fig. 11: Use well-designed interactions to help users work with large, multi-narrative datasets.

Again, at first glance the visualization seems to be messy and incoherent—but look closer. Users can investigate any individual package of code, including its personal relationships (listed in the bottom left). A handy search bar has also been incorporated in the top left corner.

What makes this particular visualization more meaningful is that the user can explore it in 3D space via keyboard and mouse. Leveraging this uniquely digital capability in the browser allows users to start discovering their own story in the enormous swarm of data, “moving” toward areas in the visualization that they find more relevant to their interests or needs. (Fig. 12)

Detail view of specific data nodes in a computer-generated 3D depiction of data relationships
Fig. 12: “Moving” intuitively through the data allows users to find meaning that’s personally relevant to them

Once the user finds a package or groups of packages they’re interested in exploring, they can click on one for a specific and focused view of the package in isolation, including its relationships with other packages. A full breakdown of these relationships is posted on the left of the screen, including visual nodes linking directly to the Github page for that code package. (Fig. 13)

Isolated close-up of a specific data note and its associated information in a computer-generated 3-D depiction of data relationships
Fig. 13: Isolation view of a specific package.

This visualization, like the one shown before it, uses the idea of a network in order to display the immensity of the data, but it also uses intuitive interaction and lets the user explore in order to extract personally relevant meaning. It uses the modern advantages of the web to deal with the modern problems of big datasets, much like the following visualization from OpenCorporates. (Fig. 14)

Computer-generated display of country silhouettes sized according to the provided data and depicting lines of relationship from country to country and city to city
Fig. 14: Look for ways to “translate” data into simple and relatable concepts and simple explanations.

This design allows users to zero in on data they care about, choosing where they go and which breadcrumbs offer meaningful insight.

If a dataset needs to be fully visualized but has smaller stories within it, it may be useful to:

  • Show all data, but give users the ability to create chunks or segments they wish to explore
  • Leverage the advantages of being digital. For example, explore how input devices (e.g., keyboard and mouse) can facilitate how users interact with the data.
  • Use visual metaphors that support extensive and intricate relationship associations, such as a tree or network.

Visualization with meaning

Data is powerful in the right hands, and something we’re skilled at presenting in our websites. But toss in words like “big data” or “data visualization” and we second-guess ourselves instead of owning it as part of our workflow. The web is actually a great place for data visualization.

Leveraging the benefits of “digital” environments and tools, we can help users get what they need from large, complicated datasets. They are looking for insights, for meaningful information presented simply, for stories that resonate—for data stories they care about. We can help them find those stories by blending in a few new techniques on our end, such as sub-selections of data, use of small multiples to show relationships between data points, or even allowing user-driven focus on the full dataset.


Read the full article

Older posts «