On Empathy

I ♡ our industry. Thanks to the blessing of View Source, the web has been egalitarian from the start — all we need are a computer, an internet connection, and the determination to learn. The lack of accreditation means we’re hired on the strength of our portfolio or GitHub account, and in general our industry feels like a meritocracy — do great work and you’ll be recognised for it.

I also feel despite the stereotypes that we’re on the whole a sociable and easy-going bunch, both online and In Real Life. We like attending the many conferences and meetups, and the leaders of our industry are amazingly approachable. Meeting others at events I feel a shared love for technology and making the world a better place, a wonderful “these are my people” feeling. I’d even go so far as to say that as a group we’re caring, of above average intelligence and attractiveness, and of course empathetic.

Well, I certainly considered myself to be empathetic. That is, until I discovered I’m not.

A fish in water

I realised this talking to my daughter about her teddy (bear with me…). She replied to “Come get him” with “You mean her”. I’d subconsciously perceived teddy bears as masculine, as if English words were gendered (like “L’ours en peluche”), but for my daughter the gender was naturally feminine. To think about this, it’s obvious. But for me this conversation was the difference between thinking and empathising. I use gender-neutral words with her now, like waiting for the “green person” to cross the road, and referring to toys as “they”, not “he” or “she”.

Coming to Japan was also an eye-opening experience for me. Along with the amazing experiences and wonderful people, many things I’d taken for granted or never even thought about are … different here. One that surprised me was how I reacted to being treated differently because I looked Western. Generally this attention has been positive — people making a fuss of me. But sometimes I just don’t feel like answering “Are you American?” again, or being complimented on my ability to use chopsticks. Sometimes I just want to be treated like everyone else. I soon learned those questions are just easy conversation starters for Japanese people not used to talking with foreigners. But even knowing that I still find this peculiar feeling of being “the other” can be unsettling, even when the attention is positive.

Empathy and us

Seeing things from someone else’s perspective is easy to intellectualise, but actually doing it is completely different, and considerably harder. People talk about walking a mile in someone else’s shoes, but few ever tie up the laces and do it. However, empathy is a core competency for us — we make things for people to use. If we don’t help the people using what we’ve made, we’ve failed, no matter how beautiful the design or elegant the code. This is incredibly obvious, but because we naturally assume other people are like us, it’s easy to think empathy without feeling it. We all have a self-image of being empathetic, and nobody says empathy is hard. But it is.

Luckily many of our best practices are exercises in empathy: user testing, personas, site visits, stakeholder interviews and even client meetings all provide valuable chances to see a project through other people’s eyes.

Level up in empathy

The easiest thing we can do to become more empathetic is to improve communication with clients, colleagues, and the people who will use our projects. It’s easy to assume motivations and guess at intentions — much of what we perceive is actually internally constructed, so listening to what is said (rather than hearing what we expect) can be surprisingly difficult. Frequent face-to-face communication helps, and building these relationships naturally makes us more empathetic.

When someone disagrees, try to avoid the temptation to “win the debate”, and instead focus on understanding what they believe, and why. A good test is how you react to criticism — treating it as potentially valuable feedback from a different perspective, and empathising with the person, helps to avoid taking it as an attack.

When you’re starting a new project, try to arrange time with someone who will use what you’re making, and if applicable consider volunteering to help them do that task for an hour or two. People are inventive and unpredictable, so you’ll probably discover some novel workflow, a feature that isn’t in the brief, or just a different perspective. Meeting people who’ll actually use what you produce is also a great help for frequent informal user testing and feedback later on.

More generally, try to get out of your comfort zone — learn new things unrelated to web development, talk to people from different walks of life, volunteer, travel somewhere you don’t speak the language. Although having kids might be a little extreme, using the web while holding a baby is a great insight into why usability is so important. Trying to use the web in a different language is also eye-opening, and has helped me realise the importance of copywriting, and consider how a non-native speaker might use what I make. Try ordering something on the Japanese Apple store, and see how far you can get!

Our self-image of (and job requirement for) empathy also makes recent online discussions of sexism in tech, with female beer pourers and all-male conference lineups, seem even more out-of-place to me. Reading @yesyouresexist is an amusing (and depressing) reminder of how unempathetic and self-deluded other people can be. But we are also “those people” on occasion, without even realising.

Luckily, knowledge is half the battle — just knowing that empathy is hard helps. As the year kicks off, let’s go beyond just “keeping the user in mind”, and aim for a more fundamental empathy with everyone involved. In addition to better working relationships, it’ll make our work noticeably better too.

♡

I recently moved, from Osaka to Tokyo. Packing your life into boxes is exhausting, but I found the “deciding what to keep” part reflective. I rediscovered some great books I’d bought and read years ago, but had not opened since. Revisiting Müller-Brockmann’s Grid Systems in Graphic Design again, I had fresh insights on how I could apply it to web design. Part of this was refreshing my memory, but there was more — I realised I’m a different person compared to when I read it the first time. At that stage I hadn’t designed to a baseline measure, and everything I’ve done since then (work, discussions, learning about Flexbox and CSS Grid Layout…) has affected my viewpoint.

