Web Development Network  |  Sites:    Capital Tutorials    Internet Marketing Books    Arcade Games
Depiction- Webmaster Resources
Stock Image

Contributors: SSD VPS in Europe  |  SEO Las Vegas |  EsqRank |  Colorado Springs SEO

Dental SEO Marketing  |  Best Las Vegas SEO Company  |  Park Shore Condos  |  Top Rated Binary Option Robots

Misc Links: Submit Tutorials (Earn $$) l Advertising l Privacy Policy | Site Map

RSS News Feeds

A List Apart: The Full Feed

Articles for people who make web sites.

This is the most recent feed available as of 03/28/2017 at 04:17 AM

Practical CSS Grid: Adding Grid to an Existing Design

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:

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

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 navigation div was placed in the exact grid cell I wanted. That would have left the second row’s first cell filled by navigation, 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>

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>

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.


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.


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


This week's sponsor: HIRED

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

Practical Design Discovery

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.

Long-Term Design: Rewriting the Design Sales Pitch

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.

Big Data Visualization with Meaning

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.

This week's sponsor: Hotjar

Hotjar, see how your visitors are really using your site. Try it free.

I Don’t Need Help

We have no excuse…admit it. UX may brag about intuitive and pretty, but we sure suck at helping people—this one thing that most defines, most embodies great user experience.

Throughout history, there’s one recurring theme: people need help. For all we know, the need for assistance might have triggered the development of communication. It could have led to bonding among tribes and our existence today. In the future, it might be the only thing that staves off human extinction and promotes societal evolution.

But if so, that begs the question: why do we find it so difficult to ask for help or offer guidance to one another? Do we prefer to figure things out for ourselves? Are we afraid that any request for assistance would be fraught with obligations to reciprocate? Are we worried that we’ll be rejected? Or that we might not get the help we need?

People do need help. It’s a given—and a problem in the field of UX. We claim to do so much for users, but treat help as an afterthought. How come it isn’t our primary consideration?

A glance at most websites, including those for large and small organizations, suggests that user assistance is treated as a cursory option—often relegated to a question mark symbol tacked onto a corner. The assumptions are:

  • Users won’t need help; the design is intuitive.
  • If users do want help, they’ll look for it (somewhere).
  • Once users figure out where to look, they’ll seek help when they need it.

If the same scenario were layered on real-world interactions, it would be analogous to visiting a large museum, with maps, tours, guides, and program schedules hidden in a locker at some end far off the main entrance.

Why offer help before it’s requested?

Taking the guesswork out of a customer’s experience is beneficial to all involved.

Consider that you’re walking into a new casual diner. Initially you may wonder if everything is self-service, and if you are expected to clear your own table. You could just stare at folks around the room and make your move based on what other diners are doing. Or, the franchisee could help you get up to speed right away. Ikea solves the what-do-I-do problem with a “Why should I clear my own table?” sign right at the center of its popular store restaurant. The sign solves two problems—it gives the customer needed information immediately and it promotes Ikea’s aim to cut costs.

Designers create user interfaces through careful planning, so one popular conclusion is that if a design has been a success, no explanation—no prominent sign—is required.

But help is often sought or needed for a variety of reasons. Help could be required to explain certain fields in a form, to define the meaning of a specific icon, to parse highly technical terms, to identify new features, to illuminate hidden gestures, or to detail policies that are obtuse.

A user may immediately understand that a pencil icon opens an editing pop-up. If he doesn’t, he may well figure it out eventually but only after moments wasted in confusion.

No matter how smart a design is, unless it is customized to every user’s personality, needs, working conditions, device, domain knowledge, technical expertise, and mood, it will need some explaining. A good designer empathizes with unique concerns and takes users as they are, from practiced online mavens to casual browsers. A good design includes user assistance that is given due consideration. 

When help goes wrong

Sometimes websites do make dedicated attempts to help. And sometimes those attempts smack of overkill.

There are video tours expertly created to take users through each feature in the product. There are slideshows with custom fonts and colorful characters that highlight everything new and promising in the release. There are translucent overlays of clever pointers to indicate where useful action commands are located.

Analytics and studies show that when presented with any of the above on launch of an application, a user either:

  1. Rushes through it with no interest in its content, or
  2. Closes it.

The main issue with providing informational assistance as the first screen is that users do not care yet. They have not seen enough of the product to want to learn about its intricacies.

Users want to get to the product as soon as possible; they’ve already read the marketing material, gone through the registration process, perhaps even read the “Terms and Conditions.”  They do not want anything else to lengthen the delay. If forced to read through preliminary content or go through tours, they do so while disengaged and hence, promptly forget all they learned.

Some applications have book-length help manuals. Immense thought and work goes into writing and creating these documents. But they exist in a separate world, removed from the application itself, expecting the user to click away from her task at hand to read and learn. Often, they are poorly designed, making the process of finding information in the “help” website a chore.

Can help intrude?

Handholding, intrusive help is as frowned upon in the design world as lack of intuitiveness. Examples of this include forcing open an overlay with offers of help while the user is engaged in a task; loading screens full of product descriptions without context; or launching a product tour that must be completed before the user can access the product. This is where the need to understand the goals of the application comes in.

Is this an enterprise application with cloud-based storage, multiple server connections, and sensitive data transfers? In that case, help should become a visible priority. What if it’s an app built with a strong gamification approach? In that case, help can probably take a passive backseat.

Consider user behavior patterns while designing the help function. Some users prefer an uninterrupted reading experience—they like to dive deep into the subject matter, read every instruction, perhaps even download the content for offline reading. They rely on in-depth topic descriptions. On the other end of the spectrum, some users prefer to scan the text. They only seek help after they’ve made a mistake and will rarely go to a dedicated off-context help website. Short bites of support within the application work best for them.

Instructions offered in a non-intrusive manner can enhance an experience, whether real or virtual. Hiking on a trail with clear path markers, distance indicators, wildlife cautions, and plant and foliage descriptions would be safe and informative and hence, helpful. The “x minute read” tag in Medium posts, the Slackbot messenger in Slack, and the delineations of simple steps in Google Apps Learning Center are all examples of help offered to users without distracting fanfare.

How to help

Simply ensuring your user assistance function is visible can be enough to provide comfort. In the same way a good interface doesn’t make users think too hard, a good help function should be easy to find and access.

Help can be designed to be contextual or stand-alone (a mix of both works best).

Contextual help is any form of user assistance that is embedded within the product’s screens. It prevents disruption from user’s immediate focus. It is concise and quick to read and access. It is available when the user requests or—even better—expects it.

A few examples:

  • Tooltips that appear on hover indicating the name of an icon or button.
  • Info-tips that open after clicking an “i” or “?” next to a form or field or any part of UI worth explaining. These should have brief content that explains the purpose/meaning of the relevant element.
  • Ghost text that appears within a text field or next to the UI element to help users learn about the element.
  • A panel that functions an an overlay within the product screen, providing users with more detailed help information.
  • Quick “Getting Started” guides that merge with the interface and take users through the actions flow.
  • Tooltips indicating feature upgrades within the UI.
  • Hint text that demonstrates search protocols—such as suggested keywords that actually work in the application.

Stand-alone help can take a more detailed approach.

Designing the help center for an application is usually a challenge. Should information architecture match the application’s architecture? How will users approach the content? Would they want every action and interface element documented? If so, how should the content be structured for easy perusal? If they don’t, how do writers prioritize topics? How much is too much?

Effective search functionality can help save users from getting lost in content; a prominent search box makes it simple to locate the right topic before users get overwhelmed. And if the application’s search option is internet friendly, it will appeal even more to those users who prefer using a “real” search engine (like Google or Bing).

Documentation categorized by features or tasks allows users to filter more quickly. It is also important to identify which information warrants greater visibility—help users solve their most pressing concerns, and quickly. Customer feedback, analytics, and user research can help determine which topics your users are looking for most.

The myth of technical proficiency

Enterprise applications as well as consumer applications can benefit from a well thought out help system. It’s poor logic to say that an interface is designed for “technically proficient” users who therefore won’t need any help.

A well-designed help function is more than a set of instructions in an emergency. It is thoughtful, approachable, and considerate. It knows that no quest for assistance is too small, no needed explanation is too big. It’s time we uprooted the precedents of cumbersome or “barely there” help functions. It is time to make Help helpful.

After all, needing help is part of the human condition.


This week's sponsor: Hired

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

Considering How We Use HTTP/2

A note from the editors: This article is part two of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part one, Using HTTP/2 Responsibly: Adapting for Users.

It’s important to remember that HTTP/2-specific optimizations may become performance liabilities for HTTP/1 users. In the final part of this series, we’ll talk about the performance implications of such a strategy and how build tools can help you manage HTTP/1- and HTTP/2-specific assets.

Our generalized example from the previous article shows how we can adapt delivery of site assets to a user’s connection. Now let’s see how this affects performance in the real world.

Observing performance outcomes

Developing a testing methodology

Low speed mobile connections are quite common in the developing world. Out of curiosity, I wanted to simulate HTTP/1 and HTTP/2 scenarios with my own site on an actual low speed mobile connection.

In a strangely fortuitous turn of events, I ran out of high speed mobile data the month I was planning to test. In lieu of extra charges, my provider simply throttles the connection speed to 2G. Perfect timing, so I tethered to my iPhone and got started.

To gauge performance in any given scenario, you need a good testing methodology. I wanted to test three distinct scenarios:

  1. Site optimized for HTTP/2: This is the site’s default optimization strategy when served using HTTP/2. If the detected protocol is HTTP/2, a higher number of small, granular assets is served.
  2. Site not optimized for HTTP/1: This scenario occurs when HTTP/2 isn’t supported by the browser and when delivery of content isn’t adapted in accordance with those limitations. In other words, content and assets are optimized for HTTP/2 delivery, making them suboptimal for HTTP/1 users.
  3. Site optimized for HTTP/1: HTTP/2-incompatible browsers are provided with HTTP/1 optimizations after the content delivery strategy adapts to meet the browser’s limitations.

The tool I selected for testing was sitespeed.io. sitespeed.io is a nifty command line tool—installable via Node’s package manager (npm)—that’s packed with options for automating performance testing. sitespeed.io collects various page performance metrics each time it finishes a session.

To collect performance data in each scenario, I used the following command in the terminal window:

sitespeed.io -b chrome -n 200 --browsertime.viewPort 320x480 -c native -d 1 -m 1 https://jeremywagner.me

There are plenty of arguments here, but the gist is that I’m testing my site’s URL using Chrome. The test will be run 200 times for each of the three scenarios, and use a viewport size of 320x480. For a full list of sitespeed.io’s runtime options, check out their documentation.

The test results

We’re tracking three aspects of page performance: the total time it takes for the page to load, the amount of time it takes for the DOMContentLoaded event to fire on the client, and the amount of time it takes for the browser to begin painting the page.

First, let’s look at total page load times for each scenario (Fig. 1).

Stacked bar chart of “Total Page Load Times” testing results for each of the three scenarios
Fig. 1: Total Page Load Times test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

This graph illustrates a trend that you’ll see later on. The scenarios optimized for HTTP/1 and HTTP/2 demonstrate similar levels of performance when running on their respective versions of the protocol. The slowest scenario runs on HTTP/1, yet has been optimized for HTTP/2.

In these graphs, we’re plotting two figures: the average and the 95th percentile (meaning load times are below this value 95% of the time). What this data tells me is that if I moved my site to HTTP/2 but didn’t optimize for HTTP/2-incompatible browsers, average page load time for that segment of users would be 10% slower 95% of the time. And 5% of the time, page loading might be 15% slower.