I feel the same as the young me of 15 years ago, but my perspective has been continually changing. Realising this self-delusion is useful for judging my memories, and considering the viewpoints of others. Now I’m re-reading other “design thinking” books, to see what extra things the “now” me will perceive.

Just like great movies, the best books and articles reveal more nuance the second or third time around. If you haven’t recently, re-read the best article of our profession — John Allsopp’s A Dao of Web Design, and reconsider this near-13 year old wisdom through the lens of Responsive Web Design and the zombie apocalypse of devices.

The name of things

Linguistic relativity is the idea that language influences the way people think — the names we use can have a powerful effect on how we perceive things.

Horace Dediu points out that the names we use for the supercomputers we have with us are from a different time.

I wonder what my kids will be calling these devices in ten years. For me “computer” already seems a term from an earlier time: the time before everything was a computer.

The labels we use in web design can also subtly affect our perception. For example, talking about web pages can lead us to perceive and design them as static comps with fixed dimensions, no different from print design.

What other names come to us with the mental baggage of past association? By considering their connotations, we can at least be more aware of their influence on us, and avoid the narrow, predetermined path of the obvious.

Have a reason

Graphic design is an odd bird. It’s part art and part science, and often treated as mostly decorative. But armed with your favorite tools of the trade, it’s also very satisfying.

Teaching myself graphic design as a student, I created layouts based on what felt good. I was into that edgy, “creative” stuff. If you’ve got a great eye that may be enough, but now I also use this design golden rule: have a reason. Typography, grid-based layout, and basic design principles (balance, hierarchy, scale…) are essential foundations of great graphic design. Instead of throwing elements at a canvas and seeing what sticks, use these fundamentals to place them deliberately. Have a reason for every design decision. By doing so, you’ll increase resonance in a design.

In contrast, small differences (such as almost identical font sizes, or slightly unaligned objects) detract from this, often appearing as mistakes even if intentional. This gives me another rule: make differences obvious. If you’re going to break the rules (of your grid etc.), do so deliberately and make it count. Luckily, building a strong chorus of resonance in your design causes deliberate differences to stand out even more sharply.

Having a reason behind everything you do gives your work depth and subtlety. It shows you’ve thought carefully about each aspect, and lets you explain each decision.

Have a reason.

CSS: reset or normalize?

Building for the web can be like building on quicksand. Browsers have tended to do mostly the same thing, but have occasional, maddeningly unpredictable differences. For example, browsers all come with “user agent stylesheets” — a default set of CSS styles, so that a heading looks like a heading etc., even before you style the page¹. Of course, every browser engine uses a slightly different set of defaults.

One example of this was default list styles, where Internet Explorer and Opera initially² indented lists with margin-left: 30pt; in their default browser stylesheets, while Firefox and KHTML went with padding-left: 40px;. If you wanted to change the default indent, specifying ul {padding-left: 0;} would lead to very different results across browsers.

CSS resets³

To get a little stability, some developers reset all margins and padding using the universal selector:

* {margin: 0; padding: 0;}

With this at the start of your stylesheet, when you specified a list indent you got what you expected. However, using * meant the default margin and padding were nuked for all elements, which became painful as soon as you added a <form> element.

Tantek Çelik and Eric Meyer started discussing a more targeted way to address user agent style differences in 2004, with the YUI CSS Reset appearing in 2006, and the Meyer Reset in 2007.

The point of a reset is to zero out as much as possible … [and] to serve as a starting point for your own baseline styles — Eric Meyer

Here’s the first rule of Eric’s current (v2.0) CSS Reset:

html, body, div, span, applet, object, iframe,
  h1, h2, h3, h4, h5, h6, p, blockquote, pre,
  a, abbr, acronym, address, big, cite, code,
  del, dfn, em, img, ins, kbd, q, s, samp,
  small, strike, strong, sub, sup, tt, var,
  b, u, i, center,
  dl, dt, dd, ol, ul, li,
  fieldset, form, label, legend,
  table, caption, tbody, tfoot, thead, tr, th, td,
  article, aside, canvas, details, embed, 
  figure, figcaption, footer, header, hgroup, 
  menu, nav, output, ruby, section, summary,
  time, mark, audio, video {
  	margin: 0;
  	padding: 0;
  	border: 0;
  	font-size: 100%;
  	font: inherit;
  	vertical-align: baseline;
  }
  …

This resets several properties on many (but not all) elements back to the equivalent of plain text. Because only appropriate elements are reset, this avoids some of the problems of * {margin: 0; padding: 0;}. We can then define styles for these reset “unstyled” properties, safe in the knowledge we’re building on a stable, cross-browser base. This “unstyled” styling also acts as a reminder to consciously set appropriate styles for these elements.

Problems with CSS resets

CSS resets have been a lifesaver, but especially with the rise of frameworks they are now often used as-is. For example, Eric assumed people would build on the reset styles he proposed, overriding them as appropriate, and version 1 of the Meyer Reset included this rule for a time:

/* remember to define focus styles! */
  :focus {
  	outline: 0;
  }

Sadly, not everyone did define focus styles, and Eric has removed this from v2.