For a small and uncomplicated site such as my blog, this may seem insignificant, but it really isn’t. What if my site is experiencing heavy traffic? Changing how I deliver content to be more inclusive of users with limited capabilities could be the difference between a user who sticks around or one who decides to leave after waiting too long.

Let’s take a look at how long it takes for the DOM to be ready in each scenario (Fig. 2).

Stacked bar chart of “DOM Content Loaded Time” testing results for each of the three scenarios
Fig. 2: DOMContentLoaded Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

Again, we see similar levels of performance when a site is optimized for its particular protocol. For the scenario in which the site is optimized for HTTP/2 but runs on HTTP/1, the DOMContentLoaded event fires 10% more slowly than either of the “optimal” scenarios. This occurs 95% of the time. 5% of the time, however, it could be as much as 26% slower.

What about time to first paint? This is arguably the most important performance metric because it’s the first point the user actually sees your website. What happens to this metric when we optimize our content delivery strategy for each protocol version? (Fig. 3)

Stacked bar chart of “First Paint Time” testing results for each of the three scenarios
Fig. 3: First Paint Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

The trend persists yet again. In the HTTP/1 Unoptimized scenario, paint time is 10% longer than either of the optimized scenarios 95% of the time—and nearly twice that long during the other 5%.

A 10– 20% delay in page paint time is a serious concern. If you had the ability to speed up rendering for a significant segment of your audience, wouldn’t you?

Another way to improve this metric for HTTP/1 users is to implement critical CSS. That’s an option for me, since my site’s CSS is 2.2KB after Brotli compression. On HTTP/2 sites, you can achieve a performance benefit similar to inlining by using the protocol’s Server Push feature.

Now that we’ve examined the performance implications of tailoring our content delivery to the user’s HTTP protocol version, let’s learn how to automatically generate optimized assets for both segments of your users.

Build tools can help

You’re busy enough as it is. I get it. Maintaining two sets of assets optimized for two different types of users sounds like a huge pain. But this is where a build tool like gulp comes into the picture.

If you’re using gulp (or other automation tools like Grunt or webpack), chances are you’re already automating stuff like script minification (or uglification, depending on how aggressive your optimizations are.) Below is a generalized example of how you could use the gulp-uglify and gulp-concat plugins to uglify files, and then concatenate those separate uglified assets into a single one.

var gulp = require("gulp"),
   uglify = require("gulp-uglify"),
   concat = require("gulp-concat");

// Uglification
gulp.task("uglify", function(){
   var src = "src/js/*.js",
       dest = "dist/js";

   return gulp.src(src)

// Concatenation
gulp.task("concat", ["uglify"], function(){
   var src = "dist/js/*.js",
       dest = "dist/js";

   return gulp.src(src)

In this example, all scripts in the src/js directory are uglified by the uglify task. Each processed script is output separately to dist/js. When this happens, the concat task kicks in and bundles all of these scripts into a single file named script-bundle.js. You can then use the protocol detection technique shown in part one of this article series to change which scripts you serve based on the visitor’s protocol version.

Of course, that’s not the only thing you can do with a build system. You could take the same approach to bundling with your CSS files, or even generate image sprites from separate images with the gulp.spritesmith plugin.

The takeaway here is that a build system makes it easy to maintain two sets of optimized assets (among many other things, of course). It can be done easily and automatically, freeing you up to focus on development and improving performance for your site’s visitors.


We’ve seen how an HTTP/2-optimized site can perform poorly for users with HTTP/2-incompatible browsers.

But why are the capabilities of these users limited? It really depends.

Socioeconomic conditions play a big role. Users tend to buy the quality of device they can afford, so the capabilities of the “average” device varies significantly, especially between developing and developed nations.

Lack of financial resources may also drive users to restricted data plans and browsers like Opera Mini that minimize data usage. Until those browsers support HTTP/2, a significant percentage of users out there may never come on board.

Updating phone applications can also be problematic for someone on a restricted data plan. Immediate adoption can’t be expected, and some may forego browser updates in favor of preserving the remaining allotment of data on their plans. In developing nations, internet infrastructure quality is significantly behind pace with what’s in the developed world.

We can’t change the behavior of every user to suit our development preferences. What we can do, though, is identify the audience segment that can’t support HTTP/2, then make an informed decision whether or not it’s worth the effort to adapt how we deliver content to them. If a sizeable portion of the audience uses HTTP/2-incompatible browsers, we can change how we deliver content to them. We can deliver an optimized experience and give them a leg up, and we can do so while providing performance advantages for those users who can support HTTP/2.

There are many people out there who face significant challenges while browsing the web. Before we fully embrace new technologies, let’s figure out how we can do so without leaving a significant segment of our audience in a lurch. The reward in what we do comes from providing solutions that work for everyone. Let’s adopt new technologies responsibly. It behooves us all to act with care.

Further reading

Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.

Using HTTP/2 Responsibly: Adapting for Users

A note from the editors: This article is part one of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part two, Considering How We Use HTTP/2.

With HTTP/2 ticking up steadily in use, it’s clear that there’s something to this long overdue update to the protocol. Implementing it, however, not only changes how websites are delivered to the user, it demands that we think critically about how we migrate existing sites to the protocol. More importantly, it demands that we consider our users’ capabilities.

Whether you’ve already migrated your site to HTTP/2 or you’re bracing yourself to take the plunge, there are challenges when it comes to tuning your site’s front end architecture to be the most performant it can possibly be for all your users. Perhaps you’ve read about what it takes to get your site ready for HTTP/2. Perhaps you haven’t. If the latter describes you best, it’s not worth getting into the weeds here. The gist of it is that HTTP/2 optimization patterns are the opposite of those for HTTP/1. Your site will perform better on HTTP/2 if you avoid practices that combine files, because caching for those resources will be more efficient when they change.

In order to cope with the limitations of the aging HTTP/1 protocol, we were more than willing to sacrifice some degree of caching effectiveness for return visitors in order to speed up the initial loading of a site. Thus, techniques like scripts and CSS concatenation, image sprites, and inline assets were embraced. In a world that’s creeping toward HTTP/2, however, we’re told to abandon these practices —and for the most part, rightly so.

The reality of the situation can be more complex than we initially thought. While HTTP/2 support on both the server and client side is steadily increasing, browsers that can’t understand the new protocol will linger on for some time yet—and that doesn’t just mean Internet Explorer. It also includes browsers like Safari on older versions of OS X, UC Browser, older versions of Android Browser, and Opera Mini.

Sometimes we hurt the ones we love

HTTP/2 support is not a one-sided affair. In order for it to work, the server must not only implement it, but the browser must also be capable of understanding the new protocol. When a browser that understands HTTP/2 begins requesting content from an HTTP/2 server, the exchange will predictably occur in, well, HTTP/2. In the case of an older browser like Internet Explorer on Windows 7 (or even a current browser such as Opera Mini), the conversation proceeds in HTTP/1. The underlying mechanism that drives this behavior is nuanced, but it can be considered progressive enhancement in that we’re not breaking the experience for users on platforms that can’t use HTTP/2. They’re merely getting a less optimal experience.

Whether you’ve made the jump and optimized your site for HTTP/2 already, considering the jump from HTTP/1, or somewhere in between, it can pay (sometimes quite literally) to understand how these optimizations can impact your site’s users. Depending on your audience’s capabilities, a site optimized for HTTP/2 may well be detrimental for a segment of your audience.

HTTP/2 enjoys broad support among users in the global sense. According to the popular feature support index site caniuse.com, HTTP/2 currently enjoys support of roughly 78% of all browsers currently in use. Some fringe browsers such as IE 11 below Windows 10, and Safari on OS X below El Capitan muddle the picture a bit. You can count on at least 72% of users globally to support HTTP/2 (at least at the time of this writing).

Of course, this is just the big picture, and it isn’t an indicator of what your specific audience looks like. You need to consider the source of your visitors and what browsers they tend to use. You also need to consider where your users reside in the world.

In the rudimentary statistics I’ve compiled from caniuse.com, I’ve found that users in developing nations tend to use browsers that don’t support HTTP/2 more often than those in developed nations. Following that up with statistics from Akamai’s Q3 State of the Internet Report, developing nations generally have a lower quality of internet infrastructure than developed nations. I won’t get into the data here (though you can have a look for yourself), but if you’re curious, you can check out this short write-up I’ve done on the subject to get some context.

The confluence of these two truths creates a challenge in how we optimize sites for our visitors.

  • Even if you set up a web server that uses HTTP/2, there’s a segment of your audience that won’t receive the benefits because their connection to your server will be over HTTP/1.
  • Even worse, if you’ve optimized your site for the best performance on HTTP/2, you’ve likely made your website slower for users with older browsers.

“Aw, hell! They should just upgrade their browser!” While some of us have said this at one time or another out of utter frustration in the face of solving a challenging problem, this is a terrible sentiment. It presupposes that the user has the ability to upgrade their browser, but they’re just too damn lazy to get around to it.

The more likely problem is that users in developing nations are reliant on antiquated infrastructure or bound to a restricted data plan that makes this impractical. We need to be empathetic to this reality. It behooves you to know how many of your users are running HTTP2-capable browsers, and how many aren’t. All you need to determine this is a Google Analytics account and caniuse.

caniuse is able to comb through your site’s visitor data, then give you the status of support for a particular browser feature in the context of your site’s visitors, rather than for a particular country. Perfect for determining browser support for HTTP/2 in your audience! By opening the settings panel in the site and then clicking the “Import” button under the “From Google Analytics” header, you’ll be prompted to allow caniuse to access your analytics.

Here’s a real world scenario in which I’ve used this tool to determine an audience’s HTTP/2 support: My friend runs a reasonably popular blog about guitars and guitar accessories that receives roughly 30,000 pageviews per month. When I fed the site’s Google Analytics data into caniuse, it showed that the site’s audience over the most recent 30 day period had about 91% support for HTTP/2 (Fig 1).

Visual comparison of two equations: All Web Site Data (78.47% + 12.27% = 90.74%) and Global (70.13% + 5.95% = 76.08%)
Fig. 1: caniuse.com’s support threshold for HTTP/2 for a specific site, labeled “All Web Site Data.”

91% seems like a high level of support for HTTP/2 —and it is! Despite that fact, you must take into consideration the raw number of pageviews from browsers fetching resources over HTTP/1 because they don’t support HTTP/2.

Some basic math reveals that this segment represents 2,700 pageviews per month. Furthermore, the quoted support of 91% includes browsers that partially support HTTP/2. In this specific example, we can only be absolutely certain that around 78% of this site’s visitors support HTTP/2. This means that anywhere from 2,700 to 6,600 pageviews may be served over HTTP/1. The actual number is somewhere in between, and even though this is a minority of users, it’s still a significant number of pageviews on its own, and it may be too large for you to simply ignore.

Adapting your users’ limitations

By this point, we know three things:

  1. HTTP/2 servers will downgrade to HTTP/1 when responding to HTTP/2-incompatible browsers.
  2. HTTP/2-specific front-end architecture optimizations are usually detrimental to users on browsers that are HTTP/2-incompatible.
  3. Users in developing nations tend to have a lower level of support for newer browser features like HTTP/2, and tend to have slower internet connection speeds.

The only thing we don’t know at this point is how to fine-tune our content delivery so that it’s beneficial for everyone. Before we can really think about modifying how content is delivered to the user, there are a couple of things we should consider first.

Is HTTP/2 right for you?

Assuming you haven’t already migrated to HTTP/2, there are a few things to take into account before you invest time and resources into making the switch:

  1. While the HTTP/2 specification doesn’t explicitly require SSL, it is a de facto standard in that browsers require it. If you implement HTTP/2 on your server and fail to install a valid SSL certificate, the connection will always downgrade to HTTP/1. For the budget-conscious, certificates range from reasonably priced to 100% free via Let’s Encrypt. Even with free certificates, implementing SSL still represents a cost to your organization. It takes time and effort in the form of QA testing to ensure that existing sites aren’t broken in the migration.
  2. If your site’s footprint is very small, HTTP requests are few, and upgrading to SSL isn’t pragmatic, you may already be well-served by HTTP/1. This is especially true if you’ve implemented HTTP/1-specific optimizations and it would cost significant developer time to unravel them into HTTP/2 optimizations. This doesn’t mean that you shouldn’t upgrade to SSL, though.
  3. If most of your site’s audience uses browsers that can only support HTTP/1 and your site is well-optimized for it, you’re probably already well-served by HTTP/1. But again: consider SSL anyway.

Let me be totally clear: HTTP/2 is an excellent performance enhancement for large, complex sites with lots of assets that would otherwise perform poorly on HTTP/1. We just need to talk about how you might be able to mitigate some of the pain for users with less capable browsers, and that begins with identifying those users when they visit.

Checking for HTTP/2 and adapting to users’ needs

How you deliver content based on a given user’s HTTP protocol version depends on what technologies you have available on your host. You’ll usually use a back end language like PHP to modify the markup you send to the client. Regardless of the technology you use, there are two conditions you’re covering:

  1. If the user is on HTTP/2: You’ll serve more and smaller assets. You’ll avoid stuff like image sprites, inlined CSS and scripts, and concatenated style sheets and scripts.
  2. If the user is on HTTP/1: You’ll do the opposite. You’ll bundle files, use image sprites, and inline small assets.

The specific mechanism by which you detect HTTP/2 support will depend on the back end language you use. In PHP, we can determine the protocol version of a given connection by checking the $_SERVER["SERVER_PROTOCOL"] environment variable. Below is a one-liner that stores the HTTP/2 connection status in a variable named $isHttp2:

$isHttp2 = stristr($_SERVER["SERVER_PROTOCOL"], "HTTP/2") ? true : false;

Using the stristr function, the $_SERVER["SERVER_PROTOCOL"] environment variable is checked for the presence of the substring "HTTP/2". If the substring exists, $isHttp2 is set to true. If not, it’s set to false. From here, it’s up to you to apply this logic to your site, but let’s look at a couple of things you could do. For instance, you could add a class of http1 to the


if ($isHttp2 === false) {
	?><html class="http1"><?php
} else {

Using this class, you can adapt your CSS to serve an image sprite for HTTP/1 users, and individual images for your HTTP/2 users. Or maybe serve a separate CSS file with inlined assets using the data URI scheme. Speaking of serving different files, you could change your markup based on the user’s protocol version to change how you serve assets to the client:

if ($isHttp2 === true) {
	<script src="/js/script-1.js"></script>
	<script src="/js/script-2.js"></script>
	<script src="/js/script-3.js"></script>
} else {
	<script src="/js/script-bundle.js"></script>

Or you could change your markup to inline some critical CSS for HTTP/1 users with the handy file_get_contents function:

if ($isHttp2 === true) {
	<link rel="stylesheet" href="css/critical.css">
} else {
	<style><?php echo(file_get_contents("css/critical.css")); ?></style>

Of course, on HTTP/2 sites, you would take any content that you’d normally inline and use server push to confer the benefits of inlining without actually inlining content. How you specifically adapt your site’s content delivery based on the visitor’s protocol version really depends on your specific situation.

This concludes the first article! In part two of this series, we’ll:

  • Apply these techniques to a real world scenario
  • Use a performance testing tool to check for meaningful comparisons se a build system to generate HTTP/1-friendly assets so you can keep your workflow clean and efficient.

Further reading

Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.

This week's sponsor: FullStory

FullStory, the CX platform that captures every interaction on your site for pixel-perfect playback. Get it free, forever. For real.

Gaming the System…and Winning

Good intentions usually drive the “gamification” of websites—adding points, badges, and leaderboards to make them more engaging. It sounds like a great idea, but borrowing game design elements out of context is a risky way to design experiences, especially experiences intended to bring users back to a site.

Not everyone wants to spend more time on your site just to get a badge; some people simply aren’t motivated by such extrinsic rewards. When game designers include elements intended to promote deeper engagement, they look at their users through a very different lens than those of us in web design. Understanding how and why they do this can help us craft more engaging web experiences.

A game designer and a web designer looking at the same user research will most likely come up with totally different personas. Talking about many people as though they were one person can be a strength;it gives a clear vision of who we need to serve. But it’s also a limitation because this method of clustering requires us to pick certain axes and disregard others. Web designers cluster people by their needs and abilities, but in doing so, we tend to disregard their personalities. Game designers are more likely to fixate on interaction styles; they embrace personality.

Let me show you what I mean. Pokémon Go has seen a meteoric rise in popularity since its release, possibly because of how well it caters to people with different personalities. In Pokémon Go, people who like to compete can “battle” in gyms; those who prefer to collaborate can go on “pokéwalks” together; and anyone with a drive to explore and push boundaries can try to “catch ’em all.” Even if a player enjoys all of these options, they’re likely to find one more motivating than the others. Ensuring that the game caters to each interaction preference enhances its appeal to a wide audience.

The same is true of web design. Adding gamification elements to draw in more visitors—but only elements that cater to competitive people—can overlook the wider audience. UX design that doesn’t target a variety of interaction styles is going to be hit-or-miss.

Game designers (and educators and psychologists) segment people in ways that complement web design and user experience. I’ve put together this guide to show you how they think and how (and where and why) we can use their models. Along the way, I’ll show how those models might overlap to create one bigger framework that we can use to pinpoint strengths and weaknesses in our designs.

Making it fun

Emotional design—the practice of moving interfaces beyond merely usable—is a growing field of interest among UX designers. (I highly recommend Designing for Emotion and Seductive Interaction Design.) Unsurprisingly, game designers have a theory of fun, too.

A recent study performed a contextual inquiry of hardcore and casual gamers, plus interviews with their friends and family members, identifying four types of fun (PDF) that relate to interaction preference.

  • Hard Fun comes from pursuing a goal—earning rewards according to progress.
  • Easy Fun focuses on something other than winning. It encourages learning and emphasizes feelings of wonder, awe, and mystery.
  • The People Factor caters to interaction with others; the interface becomes a mechanism for social engagement.
  • Altered States attract people to engage in a social context to feel something different (e.g., to gain pleasure from acting upon or inciting those around them).

These styles are easy to spot on social networking sites:

  • Competing for likes or followers (as on Twitter) is Hard Fun.
  • Casually browsing to find humorous new posts (as on Tumblr) is Easy Fun.
  • Engaging with a social network to connect with other people (as on Facebook) is a People Factor.
  • People who experience excitement from messing with other people (as on Reddit) are enjoying Altered States.

Bartle’s four player types

There are numerous ways of grouping people by interaction style, including Hallford and Hallford’s six categories of player behavior and Yee’s statistical clustering of three player types (PDF), but I find that these approaches roughly map to Richard Bartle’s 4 player types (particularly the three non-Troll ones). Bartle’s theory is among the most common approaches chosen by game designers (Fig 1).

Fig 1: Bartle’s player types are one common way that game designers segment player experiences.

Suppose you have an ecommerce site for people to buy snakes. An Achiever may be motivated to engage by extrinsic factors: How many snakes can she collect? How many reviews of snakes can she write? The Explorer may be motivated by learning more about snakes: What’s the length specification on the new python? Where can she read more about novel uses of snakeskin? The Socializer will be motivated by interactions with others: What types of snakes are her friends buying? Is there a discussion forum where she can connect with others over her love of snakes? And you’ll probably have to deal with a couple of teenaged Trolls who just want to make fun of everyone else’s snake-buying experience.

Bartle also examines pairwise interactions between player types. This leads him to the following sorts of conclusions:

  • The ratio of Achievers to Trolls is like the ratio of rabbits to wolves. When there are too many Trolls, the Achievers leave, but without interesting victims, the Trolls leave and the Achievers return.
  • Providing opportunities for exploration is key. When there aren’t enough Explorers finding new things and telling others about them, the Achievers eventually get bored and leave, causing the Socializers and Trolls to leave, as well.
  • Trolls keep the Socializer population in check. To reach the widest audience possible, a few Trolls are necessary because they keep the Socializer population from expanding exponentially and pushing out the Achievers and Explorers. (The only other stable equilibria involve fewer player types: either a balance of just Trolls and Achievers or else a community almost exclusively composed of Socializers.)

Motivating people

Another way of segmenting people is by identifying what motivates them. At a recent conference, I saw a presentation of a study of a mobile fitness coach. The presenters said that people’s motivations for exercise tend to cluster into distinct categories. Bartle himself didn’t focus much on motivation, so it was fascinating to see how closely the presenters’ categories align with Bartle’s: one extrinsically motivated, one self-motivated, one socially motivated.

In addition to the two dimensions considered by Bartle (Players versus World and Acting versus Interacting), a third axis should be taken into account: the players’ motivations for choosing to engage. Unlike the binary nature of acting OR interacting with the player OR the world, motivations fall along a spectrum of intrinsic and extrinsic motivation (Fig 2).

Fig 2: Each player type falls on a spectrum from intrinsic to extrinsic motivation.

Ryan and Deci’s Self Determination Theory (PDF) is a framework illustrating how player types vary according to source of motivation (Fig 3).

Fig 3: Ryan and Deci represent levels of motivation.
(adapted from Ryan & Deci, 2000, p. 61)

How we can motivate people to engage with a site or app depends on where their interaction style falls along this spectrum. What player type we cater to also determines how likely people are to stick around.

  • We can motivate Achievers (or the Achiever side of people) by adding extrinsic metrics they can use to compete with others. Achievers, being extrinsically-motivated, will eventually grow bored and leave. Gamification techniques like points, badges, or leaderboards motivate Achievers extrinsically but can also give them a way to measure their growing competence (encouraging intrinsic motivation).
  • Explorers set their own goals and are self-motivated to interact with your website. Because they’re intrinsically motivated by enjoyment of the task itself, they tend to stick around longer. (Bartle says that changes in numbers of other player types doesn’t usually impact the number of Explorers.) To promote long-term engagement of Explorers, it helps to introduce unexpected achievements. Hinting that there are some Easter Eggs hidden in your site could be a great way to encourage explorers to stick around.
  • Socializers will stick around as long as there’s enough social interaction for them. We can motivate them by adding ways to add their own thoughts to site content, such as comments on an epublishing site or reviews on an ecommerce site. If they don’t get enough external feedback from other people, they’ll leave. Adding a way to “Like” reviews or respond to other users’ comments can help to provide this feedback.
  • Trolls set their own goal of annoying other users, but they require feedback from others to know that they’re actually being annoying. The expression “Don’t feed the Trolls” means removing this feedback loop, which we can do with moderation tools and community posting guidelines.

How you choose to present rewards will encourage people with different preferred interaction styles to engage with your product. Conventional cognitive psychology wisdom suggests that irregular rewards at irregular intervals motivate continued engagement most effectively. (Expected rewards can be problematic because if people know that a reward is coming, they may work for the reward rather than focusing on the task itself.) Yet, having a variety of expected rewards can help people set goals, thus promoting Achievers.

Helping people learn to use your site

When we make fairly complicated sites, people may cycle through different player types as they learn to engage with them.

To see what I mean, consider the Experiential Learning Cycle of Kurt Lewin, which contains four stages (Fig 4).

Fig 4: Lewin shows how we learn.

Viewing this cycle through Bartle’s player types, it’s possible to align player characteristics with aspects of Lewin’s cycle: Achievers concretely experience the world, Explorers reflect upon what they see, Socializers abstract the world into a context they can discuss, and Trolls premeditate their approach to interactions. This mapping also works with Bartle’s axes (Fig 5).

Fig 5: Lewin’s learning model can be overlaid upon Bartle’s player types.

For example, someone coming to a large content site focused on do-it-yourself projects might initially be motivated to engage by their own experience with home improvement. Once they’ve engaged regularly with the site for a time, they might move to a more reflective mode, exploring more of the site. If they really get interested, they might join in the discussion forum, discussing projects with others, and this discussion will give them new ideas for projects they can create in their own life. Application of the ideas to the real world moves back to the Achiever quadrant, but may impact people in that world as well (the Troll quadrant). Thus, if we want people to engage deeply with a site or app over time (learning different aspects of it) it helps to support the many different interaction styles that people may use to engage while learning.

Making it engaging

Of course, when we make websites, we often talk about supporting immersion through an experience of flow. Game designers again bring light to this form of interaction. Salen and Zimmerman, authors of the seminal textbook on game design, note that four parts of Mihaly Csikszentmihalyi’s flow model are necessary for flow to occur:

  • Challenge
  • Goals
  • Feedback
  • Control

All four player types need all four of these to engage fully, yet each prerequisite of flow might be aligned with a player type and learning stage (Fig 6). 

Fig 6: Csikszentmihalyi’s four prerequisites of flow can be mapped to the same axes as Bartle’s player types.
  • Achievers seek challenge. (They don’t set their own goals as much as Explorers, but will tackle whatever extrinsic challenge you put in front of them.) Challenge is actively experienced.
  • Explorers set their own goals to create challenge for themselves. These goals project into the future with reflection upon observation.
  • All players need feedback from the game, yet Socializers thrive upon feedback from other players.
  • Trolls seek control. (To prevent trolls, building in some form of moderation system is a way of taking away their control.)

For example, a photo-sharing site might create an immersive experience by challenging people to upload a certain number of photos, letting them set their own goals for organizing content, allowing other people to give feedback about the quality of the photos or collections, and giving everyone a comfortable sense of control over their own photos and collections. Introducing artificial difficulties, like saying “Try only uploading black and white photos this week” can make the experience more game-like, presenting a challenge that people can choose to use as their own goal or not.

Bringing it all together

Here is a fully overlaid model based on my own interpretation of how they’re related (Fig 7).

Fig 7: All of the models can be overlaid upon each other to form a diagnostic tool.

This model might be expanded further using other four-part models from game design such as Hallford and Hallford’s four reward types or Callois’s four game types. To examine how people progress through the learning stages, we might overlay David Kolb’s Experiential Learning Cycle (which is built upon Lewin’s model for learning).

I haven’t tested all the variables here, but I hope that this grouped model can be a useful diagnostic tool, as I’ll show with the following three examples. (If you encounter evidence supporting or refuting this way of overlaying the models in your own work, please leave a comment at the end of the article explaining what you’ve found.)

The model suggests that if a new feature does not succeed right away, it may largely be due to the interaction styles of the people engaging with the site or app. For example, on a start-up site I worked on, the most engaged users were the ones who had created their own reviews. When we added a discussion forum, it initially didn’t get a lot of use. One possible diagnosis of this slow beginning is that most of the people we’d attracted were Achievers, who learned through their own experiences and enjoyed the challenging hard fun of seeing who could write the most reviews. We dialed back the discussion experience to focus the site more directly on these Achievers. Another approach might have been to add a competitive element to the discussion itself; you’ve probably seen forums that rank their participants, which is a way of luring Achievers to be more social (and thus creating a more diverse community for Socializers).

The Troll quadrant is certainly the one least directly mapped to by other models. One possible explanation of this is that we try not to design for Trolls. An explanation I consider more likely is that in a socially-moderated setting, there’s little opportunity for Trolls to exist. If your site is having difficulty with Trolls, the model suggests that making it more difficult for people to act upon people can mitigate the problem. Moderation tools can take away the control that trolls require, making it difficult for them to create altered emotional states.

Bartle found that Explorers are rare and difficult to attract, but necessary for the long-term survival of a site. They’re the ones who try out new features to give the rest of the community things to do and discuss. One conventional approach to trying to increase site engagement is to add “gamified” elements, such as points, badges, and leaderboards. But such an approach may actually harm long-term engagement because such extrinsic motivators are unappealing to the Explorers who help the community evolve. Looking at what interaction types a site appeals to and then adding elements to appeal to others can help the site to grow a well-rounded, sustainable audience.

There’s much more that can be brought from games to make the web fun and meaningful. I hope that a greater understanding of how game designers make experiences engaging can empower web designers to craft a more intriguing and inviting web for a wide variety of people.

This week's sponsor: GatherContent

GATHER CONTENT: Stop content delaying website launches with custom collaborative online templates and workflow. Try it free!

Guerrilla Innovation

In a culture like Google’s, having paid time to innovate is celebrated. But most of us don’t work at Google; most of us work at places that are less than thrilled when someone has a bright new idea that will be amazing.

After all, who has time to try new things when the things we’re doing now aren’t broken? No one wants to be forced to use another app, to have yet another thing they are expected to log into, only to see it die out in six months.

So how do you push an idea through? How can you innovate if you work in a less-than-innovative place?

It takes more than a big idea

Let’s say you just saw a demo of someone using a prototyping tool like UXPin and you’ve got this big vision of your team incorporating it into your development process. With a tool like this, you realize, you can quickly put some concepts together for a website and make it real enough to do user testing within two days! Seems pretty invaluable. Why haven’t we been using this all along?

You create an account and start exploring. It’s pretty damn awesome. You put a demo together to share with your team at your next meeting.

Your excitement is completely drained within five minutes.

“Seems like a lot of extra work.”

“Why would we create a prototype just to rewrite it all in code?”

“Let’s just build it Drupal.”

Knife. In. Heart.

You can see the value in the product, but you didn’t take the necessary steps to frame the problem you want to solve. You didn’t actually use this exciting new tool to build a case around the value it will have for your company.

So right now, to your coworkers, this is just another shiny object. In the web development world, a new shiny object comes along every couple seconds. You need to do some legwork upfront to understand the difference between what shiny object is worth your team’s time and what is, well, just another shiny object.

Anyone can come up with an idea on the fly or think they’re having an Oprah Aha! Moment, but real innovation takes hours of work, trying and failing over and over, a serious amount of determination, and some stealth guerrilla tactics.

Frame the problem

The first step in guerilla innovation is making sure you’re solving the right problem. Just because your idea genuinely is amazing doesn’t mean it will provide genuine value. If it doesn’t solve a tangible problem or provide some sort of tangible benefit, you have little or no chance of getting your team and your company to buy into your idea.

Coolness alone isn’t enough. And “cool” is always up for interpretation.

Framing the problem allows you to look at it from many different angles and see different solutions that may not have occurred to you.

By diving deep into the impact and effects your idea will have, you will start to see the larger picture and may even decide your idea wasn’t so amazing after all. Or, this discovery could lead you to a different solution that truly is innovative and life-changing.

Start at the end

When your idea is implemented and everything goes as planned, what benefit will it provide?

Make a list of people who would theoretically benefit from this idea. Write down who they are and how the idea would help them.

Let’s go back to our prototyping tool example. Who would benefit from it the most? The end user looking for specific content on your website. Using a prototyping tool would allow you to do more user testing earlier in the process, letting you tweak and iterate your design based on feedback that could improve the overall site experience. An improved experience would, ideally, allow visitors to find the content they are looking for more easily; the content would therefore be more useful and usable for them.

If visitors have a better experience, that could result in a better conversion rate—which in turn would help your manager’s goals as web sales improve.

That benefit could extend to your team as a whole, too: a prototyping tool could improve communication between the marketing group and the development group. Using a prototyping tool would help quickly visualize ideas so that everyone can see how the site is evolving. Questions could be asked and addressed sooner. A prototyping tool could be just the thing you need to get everyone on the same page about content and identified goals.

Identify your target audience(s)

The top two audiences with the potential to get the most benefit from your innovative idea are your target audiences. If the end user of the website will receive the most benefit, then that is your primary target audience. If your manager receives a benefit as a result, then that is your secondary target audience.

Take some time to develop a persona around each of your top target audiences. A persona is a document that summarizes research trends and data that have been collected about a key audience segment. Although a persona depicts a single person, it should never be based on one real individual; rather, it’s an amalgam of characteristics from many people in the real world. A persona is usually one page and includes characteristics such as attitude, goals, skill level, occupation, and background. For more on developing personas to improve user experience, check out Usability.gov.

When you’re waist deep in this idea in the next six months and your coworkers are complaining about the extra workload, and you’re wondering why you ever decided to do this you will look at your white board where you have your personas displayed and you will remember they are your target audience, not you. All of this extra work is for their benefit.

As you implement a workflow using a prototyping tool and the decision gets made to only do only one round of user testing instead of the three rounds that were initially discussed, you can reference your personas and ask who stands to benefit from that decision. Are you just saving time for the developers and the stakeholders in an attempt to pump out websites faster? Or will this really benefit the target audience?

Do a pre-postmortem

Understanding the risks of innovation does not mean backing away from your idea and giving up. When you understand the obstacles in front of you, you can more easily identify them and develop solutions before potential failures take place.

One useful exercise is to do a postmortem report even before you begin. Start anticipating the reasons the tool or project will fail so you can avoid those pitfalls. Some questions you might ask in a postmortem:

  • Who was involved in the project?
  • What went well with the project?
  • What did not go well?
  • What can we do next time to improve our results?

With our prototyping example, a possible reason for failure might be the team not adopting the tool and it never gaining traction. You need the team to be on the same page and using the same workflow; lack of adoption could be detrimental to progress.

Analyze your current situation

What sorts of effects are you seeing right now because of this identified problem? Gather some data to prove there is an actual problem that needs to be addressed. If your help desk continually receives calls about users unable to find a specific button on your website, for example, then you have some evidence of a bad user experience.

Do some research

Ask your coworkers what they know about prototyping. Ask if they have ever experimented with any prototyping tools.

Ask your end users about the content on your site. Gather some information about just how bad the user experience really is.

This is not the time to pitch your idea. You are in complete listening/observation mode. Save the elevator pitch for later, when you have all the information and are confident this is the right solution to a very specific problem and you are prepared to answer the questions that will come.

Assess your tools

Are there any tools you use now that are similar to the tool you are proposing? If so, what are their benefits and downfalls?

Take the UXPin example. Does your team use paper to do prototypes right now? Does the graphic designer use Photoshop to start with wireframes/prototypes before doing a high-res layout?

Having a ready list of pros and cons for the tools you currently use will help you build a case around why your solution is superior and will show that you’ve done your homework.

Check your ego

Scrutinize your motivations for wanting to introduce a new tool. Do you want to try something new just to take control of a situation? If the graphic designer does a fine job using Photoshop to develop a prototype but you don’t know how to use Photoshop, that’s not a great reason to try a new tool.

However, if you have a team of six and only one person knows how to use Photoshop, choosing a more accessible tool with a shorter learning curve could be the right move.

Explore other solutions

Are there other tools out there that will solve the problem you discovered?
If you don’t yet have room in the budget for UXPin, can something else get you by while you prove the value of this type of tool? can you use paper prototypes for a few months while the team adjusts to this new part of their workflow?

Sometimes starting with something less complex can be beneficial. Anyone can use pen and paper, but learning new software can be daunting and time-consuming.

Still think this is an awesome idea?

You now understand the tangible benefits of implementing your innovative idea and you know who stands to gain from it. You can foresee both the rewards of implementing it and the potential risks of not implementing it.

Your motives are good, you’ve analyzed your current situation for similar tools or processes that may already be in place, and you’ve explored other potential solutions. You are well on your way to building a strong case around your innovative idea. At this point, you’ve put a lot of time and effort into developing it. Do you still think it’s a good idea, and are you as excited as you were when you started?

If you’ve lost your drive and excitement at this point, or have been unable to visualize any real benefit, the idea may not be worth implementing. That’s okay. The way you will land on a really great idea is by testing many not-so-great ideas until you find one that fits.

Your continued excitement and drive will be necessary as you start to implement your idea and work toward gaining supporters.

Start small and fail as soon as possible

Even if you’re still quite sure this idea is amazing, start small and keep an open mind. A thousand questions will come to mind as you begin using an actual product with real users.

As you start running a couple of tests, use language like “experiment” instead of “implementation.” This leaves room for error and growth. You want to know what’s not going to work as much as you want to know what is going to work. And if someone asks what you’re doing, it sounds way more innocent if you say you’re running a few experiments that you’re going to share with the team than if you say you’re implementing a prototyping tool into our web development process.

If you’re working on a current website project, try creating just one page using the prototyping tool on your own time, not as a part of the official project process. See how it goes building just one page for now. Even better, try making just one element of the page, like the header or navigation. By starting small you will have fewer variables to take into consideration. Remember, right now you’re evaluating the tool itself, not necessarily the user experience of your website.

Then take your prototype and see what kind of feedback you can get by testing it with real end users.

Is the prototype responsive? What URL did you need to use to access it? Was it easy to direct users to this URL? Can you record mouse movements or clicks, and do you need to? How are you documenting their feedback to the site? Were they able to use their own device, or did you need to provide it? What are you going to do with the feedback and observations you’ve gained?

Do several tiny experiments like this, making adjustments as you go, until you’re more comfortable with the tool, its features, and the results you get from it. Your confidence with the tool will give your team confidence with it as well.

Don’t get fired

Most companies don’t mind their employees doing research about their work on company time. Unfortunately, some do mind. Using your own device on your lunch hour or before and after work may be your only option.

Even if your job does allow you to research and learn on the clock, be respectful of time. Spending several months straight iterating on one idea might not be good for your next employee review. 3M designates 15 percent time for employees to focus on innovation; Google has famously allowed up to 20 percent of employee time to focus on new innovative ideas. Try to gauge what percentage of time you could reasonably spend on your research without neglecting your real job.

Be transparent about what you’re doing. Hiding it and sneaking around will give the wrong impression. Let your boss know you’re curious about a new tool and you’re just running a few experiments to explore it more. Curious, experiment, explore—as I suggested earlier, these are all safe words implying no level of commitment or pressure.

Win allies

Presumably you have a few friends in the office; take them out to lunch and toss them the idea. Let them know about the experiments you’re running and the results you’re getting. Ask if they want to see what you’ve been working on.

It might take a while for anyone to show some interest. Don’t give up if your excitement isn’t mirrored immediately and don’t be pushy. Remember, you want your colleagues to be in your corner.

Also, bouncing your idea off your coworkers is great practice for telling your boss. Your coworkers will definitely ask you a bunch of questions you haven’t thought of yet and will express viewpoints you haven’t considered.

Listen to their opposition and use their concerns to build your case. Do they think adding a new tool to the workflow will slow down the process? Explore that concern; next time you talk, offer some data and insight about how that assumption might not be true.

Having your team on your side will go a long way when presenting this to your boss, but it doesn’t have to be a deal-breaker if they’re not. Sometimes our coworkers are just so scared of change that no amount of data will make them comfortable. They will likely express their concerns when you bring your idea up in front of the boss; having a prepared response makes you look confident.

Get your boss’ support

Time to go up a level. Please do not put together a giant presentation, wear your best power suite, and pour your heart out onto the line. If your experience is anything like mine, you’ll just spend the rest of the day crying off and on in the bathroom.

A definitive, polished presentation can be offputting. It makes you look like you’ve already solved the whole problem. You want to appear open to suggestions—because you are.

The approach

You know your relationship with your boss, and how to approach them, better than anyone else. For me, the best way is to wait for the right opening and mention the new idea in passing. Be prepared to show all of your progress and make some sort of proposal right on the spot. Make it seem easy and low-risk, with clear next steps. I’ve found it beneficial to address the concerns of your team up front to show you value their opinion and input. Bosses love teamwork.

If there isn’t clear interest from your boss, ask them what other data or information they would like to see to help support this idea. What are their concerns or hesitations?

At this point, consider asking for permission to continue to experiment on a broader level. The word “implement” really freaks people out. Trying a prototyping tool in the web-development process for three months instead of implementing it forever sounds a lot less risky.


If you can’t stick with your idea long enough to do some research and run some experiments, why should anyone else? If it truly matters to you and you can see your idea making a real change in your company or within your work environment, hang in there for the long haul.

When the graphic designers agree to use UXpin as a prototyping tool and the User Experience team (if you’re lucky enough to have a UX team, really I’m not jealous) says they will give it a try for end user testing, ask to be a part of their process. Ask them to invite you to the end-user testing sessions and the design reviews with the stakeholders.

Be in those sessions and meetings as the the idea is implemented so you can continue to reference your personas and make sure decisions are made for the right reasons. That way, you’ll be in the front row to see positive change happen as you guide your idea and hard work into something truly innovative.

As your idea starts to gain traction and your experiments turn into a real process—see things through. Don’t just hand off your idea and hope for the best like a child waiting for the school bus. Drive the damn bus.


A Dao of Product Design

When a designer or developer sets out to create a new product, the audience is thought of as “the user”: we consider how she might use it, what aspects make it accessible and usable, what emotional interactions make it delightful, and how we can optimize the workflow for her and our benefit. What is rarely considered in the process is the social and societal impact of our product being used by hundreds of thousands—even millions—of people every day.

What a product does to people psychologically, or how it has the power to transform our society, is hard to measure but increasingly important. Good products improve how people accomplish tasks; great products improve how society operates. If we don’t practice a more sustainable form of product design, we risk harmful side effects to people and society that could have been avoided.

The impact of product design decisions

In 1956, President Eisenhower signed the U.S. Interstate Highway Act into law. Inspired by Germany’s Reichsautobahnen, Eisenhower was determined to develop the cross-country highways that lawmakers had been discussing for years.

During the design of this interstate network, these “open roads of freedom” were often routed directly through cities, intentionally creating an infrastructural segregation that favored affluent neighborhoods at the expense of poor or minority neighborhoods. Roads became boundaries, subtly isolating residents by socioeconomic status; such increasingly visible distinctions encouraged racist views and ultimately devastated neighborhoods. The segmentation systematically diminished opportunities for those residents, heavily impacting people of color and adversely shaping the racial dynamics of American society.

Such widespread negative consequences are not limited to past efforts or malicious intentions. For example, the laudable environmental effort to replace tungsten street lamps with sustainable LEDs is creating a number of significant health and safety problems because the human impact when applied at scale was not thought through sufficiently.

In each example, we see evidence of designers who didn’t seriously consider the long-term social and moral impacts their work might have on the very people they were designing for. As a result, people all around suffered significant negative side effects.

The ur-discipline

Although the process is rarely identified as such, product design is the oldest practiced discipline in human history. It is also one of the most under-examined; only in relatively recent times have we come to explore the ways products exist in the context they impact.

Designers often seek to control the experience users have with their product, aiming to polish each interaction and every detail, crafting it to give a positive—even emotional—experience to the individual. But we must be cautious of imbalance; a laser focus on the micro can draw attention and care away from the macro. Retaining a big-picture view of the product can provide meaning, not only for the user’s tasks, but for her as a person, and for her environment.

Dieter Rams’s ninth principle says that good design is environmentally friendly; it is sustainable. This is generally interpreted to mean the material resources and costs involved in production, but products also affect the immaterial: the social, economic, and cognitive world the user inhabits while considering and using the product.

At a high level, there is an easy way to think about this: your product and your users do not exist in a vacuum. Your algorithms are not fair or neutral. Your careful touch is not pristine.

Your life experiences instill certain values and biases into your way of thinking. These, in turn, color your design process and leave an imprint behind in the product. It’s essentially the DNA of your decisions, something embedded deeply in the fabric of your work, and visible only under extremely close inspection.

Unlike our DNA, we can consciously control the decisions that shape our products and strive to ensure they have a positive impact, even the myriad subtle and non-obvious ways we might not anticipate. Let’s learn to solve the problems we can’t yet see when designing our products.

Design for inclusion

When we set out to design a product, we generally have a target audience in mind. But there are distinctions between functional target audiences and holistic ones. To create products that embrace long-term positive impacts, we must embrace inclusive thinking as comprehensively as we can.

Conduct research into racial and gender politics to broaden your awareness of the social structures that impact your customers’ lives. These structures alter people’s priorities and affect their decision-making process, so design for as many social and societal considerations as possible. Sometimes people who fall outside the “target audience” are overlooked simply because their priorities for your product come in second place in their lives. Design your product to bridge such gaps, rather than ignoring them.

Listen to the voices of people expressing concern and learn to see the pain points they experience, even if they don’t articulate them as such. Step up to your responsibilities as a designer, curator, entrepreneur, or platform owner. You may not be an elected official, but when you offer products you still have responsibility over the roles they play in people’s lives and experiences—so govern accordingly.

Read studies that examine human psychology to understand how people’s biases may be exacerbated by your product. Learn about microaggressions so you can consciously design around them. Extrapolate how people with nefarious goals—from hackers to authoritarian governments—could exploit or abuse your features or the data you collect.

Work with data and let it inform you, but remember that data is suggestive, not authoritative; the data we gather is always a myopic subset of the entirety that exists but cannot possibly be measured. Enrich your process and viewpoint with information, but let your heart drive your design process.

These principles are more than “nice-to-haves”—they help you design with an ethical and moral code as inherent throughout the product as the design system used to build it.

Foster positivity and civility

When we use a product frequently, the DNA of its design process can leave a psychological imprint on us. Facebook knows it can affect people’s moods by putting more positive items in their feeds. When news broke that it did so, people were upset about this manipulation. In actuality, our lives are constantly being manipulated by algorithms anyway; we’re just not very conscious of it. Often, even the people who designed the algorithms aren’t conscious of the deeper manipulative impacts.

Features like upvotes and downvotes may seem like a balanced solution for people to express opinions, but the downvote’s only purpose is to feed and perpetuate negativity; it can be avoided or removed entirely without harmful consequences.

Don’t give angry people shortcuts to wield negative power; make them either articulate their anger or deal with it in more constructive ways. Social media platforms never benefit from angry, biased groups suppressing messages (often positive and constructive) from people they despise. In those scenarios, everyone loses—so why design the option into your product?

Any feature that petty, time-rich people can abuse to game your product’s ranking or discovery algorithms is a feature that eventually serves up toxic behaviors (regardless of the person’s politics) and is best left out.

Also avoid features that simply waste time, because when people waste time they feel less happy than when they do something productive or constructive. And of course, don’t deliberately design time-wasters into your product and offer users a premium fee to avoid them; that’s just not civil.

To foster positive behavior and encourage civility, you can reward good behavior and hold bad behavior accountable. Holding bad behavior accountable is crucial to establishing a credible community or platform—but no rewards for good behavior risks creating a fear-driven atmosphere.

A great example of designing consciously like this is Nextdoor, a platform for local communities. Nextdoor made a purposeful effort to reduce racial profiling by users by redesigning a small part of their product. For example, when reporting “suspicious activity,” new follow-up questions like “What are they doing that’s suspicious?” are required fields, so that users can no longer simply accuse people of color of “being suspicious.” The resulting 75 percent reduction in racial profiling is great for obvious reasons, but it also has the effect that users are actively being trained to no longer associate the two as interchangeable.

Design to avoid vectors of abuse; strive to encourage positive interactions and, wherever possible, challenge and transform existing biases.

Boost confidence and courage

People likely use your product to accomplish something, whether it’s a leisure task or a professional one. A user who repeats certain tasks with your product is effectively practicing her interactions; find the opportunities therein to help her grow as a person, not just succeed as a worker.

For example, when my cofounder and I set out to create Presentate, our goal wasn’t merely to create a web-based version of Keynote or PowerPoint—we set out to help people lose their fear of public speaking, to prevent audiences from experiencing “Death by PowerPoint,” and to create the fastest, most effective presentation software and sharing platform available on any device.

Our business effort was cut short, but our product design goals were achieved even with our alpha software: our users—the presenters—felt more confident and relaxed, found it easier to focus their energies on their talks, and spent far less time creating the presentations (leaving more time to rehearse). Plus, their audiences didn’t suffer through the dreaded stack of bullet points and a monotonous presentation.

Instead of seeing our product as a combination of features and UI, we considered it a tool that could empower people far beyond the scope of their tasks. Your product can do the same if you think about how it could strengthen related skills (in our case, public speaking) the more someone “practices” by using it.

Think about features and insights that encourage people in positive ways; teach them knowledge you have that they might not, perhaps as imposingly as by embedding its principles as features themselves.

Your user is likely a busy person with a million things on her plate—and on her mind. She won’t sit down and think introspectively about how your product affects her life, but you as the designer or developer can and should do precisely that.

You can spend the extra time upfront thinking about how to inform or teach your users new insights or techniques that help build the confidence they are looking for. Empowerment isn’t just the facilitation of a new ability—it’s the emotional and mental strengthening of confidence in your customer when she meets a challenge and accomplishes something impressive.

Strengthen emotional fortitude

Emotional fortitude is the foundation that helps you to be courageous and honest, and to better withstand setbacks. A person who feels emotionally secure has an easier time finding the courage to admit failure or mistakes, which creates opportunities for them to learn and grow. Conversely, emotional fragility erodes a person’s confidence and obstructs personal growth.

People’s emotional states are influenced heavily by external factors. Our environment plays a role in shaping how we see the world, its opportunities, and its problems. But while there’s been extensive research into the role of legislation on our lives, there’s comparatively little research examining the role that products play in our environment. This is becoming pressing as software and technology communicate with us, to us, and about us as frequently as other people do; they now have as much of an effect on our lives as laws and regulations.

Behavioral science and nudge theory strongly suggest that behaviors can be positively influenced by conscious efforts. For instance, rather than mandating certain actions, you could encourage better decisions or actions by making them more prominent or appealing. This kind of influence can and often does extend beyond behaviors and into our states of mind.

To be clear, this is not a deterministic argument—technology and products don’t inherently make us sad or happy, confident or anxious. Rather, this is an argument that products have the potential to influence us in emotional ways, and that the greater a product’s user base and its daily use of the product, the more impactful its effects can be on how they see and experience the world.

The strongest case for this is made by a variety of studies that show that our current social media platforms make people less happy. But what if those platforms had the opposite effect, instead making people happier and more confident about their lives?

One way is to take a teaching approach with your users. When enforcing Terms of Service, for instance, just saying “your actions are unacceptable and violate our ToS” doesn’t explain what was not okay or why you don’t want that kind of behavior. It also doesn’t suggest which behaviors you are looking to see from users. The former approach causes people to feel emotionally insecure, so focus on the latter—on positive kinds of interactions you wish to foster on your platform. They can be actual conversations, or simply part of your marketing and messaging.

Products can also affect our psychological and emotional well-being through the types of behaviors they facilitate and foster. For example, features that can be exploited by petty individuals may result in a great amount of petty behavior on your platform or within your community; we know this behavior creates emotional fragility, not fortitude. On the other hand, features that surprise and delight users (a tenet of great emotional design) can have a fortifying effect on a person’s emotional state.

When designing Presentate, our goal wasn’t “to make slideware”; our goal was to make presenters more confident in their presentation and have greater confidence as speakers. Our means of achieving that goal was to design a slideware product that would accomplish both.

Another fine example is Tesla, a company that makes electric vehicles and associated technology. As its CEO and founder Elon Musk repeats at many of their product announcements, Tesla’s goal—its mission—is to transform us into a renewable-energy human society. In setting its goal accordingly (and explicitly!), Tesla operates on the premise that it needs to do more than simply make a product; it needs to change people’s views and how they feel about their existing products. At the Solar Roof announcement, Musk reiterated that “the key is to make it desirable,” to make something people want regardless of its role in the energy revolution. Similarly, Tesla’s Model S car outperforms many a muscle car in drag races, legitimizing the electric vehicle as a high-performance option for speed enthusiasts. This approach helps to change people’s wider perceptions, extending beyond the products themselves.

When we set our goals not just to create great products, but products that help transform how we think, we can tackle underlying biases and prejudices that people may have but would be happy to be eased out of. We strengthen their confidence and character, and address problems that go well beyond the scope of any one product. And while none of us are solely responsible for fixing major problems in society, each of us, when designing a product, has an opportunity to make it part of the solution.

Or as Nextdoor CEO Nirav Tolia said, when asked about why they changed their design:

We don’t think Nextdoor can stamp out racism, but we feel a moral and business obligation to be part of the solution.

Recreate social mores

There is no digital duality, no “real world” separated from our environment online. Generally, every avatar you talk with on a screen has one or more real people behind it—people with real feelings you can hurt as easily online as you could to their face. You just don’t see it, which shows that we do miss out on a number of social cues when interacting on screen: things like tone, sarcasm, playfulness, hurt feelings—or disapproving frowns from our peers.

A street harasser exploits the lack of a social circle that pressures them to behave decently. Oftentimes this is out of ignorance, not malice, including when the harasser is in the company of others who often are equally unaware that such behavior is unwelcome and uncivil. Many, of course, are in denial and shout catcalls at women despite knowing better—and wouldn’t dare catcall a woman in front of their mothers, for example.

In the digital environment, those external social pressures to behave are often lost, so unless they come to you from the strength you have within, it’s all too easy to slip into behavior you wouldn’t engage in while speaking with someone face to face. Let’s be honest: we’ve all said things to people online at some point or another that we would be ashamed to repeat in person.

From a product perspective, that means we have to rely on mechanisms that either invoke those social mores to encourage civil and fruitful interactions, or outright enforce them. We have to design a simulated social circle of peer pressuring friends into the products we make. Nextdoor did it with form fields that asked follow-up questions. What can your product do?

See the best in people (but be realistic)

People prefer being good and happy over being mean-spirited or awful. You can design your products to encourage the best sides of people, to let them shine in their brilliance, to help them learn and grow while doing their work. But don’t mistake seeing the best in people as a reason not to anticipate harmful behaviors or exploitation of your features.

As product designers we deliberately craft solutions to envisioned problems. We should practice expanding our view to encompass and understand more people and the problems they are experiencing. We should strive to make our work a part of the solution, in ways that scale up to millions of users without harmful side effects.

You’ve read this far. That means you’re eager and ready to think bigger, more holistically, and more empathetically about the work that you do. Armed with these principles, you’re ready to take your product design to the next level.

We can’t wait to see what you’ll create!

This week's sponsor: WEBEDITION

WEBEDITION, the best way to craft and deliver issues of your own online magazine. Start now and build an issue for free.

The Imbalance of Culture Fit

When I started Bearded back in 2008, I’d never run a business before. This lack of experience meant I didn’t know how to do many of the things I’d ultimately have to do as a business owner. One of the things I didn’t know how to do yet? Hiring.

When it came time to start hiring employees, I thought a lot about what the company needed to advance, what skills it was lacking. I asked friends for advice, and introductions to people they knew and trusted who fit the bill. And I asked myself what felt like a natural question: would I want to hang out with this person all day? Because clearly, I would have to.

The trouble with this question is that I like hanging out with people I can talk to easily. One way to make that happen is to hang out with people who know and like the same books, music, movies, and things that I do; people with similar life experiences. It may not surprise you to learn that people who have experienced and enjoy all the same things I do tend to look a whole lot like me.

The dreaded culture fit

This, my friends, is the sneaky, unintentional danger of “culture fit.” And the only way out I’ve found is to recognize it for what it is–an unhelpful bias–and to consciously correct for it.

Besides being discriminatory by unfairly overvaluing people like yourself, hiring for culture fit has at least one other major detriment: it limits perspective.

At Bearded, our main focus is problem solving. Whether those are user experience problems, project management problems, user interface problems, or development problems–that’s what we do every day.

I’ve found that we arrive at better solutions faster when we collaborate during problem solving. Having two or more people hashing out an issue, suggesting new approaches, spotting flaws in each other’s ideas, or catching things another person missed–this is the heart of good collaboration. And it’s not just about having more than one person, it’s about having different perspectives.

Perspective as a skill

A simple shortcut to finding two people who look at the world differently is to find two people with varied life experience–different genders, races, religions, sexual orientations, economic backgrounds, or abilities… these factors all affect how we see and experience the world. This means that different perspectives–different cultures–are an asset. Varied perspective can be viewed, then, as a skill. It’s something you can consciously hire for, in addition to more traditional skills and experience. Having diverse teams better reflects our humanity, and it helps us do better work.

This isn’t just my experience, either.

According to research conducted by Sheen S. Levine and David Stark, groups that included diverse company produced answers to analytical questions that were 58 percent more accurate.

When surrounded by people “like ourselves,” we are easily influenced, more likely to fall for wrong ideas. Diversity prompts better, critical thinking. It contributes to error detection. It keeps us from drifting toward miscalculation.

Smarter groups and better problem-solving sounds good to me. And so does increased innovation. In her article for Scientific American, Katherine W. Phillips draws on decades of research to arrive at some exciting conclusions.

Diversity enhances creativity. It encourages the search for novel information and perspectives, leading to better decision making and problem solving. Diversity can improve the bottom line of companies and lead to unfettered discoveries and breakthrough innovations. Even simply being exposed to diversity can change the way you think.

Phillips isn’t alone in linking diversity to profit. A Morgan Stanley analysis released in May 2016 showed that gender-diverse companies delivered slightly better returns with lower volatility than their more homogenous peers.

Seems like we’d be crazy not to be thinking about building more diverse teams, doesn’t it?

People make the culture

I recently spoke at Web Directions 2016 in Sydney, and was lucky enough to listen to a talk on gender in the tech industry by Aubrey Blanche from Atlassian. Aubrey made a point of how Atlassian has shifted its perspective from finding people who fit their culture, to having a culture defined by its people.

When hiring, this means tossing out the whole “do I want to hang out with them?” question. Instead, I’ve tried to replace that with more specific, more culture-agnostic questions:

  • Are they kind and empathetic?
  • Do they care about their work?
  • Do they have good communication skills?
  • Do they have good self-management skills?

If the answer to each of these questions is yes, then it’s very likely I will want to hang out with them all day, regardless of which movies they like.

As Aubrey points out, we can then focus on values, and leave culture alone. Our values might be that we treat each other well, that we do great work that we care about, and that we are largely independent but communicate well when it’s time to collaborate. Then we can also include this new question:

  • Do they bring a valuable new perspective?

Hiring based on these values will naturally build a culture that is more comfortable with diversity, because the benefits of diversity become more clear in our daily experiences.

Encouragement and change

Now you don’t need me to tell you no one’s perfect. But when it comes to emotional, high-stakes topics like this, you can see people getting caught in the crosshairs of reproach–and that’s scary to watch. Sometimes it can feel as if we’re all one questionable tweet or ill-considered joke away from public humiliation.

That in mind, let me tell you about a time when I was an idiot.

For context, you should know that I’m a white, heterosexual, cisgender male who grew up in a stable, upper-middle-class environment, and now runs his own business. I pretty much tick all the privilege checkboxes.

Last year at a design conference, I was chatting with industry friends. At some point I brought up a meme that I thought was funny, until one of my friends pointed out that it was sexist. And he was right.

Oh crap, I thought: I’m that guy at the conference, I’m a terrible person. Luckily my friend went easy on me. He understood how I missed the underlying sexist assumptions of the joke, and was happy to bring that to my attention without extending the accusation of sexism to me, personally. He effectively reassured me that I could do something bad, while still being a good person. He gave me the option to admit bad behavior and correct it, without hating myself in the process.

And this, I think, may be the key for people in my very privileged position to change. When problems like this come up, when we make missteps and unveil our biases and ignorance, it’s an opportunity for change. But the opportunity is often much more delicate than any of us would like. Successfully navigating a situation like that requires sensitivity and control from both sides.

For the transgressor, being called out on an issue can feel like being attacked, like an indictment. For those of us who aren’t used to being made uncomfortable, that can be shocking. It can be something we might want to quickly deny, to reject that discomfort. But not all discomfort is, in the end, a bad thing. To give others’ feelings and concerns merit–to validate their different perspective–may require us to sit with our own hurt pride or injured self-image for a bit. Something that may help us through these difficult feelings is to remember that there is a big difference between behaviors and identity. Bad behavior is not immutable. Quite the opposite, bad behavior is often a first step toward good behavior, if we can withstand the discomfort of acknowledging it, and muster the strength to change.

It’s tough getting called out for bad behavior, but things aren’t exactly simple on the other side of the confrontation, either. When we’re offended by someone’s ill-considered words or actions, it can cut to the quick. We might feel required to respond with the full force of our anger or outrage. After all, why should we be expected to police our own tone, when we’re responding to words that weren’t prepared with our feelings in mind? It can be hard, but employing our empathy, our compassion—along with our critique—can be the best way to affect the positive change we want to see.

Right now, you’re doing your best. But we can all do better. Recognizing that we’re doing some bad things doesn’t make us bad people. You have the courage to see what you’ve been doing wrong (unintentionally, I know) and fix that. You can admit to having unfair privileges in the world, without it being your fault for having ended up that way. The world is terribly, horribly unfair. It may very well get worse. But when we have sway, even over a tiny part of it, we have to do our best to balance those scales, and make things a little better. I can do more, and so can you. So let’s see if we can’t get to an even better place in 2017, together.


Many thanks to Aubrey Blanche and Annette Priest for their thoughtful consideration and feedback on this article. My infinite gratitude goes out, as always, to my editor Rose Weisburd, who helped me find my way even more than usual this time around.

Learning from Lego: A Step Forward in Modular Web Design

With hundreds of frameworks and UI kits, we are now assembling all kinds of content blocks to make web pages. However, such modularity and versatility hasn’t been achieved on the web element level yet. Learning from Lego, we can push modular web design one step forward.

Rethinking the status quo

Modular atomic design has been around for a while. Conceptually, we all love it—web components should be versatile and reusable. We should be able to place them like bricks, interlocking them however we want without worrying about changing any code.

So far, we have been doing it on the content block level—every block occupies a full row, has a consistent width, and is self-contained. We are now able to assemble different blocks to make web pages without having to consider the styles and elements within each block. That’s a great step forward. And it has led to an explosion of frameworks and UI kits, making web page design more modular and also more accessible to the masses.

Achieving similar modularity on the web element level is not as easy. Pattern Lab says we should be able to put UI patterns inside each other like Russian nesting dolls. But thinking about Russian nesting dolls, every layer has its own thickness—the equivalent of padding and margin in web design. When a three-layer doll is put next to a seven-layer doll, the spacing in between is uneven. While it’s not an issue in particular with dolls, on web pages, that could lead to either uneven white space or multilevel CSS overrides.

I’ve been using Bootstrap and Foundation for years, and that’s exactly what would happen when I’d try to write complex layouts within those frameworks—rows nested in columns nested in rows, small elements in larger ones, all with paddings and margins of their own like Russian dolls. Then I would account for the nesting issues, take out the excessive padding on first- and last-child, calculate, override, add comments here and there.

It was not the prettiest thing I could do to my stylesheets, but it was still tolerable. Then I joined Graphiq, a knowledge company delivering data visualizations across more than 700 different topics. Here, content editors are allowed to put in any data they want, in any format they want, to create the best experience possible for their readers. Such flexibility makes sense for the small startup and we have a drag and drop interface to help organize everything from a single data point to infographics and charts, to columns, blocks, and cards. Content editors can also add logic to the layout of the page. Two similar bar charts right next to each other could end up being in quite different HTML structures. As you can imagine, this level of versatility oftentimes results in a styling hell for the designers and developers. Though a very promising solution—CSS Grid Layout—is on the horizon, it hasn’t made its way to Chrome yet. And it might take years for us to fully adapt to a new display attribute. That led me to thinking if we can change the Russian doll mentality, we can take one step further toward modular design with the tools available.

Learning from Lego

To find a better metaphor, I went back to Lego—the epitome of modular atomic design. Turns out we don’t ever need to worry about padding and margin when we “nest” a small Lego structure in a large Lego structure, and then in an even larger Lego structure. In fact, there is no such concept as “nesting” in Lego. All the elements appear to live on the same level, not in multiple layers.

But what does that mean for web design? We have to nest web elements for the semantic structure and for easy selecting. I’m not saying that we should change our HTML structures, but in our stylesheet, we could put spacing only on the lowest-level web elements (or “atoms” to quote atomic design terms) and not the many layers in between.

Take a look at the top of any individual Lego brick. If you see the space around the outside of the pegs as the padding of a web element, and everything inside the padding as the content, you will find that all Lego bricks have a consistent padding surrounding the content, which is exactly half of the gap between elements.

Lego bricks seen from the top, with the pegs representing box content and the padding highlighted to show its consistent width no matter the number of pegs on a brick
No matter how many pegs a brick has, the padding around them is the same as on every other Lego.

And when Lego bricks are placed together, all the elements will have the same gutter in between.

A rectangle of Lego bricks seen from the top, edges touching, each with a thin line between the pegs and the padding
The padding extends from the outer edge of the pegs of one brick to the outer edge of the pegs of the neighboring brick.

No other padding or margin needed; the gaps are naturally formed. All the elements—no matter how deeply they are nested—appear to be on the same level and need no CSS override or adjustment, not even the first- and last-child reset.

Putting it in code, we can make a class that adds the half-gutter spacing, and apply it to all the lowest-level web elements on the page. Then we can remove all the spacing on structural divs like .row and .col.

$gutter: 20px;
.element {
	 padding: $gutter / 2;

One tiny tweak to be mindful of is that when the padding is only on .element, the padding between the outermost elements and the parent div would only be half the gutter.

White rectangle representing the complete assembly of bricks in the previous figure with gray rectangles representing the area taken up by pegs, showing that the padding creates full-size gutters between peg areas but only half-size gutter around the periphery.
The periphery is only half the gutter, for now.

We need to add the same padding to the outermost container as well.

Peg areas shown as gray rectangles within a white rectangle representing the complete assembly, edges between bricks shown as black lines, and an extra pink line around the outermost edge showing added padding.
The outermost container with a half gutter added all around.
$gutter: 20px;
.element {
	padding: $gutter / 2;

And that will result in this:

White rectangle with gray rectangles and consistent padding between and around them.
With the added outermost padding, all the padding looks the same.

Think about how many layers of overrides we would need to create this layout with the current rows and columns mentality. The best we can do is probably something like this:

Diagram representing the previous Lego brick rectangle arrangement in rows and columns.
The same layout via rows and columns.

And in code:

See the Pen Complex layout the old way by Samantha Zhang (@moyicat) on CodePen.

With the Lego mentality, the spacing and the code can be much simpler, as shown in the two examples below:

Example with div:

See the Pen Complex layout with div by Samantha Zhang (@moyicat) on CodePen.

Example with Flexbox:

See the Pen Complex layout with flexbox by Samantha Zhang (@moyicat) on CodePen.

More flexible than Lego

Lego is a true one-size-fits-all solution. With Lego, we don’t get to tweak the padding of the bricks according to our projects, and we can’t have different horizontal and vertical padding. Web design offers us much more variation in this area.

Instead of just setting one value as the gutter, we can set four different variables and get more flexible layout this way:

$padding-x: 10px;
$padding-y: 20px;
$padding-outer-x: 40px;
$padding-outer-y: 30px;

.container {
  padding: $padding-outer-y $padding-outer-x;
.element {
  padding: ($padding-y / 2) ($padding-x / 2);

The result looks like this:

The same arrangement of rectangles representing bricks, but with different values for the x and y padding.
Unlike with physical Lego pieces, we can set different values for the padding.

It’s still modular, but also has varying spaces to create a more dynamic style.

With responsive design, we could also want different spacing for different media queries. We can take our approach one step further and write our logic into a Sass mixin (alternatively you can do it with LESS, too):

@mixin layout ($var) {

  $padding-x: map-get($var, padding-x);
  $padding-y: map-get($var, padding-y);
  $padding-outer-x: map-get($var, padding-outer-x);
  $padding-outer-y: map-get($var, padding-outer-y);

  .container {
    padding: $padding-outer-y $padding-outer-x;
  .element {
    padding: ($padding-y / 2) ($padding-x / 2);

Using this mixin, we can plug in different spacing maps to generate CSS rules for different media queries:

// Spacing variables
$spacing: (
  padding-x: 10px,
  padding-y: 20px,
  padding-outer-x: 40px,
  padding-outer-y: 30px
$spacing-tablet: (
  padding-x: 5px,
  padding-y: 10px,
  padding-outer-x: 20px,
  padding-outer-y: 15px

// Generate default CSS rules
@include layout($spacing);

// Generate CSS rules for tablet view
@media (max-width: 768px) { 
  @include layout($spacing-tablet);

And as easy as that, all our elements will now have different spacing in desktop and tablet view.

Live example:

See the Pen Complex layout with mixin and varying gutter by Samantha Zhang (@moyicat) on CodePen.


After using this method for almost a year, I’ve encountered a few common questions and edge cases that I’d like to address as well.

Background and borders

When adding backgrounds and borders to the web elements, don’t apply it to the .element div. The background will cover both the content and padding areas of the element, so it will visually break the grid like this:

Gray rectangles with white padding, with one of the rectangles and its padding replaced by a picture.
A background applied to .element breaks the grid.

Instead, apply the background to a child div within the .element div:

<div class="element">
  <div style="background-image:url();"></div>
Gray rectangles with white padding, with one of the rectangles replaced by a picture.
A child div contains the image so it doesn’t break the grid.

I used this structure in all my examples above.

Similarly, the border goes around the padding in the box model, so we should also apply the border of the element to a child div to maintain the correct spacing.

White rectangle with blue borders around content areas.
As with a background, apply a border to a child div.

Full row elements

Another common issue occurs because we occasionally want full row elements, conceptually like this:

A gray horizontal rectangle with the words Title Here atop a white rectangle holding smaller gray rectangles.
Sometimes we want to break the grid with full row elements.

To style full row elements following the .container and .element structure, we need to make use of negative margin:

.element-full-row {
  margin: 0 (-$padding-outer-x);
  padding: ($padding-y / 2) ($padding-x / 2 + $padding-outer-x);

Notice that we need to add back the $padding-outer-x to the padding, so that the content in .element-full-row and the content in .element align.

A gray horizontal rectangle with the words Title Here atop a white rectangle holding smaller gray rectangles and a dashed line to show how the words align on the left with the left-most of the small rectangles.
The content in .element-full-row and the content in .element align.

The code above handles the horizontal spacing, and the same logic can be applied to take over vertical spacing as well (as shown in the example above–the header element takes over the top padding). We can also add a negative margin very easily in our stylesheets.

.element-full-row:first-child {
  margin: (-$padding-outer-y) (-$padding-outer-x) 0;
  padding: ($padding-y / 2 + $padding-outer-y) ($padding-x / 2 + $padding-outer-x) ($padding-y / 2);

It can be applied as a standalone rule or be included in the Sass or LESS mixin, then you will never have to worry about them again.


The full freedom in nesting is the strong suit of this Lego CSS method. However, there is one kind of nesting we can’t do–we can’t ever nest an .element within an .element. That will create double padding and the whole point of this method would be lost. That’s why we should only apply the .element class to the lowest level web elements (or “atoms” to quote atomic design terms) like a button, input box, text box, image, etc.

Take this very generic comment box as an example.

Generic comment box with title, text area, helper text, and button.

Instead of treating it as one “element,” we need to treat it as a pre-defined group of elements (title, textarea, button, and helper text):

<div class="comment">
  <h3 class="comment-title element">Add a new comment</h3>
  <textarea class="element"></textarea>
  <div class="clearfix">
     <div class="float-left">
       <div class="element">
         <button class="btn-post">Post comment</button>
     <div class="float-right">
       <div class="helper-text element">
         <i class="icon-question"></i>
           Some HTML is OK.

Then, we can treat .comment as one reusable component–or in the atomic design context, a “molecule”–that will play well with other reusable components written in the same manner, and can be grouped into higher level HTML structures. And no matter how you organize them, the spacing among them will always be correct.

Varying heights and layouts

In the bulk of this article, we’ve been using the same fitted row example. This may lead some to think that this method only works for elements with defined height and width.

It’s more versatile than that. No matter how elements change in height and width, lazy load, or float around, the Lego-like padding will ensure the same consistent gap between elements.

Pinterest flow layout of 5 columns.
I made a quick Pinterest flow layout to demonstrate how this mentality works with fluid and changing elements.

See the Pen Pinterest Flow by Samantha Zhang (@moyicat) on CodePen.


Some of you might also be worrying about the maintenance cost. Admittedly, it takes time to learn this new method. But once you start to adopt this mentality and write CSS this way, the maintenance becomes extremely simple.

Especially with the layout mixin, all the spacing rules are centralized and controlled by a few groups of variables. A single change in the variables would be carried out to all the elements on the web page automatically.

In comparison, we might have to change padding and margin in 20 different places with the old method, and then we have to test to make sure everything still works. It would be a much more hectic process.

Grid layout

And finally, there is the Grid layout, which supports very complicated layouts and nests much more gracefully than block. You might be thinking this is quite a lot of hard work for a problem that is actually going away.

While many of the issues we talked about in this article might go away with Grid, it might take Grid years to get browser support. And then, it might take a long time for the community to get familiar with the new method and develop best practices and frameworks around it. Like Flex–it’s already supported by most browsers, but it’s far from widely adopted.

And after all, it could take a typical web user a long time to understand Grid and how that works. Similarly, it would require quite a lot of development for us to translate user layout input into good CSS Grid code. The old by-column and by-row method is way easier to understand, and when nesting is not an issue, it could stand as a good solution for websites that allow user configuration.


We started to implement this method at Graphiq in the beginning of 2016. Almost a year in, we love it and believe this is how we should write web layouts in the future. As we refactor each page, we’re deleting hundreds of lines of old CSS code and making the stylesheets way more logical and much easier to read. We also got far fewer layout and spacing bugs compared to all our refactors in the past. Now, no matter how our content editors decide to nest their data points, we’ve got very little to worry about.

From what we’ve seen, this is a real game changer in how we think about and code our layouts. When web components are modular like Lego bricks down to the elements level, they become more versatile and easier to maintain. We believe it’s the next step to take in modular web design. Try it for yourself and it might change the way you write your web pages.

Demystifying Public Speaking

A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Lara Hogan's new book, Demystifying Public Speaking, available now from A Book Apart.

Before you near the stage, before you write the talk, before you even pick a topic, take time to get comfortable with the idea of giving a talk.

You’re reading this because something about public speaking makes your palms sweat. You aren’t alone; when I created an anonymous survey and asked, “What’s your biggest fear about public speaking?” I received over 300 replies. Though the fears all revolved around being vulnerable in front of a large group of people, I was surprised how widely the responses ranged.

See for yourself—I’ve grouped a handful of replies to illustrate the spectrum of fears.

People are worried about their voices:

  • “The sound or pitch of my own voice.”
  • “Voice cracking up—I forget to breathe from the diaphragm and come across sounding nervous and uninformed.”
  • “Forgetting or skipping over what I want to say, heart racing (and getting out of breath quicker), getting tongue-tied.”

People are worried about their bodies:

  • “Being judged for being fat, not on my presentation content.”
  • “In middle school I got something in my eye during a class presentation, and my eyes would not stop watering. I’m terrified it will happen again.”
  • “Needing to pee during the speech!”
  • “Falling on stage.”
  • “People judging my appearance, whether I’m dressed appropriately.”

People are worried about technical or wardrobe malfunctions:

  • “Problems connecting laptop to projector.”
  • “Making stupid coding mistakes during live coding.”
  • “Open pants zipper (because it’s happened).”

People are worried about being wrong and being challenged:

  • “Elegantly explaining something that is actually wrong.”
  • “Showing that I’m ignorant about something I thought I was knowledgeable about.”
  • “Getting a question I can’t even begin to answer.”
  • “Being wrong and being called out on stage during Q&A.”
  • “Getting heckled.”
  • “Vocal skeptics or doubters.”

People are worried about their performance:

  • “Not being impressive enough.”
  • “That everything I say becomes so messy anyone can refute it.”
  • “Since I’m not a native English speaker, my biggest fear is not making any sense when speaking.”
  • “That no one learns anything, and the audience is starkly aware of it.”
  • “Being exposed for the fraud I have always felt like.”

Phew. Given the potential for these moments of total—human—disaster, why should we even bother embarking on this journey toward the stage?

To start, public speaking (or put another way, broadcasting your abilities and knowledge) has definite career benefits. You grow your network by meeting attendees and other speakers, and you gain documented leadership experience in your subject area. People looking to hire, collaborate with, or fund someone with your topic expertise will be able to find you, see proof of your work, and have a sense of the new perspective you’ll bring to future projects.

Those professional benefits are huge—but in my experience, the personal benefits are even more substantial. Giving a talk grows so many skill sets: crafting a succinct way to share information, reading an audience, and eloquently handling an adrenaline-heavy moment. You’ll prove something to yourself by overcoming a major fear, and you should take pride in knowing you taught a large group of people something new that will hopefully make their work or lives easier. Public speaking experience boosts a lot of knock-on benefits too, like a stronger visa application or more confidence in your everyday spotlight moments, like a standup meeting, code review, design critique, or other project presentations.

No matter the impetus, trying your hand at public speaking is a brave act. While it’s a different challenge for everyone, we do have a few tools to help tackle our fears.

Flip that fear around

First, give yourself permission to be anxious. Even renowned speaker and industry veteran Eric Meyer still gets nervous giving talks, as detailed in his article “The Stages of Fear”:

A hundred public talks or more, and it’s still not easy. I’m not sure it ever will be easy. I’m not sure it ever should be easy. […] Every speaker I know feels pretty much exactly the same. We don’t all get the same nervous tics, but we all get nervous. We struggle with our fears and doubts. We all feel like we have no idea what we’re doing.

Being nervous is totally normal. Consider what you’re juggling: sharing information, entertaining the audience, and guessing (or worrying over) how you’re being perceived. Keep in mind, though, being nervous is not a sign you’ll do poorly. Public speaking isn’t an everyday context, and you may still get butterflies even as you gain experience and improve your speaking game.

But if you can’t coolly eliminate all your fears and nerves like some stoic robot, what can you do? One tactic is to try reframing your anxiety in a positive or motivating way, as designer Lea Alcantara suggests:

Instead of worrying, flip your perception of nerves as an indication you care as opposed to dread of failure. There is no shame in caring deeply about a subject and what people think about your talk.

Caring feels a lot more approachable than dreading failure, and it gives you a way through: use your body’s natural reaction to stress to improve your talk. Invest that energy into more research of your topic, more practice, and more feedback-gathering—all acts within your control. Let your nerves become part of the process—or try accepting that—and just maybe, in time, they’ll feel more useful than disastrous.

What makes you tick?

To flip your fears into motivations, let’s dip into what makes you tick. Understanding who you are will help you determine where to invest that extra energy as you make your way toward the stage. Once you begin to name what scares you, what comforts you, and what drives you, you’ll be able to home in on which talk format, topic, venue type, and preparation style will calm those fears and build your excitement.

To get you started, think through these:

  • What makes you most excited when you think about public speaking? What do you want to get out of it?
  • What makes you most nervous when you think about public speaking?
  • What scenarios do you want to avoid?
  • What size audience do you think you might be most comfortable speaking to? Why?
  • Whose feedback matters most to you on your talk or presentation style?
  • What would you want people to take away from your talk?
  • What do you want to happen for you or your career after your talk? (Examples: someone offers you your dream project, someone you admire asks for your advice, people shower you with praise, you get right back to work, etc.)

That’s a lot of introspection, but it’s worth it. As we move through this book, we’ll go through the varied paths and aspects of public speaking, and your answers will guide you to the right fit for you. For instance, if you’re afraid of seeing a sea of strange faces before you, maybe a smaller meetup is the best venue to get in some practice. If you’re afraid of saying something patently false onstage, then pick a topic like a case study from your work that you know inside and out, and practice your Q&A session with friends who can help you fact-check your content. Or, if you’re excited to teach people skills they can immediately put into practice, opt for a workshop format and give hands-on help to folks. Whatever your goals and style, you can find a speaking opportunity that resonates with you.

Move beyond the “rules”

You’ve heard the adages: don’t say “um,” don’t say “uh.” Excise “like” with extreme prejudice. Don’t use bullets on your slides. Never, ever read from your notes. Some folks have an archetype of what a great speaker sounds like, or an audience size that feels real, or this idea you need to give a deeply technical or novel talk for it to count.

But you know what? If I can say one thing in this book about giving talks, it’s do what works for you. Truly.

Of course, it’s hard to move past the impulse to embrace rules—it’s reassuring to think we have a straightforward map to success. We try to mimic speakers who capture our attention or those whom our peers praise. We hold up examples of “ideal” presentation styles, and we instruct new speakers to follow suit. We see a lot of the same people, and we can’t help but absorb a lot of the same opinions on what a good speaker looks like or sounds like.

Just because we’ve built a system, it doesn’t mean it’s right. What we need to see represented onstage is a spectrum of speakers with different insights and ways to teach us about them. Your voice is valuable, and your own. If you choose to share it, we will all certainly be the better for it.

Public speaking is a journey that, like any other, involves practice and time to make you feel comfortable and successful. Take heart from Tiffani Jones Brown:

The worst case scenario is your talk flops—in which case you’ll be stronger for it. The likelier scenario is you’ll give a couple decent talks, followed by better ones, followed by even better ones, until you give one that really makes a difference.

I don’t want to set out any rules in this book—forget them. What I do hope is to help you forge your own path, so you make your way to that talk that makes a difference. Let’s get started.

Want to read more?

This excerpt from Demystifying Public Speaking will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

Demystifying Public Speaking by Lara Hogan


This week's sponsor: ZARGET

ZARGET: Analytics Tool for designers. Capture exactly how users experience your website. Settle design debates with data.



PS Wish Photoshop Tutorials
Tutorial Man Wallpaper Stock  More