Using a reset can also start to feel a little perverse. Resetting browser default styles does force us to deliberate on how each element should appear, helping ensure we use elements for their semantics and not their default styling. But for elements like i and em that’s almost always the browser default style. Other default browser styles, like the text sizes for headings which used to be ridiculously large, have changed to become passable defaults. There’s also the problem of someone wanting to use a reset HTML element after handoff, still with only the “unstyled” reset styles specified.

For me the main issue with resets is inheritance, leading to spam in your browser dev tools. When you’re trying to track down a CSS problem on a deeply nested element in someone else’s code, this does not help:

Normalize.css

Nicolas Gallagher and Jonathan Neal have taken a different approach with Normalize.css, “a small CSS file that provides better cross-browser consistency in the default styling of HTML elements”. As with CSS resets it gives us a reliable cross-browser starting point — the main reason for using a reset in the first place — but the two approaches are philosophically different.

CSS resets override user agent styles to return many elements back to an “unstyled” state, a level foundation we can safely build upon. However, we then need to define styles for most elements before we can build with them. Normalize.css instead addresses only the inconsistencies between user agent default styles, choosing the most appropriate default where there are differences. We get a safe cross-browser foundation here too, but one that includes normalized user agent styles as basic building materials ready for use. It’s basically a kind of an idealized, cross-browser version of CSS 2.1’s Default style sheet. For both ways we then need to add our own overriding styles to build the view, but because the browser defaults remain with Normalize.css, in general fewer styles need to be added.

Because the changes in Normalize.css are a lot more targeted, there isn’t an inheritance cascade of overwritten rules in your browser’s developer tools. Here’s a simple <ul>: “unstyled”, with the Meyer Reset, and with Normalize.css versions 1 and 2:

You can clearly see the difference in philosophy, with the Meyer Reset example appearing as two lines of plain text with no margins, padding or bullets, while the Normalize.css examples are similar to the default styling. The difference in the styles applied to this <ul> are also easy to see.

However, these are not all the styles being applied to the <ul>. For comparison, here’s the same “unstyled” screenshot, but with the user agent styles visible, in Firefox 21 and Opera Next 15:

This is the CSS that we’re resetting or normalizing.

Normalize.css version 2 supports modern browsers plus IE 8, whereas version 1 also contains additional support for legacy browsers like IE 6 and 7. These older browsers need more normalization, and this can have minor disadvantages, for example the added vertical margins for the nested list in the Normalize.css v1 screenshot above. This split into two versions is useful if you no longer need to provide old browsers with Grade A support, and also if you want to learn about old browser quirks.

Normalize.css also helps correct some browser bugs, including “display settings for HTML5 elements, correcting font-size for preformatted text, SVG overflow in IE9, and many form-related bugs across browsers and operating systems”. For example, the following CSS fixes WebKit issues with HTML5’s new <input type="search"> element:

/**
   * 1. Address `appearance` set to `searchfield` in Safari 5 and Chrome.
   * 2. Address `box-sizing` set to `border-box` in Safari 5 and Chrome
   *    (include `-moz` to future-proof).
   */

  input[type="search"] {
      -webkit-appearance: textfield; /* 1 */
      -moz-box-sizing: content-box;
      -webkit-box-sizing: content-box; /* 2 */
      box-sizing: content-box;
  }

Without it, WebKit’s default use of -webkit-appearance: searchfield; for type="search" prevents the styling of font, padding, border, and background properties on OS X and iOS, and gives buggy behavior for the border property on Windows.

An added bonus is Normalize.css is heavily commented and well-documented, helping you learn why each rule is there. This does make it noticeably longer than CSS resets, but when minified and Gzipped even the larger Normalize.css v1 is only 1KB.

Conclusion

While philosophically different to CSS resets like the Meyer Reset, Normalize.css is very much carrying on the same tradition, continuing in the footsteps of Tantek and Eric. You might even already be using it — it’s a core part of HTML5 Boilerplate, Bootstrap, and YUI’s new Pure.

User agent stylesheets are converging, and hopefully one day we won’t need to reset or normalize. There’s even a valid argument for not worrying about small differences between browsers (although being a Snook-level genius helps with that). But for now if you’re using a CSS reset, or nothing at all, give Normalize.css a try on your next project.

Addenda

1. [1] You can see the user agent style sheets for Mozilla, WebKit, and IE. CSS2.1 User Agent Style Sheet Defaults highlights the differences across (older) browsers. These styles also include things like style {display: none;} — try adding style {display: block;} to your CSS and see what happens.
2. [2] Since then, all browsers have migrated to setting list indenting via padding-left or padding-start, with IE7 being the last IE browser to use margin-left for this.
3. [3] For detailed background on the history of CSS resets, read The History of CSS Resets, by Michael Tuck.

My thanks to Eric Meyer and Nicolas Gallagher for their feedback on this article, and for these wonderful tools.

Postscript: While nuking margins and padding on all elements with * {margin: 0; padding: 0;} is gonna be a bad time, there is one universal selector-based reset you should still consider: * {box-sizing: border-box;}. This changes padding and border to being part of an element’s width, rather than additional to it. For more information, check out Paul Irish’s article “box-sizing: border-box FTW”.