Category Archives: {categories backspace="2" show_group="3"}<a href="/topic/{category_url_title}">{category_name}</a>, {/categories}

Live Font Interpolation on the Web

Posted by The fine folks at A List Apart |20 Jan 15 |

We all want to design great typographic experiences. We also want to serve users on an increasing range of devices and contexts. But today’s webfonts tie our responsive sites and applications to inflexible type that doesn’t scale. As a result, our users get poor reading experiences and longer loading times from additional font weights.

As typographers, designers, and developers, we can solve this problem. But we’ll need to work together to make webfonts more systemized and context-aware. Live webfont interpolation—the modification of a font’s design in the browser—exists today and can serve as an inroad for using truly responsive typography.

An introduction to font interpolation

Traditional font interpolation is a process used by type designers to generate new intermediary fonts from a series of master fonts. Master fonts represent key archetypal designs across different points in a font family. By using math to automatically find the in-betweens of these points, type designers can derive additional font variants/weights from interpolation instead of designing each one manually. We can apply the same concept to our webfonts to serve different font variants for our users. For example, the H letter (H glyph) in this proof of concept (currently for desktop browsers) has light and heavy masters in order to interpolate a new font weight.


Diagram of three H letters of thin, medium, and bold thickness with poles and axes labeled.

An interpolated H glyph using 50 percent of the light weight and 50 percent of the black weight. There can be virtually any number of poles and axes linked to combinations of properties, but in this example everything is being interpolated at once between two poles.

Normally these interpolated type designs end up being exported as separate fonts. For example, the TheSans type family contains individual font files for Extra Light, Light, Semi Light, Plain, SemiBold, Bold, Extra Bold, and Black weights generated using interpolation.


An example of all the fonts in the TheSans type family.

Individual font weights generated from interpolation from the TheSans type family.

Interpolation can alter more than just font weight. It also allows us to change the fundamental structure of a font’s glyphs. Things like serifs (or lack thereof), stroke contrast/direction, and character proportions can all be changed with the right master fonts.


Diagram of a three-dimensional cube of e letters showing how the appearance of the e can be changed gradually.

A Noordzij cube showing an interpolation space with multiple poles and axes.

Although generating fonts with standard interpolation gives us a great deal of flexibility, webfont files are still static in their browser environment. Because of this, we’ll need more to work with the web’s responsiveness.

Web typography’s medium

Type is tied to its medium. Both movable type and phototypesetting methods influenced the way that type was designed and set in their time. Today, the inherent responsiveness of the web necessitates flexible elements and relative units—both of which are used when setting type. Media queries are used to make more significant adjustments at different breakpoints.


A diagram of common responsive web design breakpoints, illustrating how the menu is hidden behind a triple-bar icon when there is no longer enough space to fit the text-based menu in the header.

An approximation of typical responsive design breakpoints.

However, fonts are treated as another resource that needs to be loaded, instead of a living, integral part of a responsive design. Changing font styles and swapping out font weights with media queries represent the same design compromises inherent in breakpoints.


Diagram comparing how both breakpoints and fonts require a design compromise between two ideal designs.

Breakpoints set by media queries often reflect the best-case design tradeoffs—often during a key breakpoint, like collapsing the navigation under a menu icon. Likewise, siloed font files often reflect best-case design tradeoffs—there’s no font in between The Mix Light and The Sans SemiLight.

Enter live webfont interpolation

Live webfont interpolation just means interpolating a font on the fly inside the browser instead of being exported as a separate file resource. By doing this, our fonts themselves can respond to their context. Because type reflows and is partially independent of a responsive layout, there’s less of a need to set abrupt points of change. Fonts can adhere to bending points—not just breaking points—to adapt type to the design.


Diagram showing a thin H letter on the left and a bold one on the right. In between is an empty space illustrating how an H of any weight can be created using the thin and bold letters.

Live interpolation doesn’t have to adhere to any specific font weight or design.

Precise typographic control

With live font interpolation, we can bring the same level of finesse to our sites and applications that type designers do. Just as we take different devices into account when designing, type designers consider how type communicates and performs at small sizes, low screen resolutions, large displays, economical body copy, and everything in between. These considerations are largely dependent on the typeface’s anatomy, which requires live font interpolation to be changed in the browser. Properties like stroke weight and contrast, counter size, x-height, and character proportions all affect how users read. These properties are typically balanced across a type family. For example, the JAF Lapture family includes separate designs for text, display, subheads, and captions. Live font interpolation allows a single font to fit any specific role. The same font can be optimized for captions set at .8em, body text set at 1.2em, or H1s set at 4.8em in a light color.


Comparison of the headline “LIVE FONT INTERPOLATION” set in the text version and the display version of the JAF Lapture font, illustrating how the display version reads better visually.

JAF Lapture Display (top) and JAF Lapture Text (bottom). Set as display type at 40 pixels, rendered on Chrome 38. Note how the display version uses thinner stroke weights and more delicate features that support its sharp, authoritative character without becoming too heavy at larger sizes. (For the best examples, compare live type in your own device and browser.)


A paragraph typeset in the text version of JAF Lapture, illustrating how the text version reads better.

JAF Lapture Text. Set as body copy at 16 pixels, rendered on Chrome. Note how features like the increased character width, thicker stroke weights, and shorter ascenders and descenders make the text version more appropriate for smaller body copy set in paragraph blocks.


A paragraph typeset in the display version of JAF Lapture, illustrating how the text version reads better.

JAF Lapture Display. Set as body copy at 16 pixels, rendered on Chrome.

Live font interpolation also allows precise size-specific adjustments to be made for the different distances at which a reader can perceive type. Type can generally remove finer typographic details at sizes where they won’t be perceived by the reader—like on far-away billboards, or captions and disclaimers set at small sizes.

Adaptive relationships

Live font interpolation’s context-awareness builds inherent flexibility into the font’s design. A font’s legibility and readability adjustments can be linked to accessibility options. People with low vision who increase the default text size or zoom the browser can get type optimized for them. Fonts can start to respond to combinations of factors like viewport size, screen resolution, ambient light, screen brightness, and viewing distance. Live font interpolation offers us the ability to extend great reading experiences to everyone, regardless of how their context changes.

Live font interpolation on the web today

While font interpolation can be done with images or canvas, these approaches don’t allow text to be selectable, accessible via screen readers, or crawlable by search engines. SVG fonts offer accessible type manipulation, but they currently miss out on the properties that make a font robust: hinting and OpenType tables with language support, ligatures, stylistic alternates, and small caps. An SVG OpenType spec exists, but still suffers from limited browser support.

Unlike SVG files, which are made of easily modifiable XML, font file formats (ttf, otf, woff2, etc.) are compiled as binary files, complicating the process of making live changes. Sets of information describing a font are stored in tables. These tables can range from things like a head table containing global settings for the font to a name table holding author’s notes. Different font file formats contain different sets of information. For example, the OpenType font format, a superset of TrueType, contains additional tables supporting more features and controls (per Microsoft’s OpenType spec):

  • cmap: Character to glyph mapping
  • head: Font header
  • hhea: Horizontal header
  • hmtx: Horizontal metrics
  • maxp: Maximum profile
  • name: Naming table
  • OS/2: OS/2 and Windows-specific metrics
  • post: PostScript information

For live webfont interpolation, we need a web version of something like ttx, a tool for converting font files into a format we can read and parse.

Accessing font tables

Projects like jsfont and opentype.js allow us to easily access and modify font tables in the browser. Much like a game of connect-the-dots, each glyph (the glyp table in OpenType) is made up of a series of points positioned on an x-y grid.


Diagram showing an H glyph made up of individual points.

A series of numbered points on an H glyph. The first x-y coordinate set determines where the first point is placed on the glyph’s grid and is relative to the grid itself. After the first point, all points are relative to the point right before it. Measurements are set in font design units.

Interpolation involves the modification of a glyph to fall somewhere between master font poles—similar to the crossfading of audio tracks. In order to make changes to glyphs on the web with live webfonts, we need to compare and move individual points.


Diagram showing a comparison of the points for a thin and a bold H glyph.

The first points for the light and heavy H glyph have different x coordinates, so they can be interpolated.


Diagram showing the averaging of the points for a thin and a bold H glyph.

Interpolating a glyph via coordinates is essentially a matter of averaging points. More robust methods exist, but aren’t available for the web yet.

Other glyph-related properties (like xMin and xMax) also must be interpolated in order to ensure the glyph bounding box is large enough to show the whole glyph. Additionally, padding—or bearings, in font terminology—can be added to position a glyph in its bounding box (leftsidebearing and width properties). This becomes important when considering the typeface’s larger system. Any combination of glyphs can end up adjacent to each other, so changes must be made considering their relationship to the typeface’s system as a whole.


Diagram showing all the font properties of an H glyph: advance width (the width of the letter space), yMin, yMax, xMax, xMin, width, and height.

Glyph properties. Both xMin/xMax and advancewidth must be scaled in addition to the glyph’s coordinate points.

Doing it responsibly

Our job is to give users the best experience possible—whether they’re viewing the design on a low-end mobile device, a laptop with high resolution, or distant digital signage. Both poorly selected and slowly loading fonts hinder the reading experience. With CSS @fontface as a baseline, fonts can be progressively enhanced
with interpolation where appropriate. Users on less capable devices and browsers are best served with standard @fontface fonts.

After the first interpolation and render, we can set a series of thresholds where re-renders are triggered, to avoid constant recalculations for insignificant changes (like every single change in width as the browser is resized). Element queries are a natural fit here (pun intended) because they’re based at the module level, which is where type often lives within layouts. Because information for interpolation is stored with JavaScript, there’s no need to load an entirely different font—just the data required for interpolation. Task runners can also save this interpolation data in JavaScript during the website or application build process, and caching can be used to avoid font recalculations when a user returns to a view a second time.

Another challenge is rendering interpolated type quickly and smoothly. Transitioning in an interpolated font lined up with the original can minimize the visual change. Other techniques, like loading JavaScript asynchronously, or just caching the font for next time if the browser cannot load the font fast enough, could also improve perceived performance.

As noted by Nick Sherman, all these techniques illustrate the need for a standardized font format that wraps everything up into a single sustainable solution. Modifying live files with JavaScript serves only as an inroad for future font formats that can adapt to the widely varied conditions they’re subjected to.

Fonts that interpolate well

Like responsive design, font interpolation requires considerations for the design at both extremes, as well as everything in the middle. Finch—the typeface in these examples—lends itself well to interpolation. David Jonathan Ross, Finch’s designer, explains:

Interpolation is easiest when letter structure, contrast, and shapes stay relatively consistent across a family. Some typeface designs (like Finch) lend themselves well to that approach, and can get by interpolating between two extremes. However, other designs need more care and attention when traversing axes like weight or width. For example, very high-contrast or low-contrast designs often require separately-drawn poles between the extremes to help maintain the relationship between thick and thin, especially as certain elements are forced to get thin, such as the crossbar of the lowercase ’e’. Additionally, some designs get so extreme that letter shape is forced to change, such as replacing a decorative cursive form of lowercase ’k’ with a less-confusing one at text sizes, or omitting the dollar sign’s bar in the heaviest weights.

Finch’s consistency across weights allows it to avoid a complex interpolation space—there’s no need for additional master fonts or rules to make intermediate changes between two extremes.

Glyphs also don’t have to scale linearly across an axis’s delta. Guidelines like Lucas De Groot’s interpolation theory help us increase the contrast between near-middle designs, which may appear too similar to the user.

A call to responsive typography

We already have the tools to make this happen. For example, jsfont loads a font file and uses the DataView API to create a modifiable font object that it then embeds through CSS @fontface. The newer project opentype.js has active contributors and a robust API for modifying glyphs.

As font designers, typographers, designers, and developers, the only way to take advantage of responsive typography on the web is to work together and make sure it’s done beautifully and responsibly. In addition to implementing live webfont interpolation in your projects, you can get involved in the discussion, contribute to projects like opentype.js, and let type designers know there’s a demand for interpolatable fonts.

Live Font Interpolation on the Web

Posted by The fine folks at A List Apart |20 Jan 15 |

We all want to design great typographic experiences. We also want to serve users on an increasing range of devices and contexts. But today’s webfonts tie our responsive sites and applications to inflexible type that doesn’t scale. As a result, our users get poor reading experiences and longer loading times from additional font weights.

As typographers, designers, and developers, we can solve this problem. But we’ll need to work together to make webfonts more systemized and context-aware. Live webfont interpolation—the modification of a font’s design in the browser—exists today and can serve as an inroad for using truly responsive typography.

An introduction to font interpolation

Traditional font interpolation is a process used by type designers to generate new intermediary fonts from a series of master fonts. Master fonts represent key archetypal designs across different points in a font family. By using math to automatically find the in-betweens of these points, type designers can derive additional font variants/weights from interpolation instead of designing each one manually. We can apply the same concept to our webfonts to serve different font variants for our users. For example, the H letter (H glyph) in this proof of concept (currently for desktop browsers) has light and heavy masters in order to interpolate a new font weight.


Diagram of three H letters of thin, medium, and bold thickness with poles and axes labeled.

An interpolated H glyph using 50 percent of the light weight and 50 percent of the black weight. There can be virtually any number of poles and axes linked to combinations of properties, but in this example everything is being interpolated at once between two poles.

Normally these interpolated type designs end up being exported as separate fonts. For example, the TheSans type family contains individual font files for Extra Light, Light, Semi Light, Plain, SemiBold, Bold, Extra Bold, and Black weights generated using interpolation.


An example of all the fonts in the TheSans type family.

Individual font weights generated from interpolation from the TheSans type family.

Interpolation can alter more than just font weight. It also allows us to change the fundamental structure of a font’s glyphs. Things like serifs (or lack thereof), stroke contrast/direction, and character proportions can all be changed with the right master fonts.


Diagram of a three-dimensional cube of e letters showing how the appearance of the e can be changed gradually.

A Noordzij cube showing an interpolation space with multiple poles and axes.

Although generating fonts with standard interpolation gives us a great deal of flexibility, webfont files are still static in their browser environment. Because of this, we’ll need more to work with the web’s responsiveness.

Web typography’s medium

Type is tied to its medium. Both movable type and phototypesetting methods influenced the way that type was designed and set in their time. Today, the inherent responsiveness of the web necessitates flexible elements and relative units—both of which are used when setting type. Media queries are used to make more significant adjustments at different breakpoints.


A diagram of common responsive web design breakpoints, illustrating how the menu is hidden behind a triple-bar icon when there is no longer enough space to fit the text-based menu in the header.

An approximation of typical responsive design breakpoints.

However, fonts are treated as another resource that needs to be loaded, instead of a living, integral part of a responsive design. Changing font styles and swapping out font weights with media queries represent the same design compromises inherent in breakpoints.


Diagram comparing how both breakpoints and fonts require a design compromise between two ideal designs.

Breakpoints set by media queries often reflect the best-case design tradeoffs—often during a key breakpoint, like collapsing the navigation under a menu icon. Likewise, siloed font files often reflect best-case design tradeoffs—there’s no font in between The Mix Light and The Sans SemiLight.

Enter live webfont interpolation

Live webfont interpolation just means interpolating a font on the fly inside the browser instead of being exported as a separate file resource. By doing this, our fonts themselves can respond to their context. Because type reflows and is partially independent of a responsive layout, there’s less of a need to set abrupt points of change. Fonts can adhere to bending points—not just breaking points—to adapt type to the design.


Diagram showing a thin H letter on the left and a bold one on the right. In between is an empty space illustrating how an H of any weight can be created using the thin and bold letters.

Live interpolation doesn’t have to adhere to any specific font weight or design.

Precise typographic control

With live font interpolation, we can bring the same level of finesse to our sites and applications that type designers do. Just as we take different devices into account when designing, type designers consider how type communicates and performs at small sizes, low screen resolutions, large displays, economical body copy, and everything in between. These considerations are largely dependent on the typeface’s anatomy, which requires live font interpolation to be changed in the browser. Properties like stroke weight and contrast, counter size, x-height, and character proportions all affect how users read. These properties are typically balanced across a type family. For example, the JAF Lapture family includes separate designs for text, display, subheads, and captions. Live font interpolation allows a single font to fit any specific role. The same font can be optimized for captions set at .8em, body text set at 1.2em, or H1s set at 4.8em in a light color.


Comparison of the headline “LIVE FONT INTERPOLATION” set in the text version and the display version of the JAF Lapture font, illustrating how the display version reads better visually.

JAF Lapture Display (top) and JAF Lapture Text (bottom). Set as display type at 40 pixels, rendered on Chrome 38. Note how the display version uses thinner stroke weights and more delicate features that support its sharp, authoritative character without becoming too heavy at larger sizes. (For the best examples, compare live type in your own device and browser.)


A paragraph typeset in the text version of JAF Lapture, illustrating how the text version reads better.

JAF Lapture Text. Set as body copy at 16 pixels, rendered on Chrome. Note how features like the increased character width, thicker stroke weights, and shorter ascenders and descenders make the text version more appropriate for smaller body copy set in paragraph blocks.


A paragraph typeset in the display version of JAF Lapture, illustrating how the text version reads better.

JAF Lapture Display. Set as body copy at 16 pixels, rendered on Chrome.

Live font interpolation also allows precise size-specific adjustments to be made for the different distances at which a reader can perceive type. Type can generally remove finer typographic details at sizes where they won’t be perceived by the reader—like on far-away billboards, or captions and disclaimers set at small sizes.

Adaptive relationships

Live font interpolation’s context-awareness builds inherent flexibility into the font’s design. A font’s legibility and readability adjustments can be linked to accessibility options. People with low vision who increase the default text size or zoom the browser can get type optimized for them. Fonts can start to respond to combinations of factors like viewport size, screen resolution, ambient light, screen brightness, and viewing distance. Live font interpolation offers us the ability to extend great reading experiences to everyone, regardless of how their context changes.

Live font interpolation on the web today

While font interpolation can be done with images or canvas, these approaches don’t allow text to be selectable, accessible via screen readers, or crawlable by search engines. SVG fonts offer accessible type manipulation, but they currently miss out on the properties that make a font robust: hinting and OpenType tables with language support, ligatures, stylistic alternates, and small caps. An SVG OpenType spec exists, but still suffers from limited browser support.

Unlike SVG files, which are made of easily modifiable XML, font file formats (ttf, otf, woff2, etc.) are compiled as binary files, complicating the process of making live changes. Sets of information describing a font are stored in tables. These tables can range from things like a head table containing global settings for the font to a name table holding author’s notes. Different font file formats contain different sets of information. For example, the OpenType font format, a superset of TrueType, contains additional tables supporting more features and controls (per Microsoft’s OpenType spec):

  • cmap: Character to glyph mapping
  • head: Font header
  • hhea: Horizontal header
  • hmtx: Horizontal metrics
  • maxp: Maximum profile
  • name: Naming table
  • OS/2: OS/2 and Windows-specific metrics
  • post: PostScript information

For live webfont interpolation, we need a web version of something like ttx, a tool for converting font files into a format we can read and parse.

Accessing font tables

Projects like jsfont and opentype.js allow us to easily access and modify font tables in the browser. Much like a game of connect-the-dots, each glyph (the glyp table in OpenType) is made up of a series of points positioned on an x-y grid.


Diagram showing an H glyph made up of individual points.

A series of numbered points on an H glyph. The first x-y coordinate set determines where the first point is placed on the glyph’s grid and is relative to the grid itself. After the first point, all points are relative to the point right before it. Measurements are set in font design units.

Interpolation involves the modification of a glyph to fall somewhere between master font poles—similar to the crossfading of audio tracks. In order to make changes to glyphs on the web with live webfonts, we need to compare and move individual points.


Diagram showing a comparison of the points for a thin and a bold H glyph.

The first points for the light and heavy H glyph have different x coordinates, so they can be interpolated.


Diagram showing the averaging of the points for a thin and a bold H glyph.

Interpolating a glyph via coordinates is essentially a matter of averaging points. More robust methods exist, but aren’t available for the web yet.

Other glyph-related properties (like xMin and xMax) also must be interpolated in order to ensure the glyph bounding box is large enough to show the whole glyph. Additionally, padding—or bearings, in font terminology—can be added to position a glyph in its bounding box (leftsidebearing and width properties). This becomes important when considering the typeface’s larger system. Any combination of glyphs can end up adjacent to each other, so changes must be made considering their relationship to the typeface’s system as a whole.


Diagram showing all the font properties of an H glyph: advance width (the width of the letter space), yMin, yMax, xMax, xMin, width, and height.

Glyph properties. Both xMin/xMax and advancewidth must be scaled in addition to the glyph’s coordinate points.

Doing it responsibly

Our job is to give users the best experience possible—whether they’re viewing the design on a low-end mobile device, a laptop with high resolution, or distant digital signage. Both poorly selected and slowly loading fonts hinder the reading experience. With CSS @fontface as a baseline, fonts can be progressively enhanced
with interpolation where appropriate. Users on less capable devices and browsers are best served with standard @fontface fonts.

After the first interpolation and render, we can set a series of thresholds where re-renders are triggered, to avoid constant recalculations for insignificant changes (like every single change in width as the browser is resized). Element queries are a natural fit here (pun intended) because they’re based at the module level, which is where type often lives within layouts. Because information for interpolation is stored with JavaScript, there’s no need to load an entirely different font—just the data required for interpolation. Task runners can also save this interpolation data in JavaScript during the website or application build process, and caching can be used to avoid font recalculations when a user returns to a view a second time.

Another challenge is rendering interpolated type quickly and smoothly. Transitioning in an interpolated font lined up with the original can minimize the visual change. Other techniques, like loading JavaScript asynchronously, or just caching the font for next time if the browser cannot load the font fast enough, could also improve perceived performance.

As noted by Nick Sherman, all these techniques illustrate the need for a standardized font format that wraps everything up into a single sustainable solution. Modifying live files with JavaScript serves only as an inroad for future font formats that can adapt to the widely varied conditions they’re subjected to.

Fonts that interpolate well

Like responsive design, font interpolation requires considerations for the design at both extremes, as well as everything in the middle. Finch—the typeface in these examples—lends itself well to interpolation. David Jonathan Ross, Finch’s designer, explains:

Interpolation is easiest when letter structure, contrast, and shapes stay relatively consistent across a family. Some typeface designs (like Finch) lend themselves well to that approach, and can get by interpolating between two extremes. However, other designs need more care and attention when traversing axes like weight or width. For example, very high-contrast or low-contrast designs often require separately-drawn poles between the extremes to help maintain the relationship between thick and thin, especially as certain elements are forced to get thin, such as the crossbar of the lowercase ’e’. Additionally, some designs get so extreme that letter shape is forced to change, such as replacing a decorative cursive form of lowercase ’k’ with a less-confusing one at text sizes, or omitting the dollar sign’s bar in the heaviest weights.

Finch’s consistency across weights allows it to avoid a complex interpolation space—there’s no need for additional master fonts or rules to make intermediate changes between two extremes.

Glyphs also don’t have to scale linearly across an axis’s delta. Guidelines like Lucas De Groot’s interpolation theory help us increase the contrast between near-middle designs, which may appear too similar to the user.

A call to responsive typography

We already have the tools to make this happen. For example, jsfont loads a font file and uses the DataView API to create a modifiable font object that it then embeds through CSS @fontface. The newer project opentype.js has active contributors and a robust API for modifying glyphs.

As font designers, typographers, designers, and developers, the only way to take advantage of responsive typography on the web is to work together and make sure it’s done beautifully and responsibly. In addition to implementing live webfont interpolation in your projects, you can get involved in the discussion, contribute to projects like opentype.js, and let type designers know there’s a demand for interpolatable fonts.

The Core Model: Designing Inside Out for Better Results

Posted by The fine folks at A List Apart |06 Jan 15 |

If you’ve worked on a website design with a large team or client, chances are good you’ve spent some time debating (arguing?) with each other about what the homepage should look like, or which department gets to be in the top-level navigation—perhaps forgetting that many of the site’s visitors might never even see the homepage if they land there via search.

Nobody comes to your website just to look at your homepage or navigate your information architecture. People come because they want to get something done.

All too often, we blame the client for falling short on user experience. They don’t get that the important thing is that the information architecture is easy to understand—something you will never achieve if every single department gets to have their own button on the homepage.

It’s about time we take more of that blame ourselves. Usually, no matter how much user research we do, or how meticulously we’ve treated the digital strategy, we start out in our interactions with clients by mapping the information architecture or sketching homepages. It’s no wonder clients believe these are the pillars of the entire website, if these are the first things we show them. In fact, very few users actually meet their goals right on the homepage of any given website, so it follows that very few organizations will reach their own objectives—much less their users’—by focusing only on the homepage.

Long before “mobile first” or “content-driven design” were even buzzwords, information architect Are Halland tried to solve this conundrum by introducing the core model, which he presented at IA Summit 2007. The presentation is still highly enjoyable and relevant, even seven years later. In short, websites must be designed from the inside out, with primary focus on the core tasks its users need to accomplish.

When we used the core model technique at Netlife Research to begin a mobile-first, content-driven website redesign with the Norwegian Cancer Society (NCS), we spent less time quibbling over the homepage contents, and more time trying to figure out how we could actually help the users and the NCS get what they needed out of the website—with great results.

The core model ensures that we’re thinking about user needs all the way through the website design process, thinking holistically about goals instead of hierarchically; instead of demanding “Where do you belong on the NCS website?” of our visitors, the core model prompts us to ask, more generously, “How can the NCS help you?”

A different starting point

Using the core model, we start the design process by mapping out all the content we have in order to find the pages with a clear overlap between objectives and user tasks.

To use the core model, you need:

  • Business objectives: Prioritized, measurable objectives and sub-objectives. What does the organization want to achieve?
  • User tasks: Actual, researched, prioritized user tasks. What is it that people want to get done? (We usually conduct top task surveys to identify the user tasks, which is a great tool if you want to align the organization.)

A good review of a website’s existing content can turn up some dusty corners that need clearing out. Typically, a website might have a lot of content that doesn’t help users meet their goals—such as press release archives and lengthy vision statements. A great deal of this content can usually be removed, simplified, or merged in some way.

When you have set aside the nonessential content, you are left with cores. These are pages or workflows whose content fulfills a clear overlap between business objectives and user tasks.

An example from the NCS is their page dedicated to information about lung cancer. Our user research identified a huge need for qualified and authoritative information on the many forms of cancer—and seeing that one of the objectives for the NCS is to educate Norwegians about cancer, this is a clear match of the users’ needs with the organization’s larger objective.

A Venn diagram showing the intersection of user needs and business goals.
Which pages meet both business goals and user needs?

But what happens with pages like “Donate”? Our research showed that users did not typically search the site for information related to fundraising, but being able to receive donations online is essential if the NCS is going to raise more money for cancer research. This is where the core model truly shines: if you create good cores, you’ll also be able to create good pathways to other, less-requested pages on your website, regardless of where they are placed in the information architecture. A core page should never be a blind alley.

Who is the core model for?

The core model is first and foremost a thinking tool. It helps the content strategist identify the most important pages on the site. It helps the UX designer identify which modules she needs on a page. It helps the graphic designer know which are the most important elements to emphasize in the design. It helps include clients or stakeholders who are less web-savvy in your project strategy. It helps the copywriters and editors leave silo thinking behind and create better content.

And to get all these different disciplines to start thinking collaboratively, we’ve found success with organizing team workshops that introduce core model thinking to the whole group.

By the end of the workshop, the group will have a common understanding of user needs, business goals, and how different pages should be connected. Additionally, you have worksheets where stakeholders have given you a prioritized list of what kind of content and modules they believe are the most important on the page they have worked on, when considering both user needs and business objectives.

With a prioritized list of what kind of content and modules needs to be on the most important pages, it’s a lot easier for the team to get to work, regardless of whether they are UX designers, graphic designers, or content strategists. We start by creating the core pages; the homepage is usually the last page we design. (How can you design the wrapping before you know what’s inside?)

How to do a core model workshop

The core model workshop outlined here is the first stage of a bigger design process, which might look a little different from one team to the next. But when you work with clients through these initial worksheets, the end result will be a team that’s excited to see the new website take shape—and is agreed on which content is truly important.

Doing a core workshop is easy and low-tech. All you need is:

  • Handouts summarizing researched user tasks and identified business objectives (see above)
  • Handouts with the core model (e.g. A3 paper size) (to fill out)
  • Markers and post-its
  • Room with a projector
  • 3-4 hours per workshop
  • 1-3 participants from your team (e.g. designers, UX, content, developers, and so forth)
  • 6-14 stakeholders from relevant fields or departments in the organization
  • Snacks and lots of coffee!
Core model handout with fields to fill out: core page name, business goals, user tasks, inward paths, core content, and forward path.
The core model handout.

When inviting stakeholders, try to involve people…

  • who will work with the content
  • with strong opinions about the website
  • who should be collaborating, but aren’t

To take part in a core workshop, there is no need for drawing skills, design skills, or tech-savviness. The most important thing is that people understand their own respective fields.

All workshop participants should work in pairs to fill out their worksheets. Between each step in the workshop, they’ll present their ideas to the other pairs, which will usually generate questions or new ideas that the other pairs can incorporate into their worksheets.

Core model workshop with participants discussing and working in pairs. Participants are labeled as socionom, lawyer, cancer nurse, research, design, cancer care, prevention, web editor, and fundraiser.
Participants from the NCS in one of the core workshops included people from the departments of cancer care, cancer prevention, cancer research, rights, and fundraising, as well as their in-house designer and web editor.

1. Identify your cores

The first thing you need to do is to identify your core pages by matching the business objectives and the user tasks. You can do this in the workshop or beforehand. Let’s use the example of our cancer type template, e.g. “lung cancer”, where we matched the following tasks and objectives.

Business objectives:

  • Helping patients and their friends and family
  • Increasing knowledge about cancer and prevention

User tasks:

  • Learn about different forms of cancer
  • Identify symptoms of cancer
  • Get tips for preventing cancer
  • Find information about treating cancer (therapies, adverse effects, risks, prognosis)
The core model handout, partially completed with core page name, business goals, and user tasks.
The worksheet has been filled out with the relevant business goals and user tasks.

2. Plan for inward paths

Instead of jumping in to content creation and detailing that page, the next step is to map out inward paths. This is where we’ll look carefully at any user research findings to help inform decisions. How might people find this page? How did they get here?

This approach is a simple way to prompt your client to think about the page from a user’s perspective. In our example of the page about lung cancer, plausible inward paths are things like:

  • Googling lung cancer
  • Googling symptoms
  • Clicking a link on the homepage
  • Finding a link in a printed brochure

3. Determine core content

After identifying inward paths, we begin talking about the core content. What content do we need on this page for it to achieve the goals of both the organization and the users? What kind of modules or elements do we need?

In this task, the participants are using all the information they have on their worksheets: the user tasks, the business objectives, and the inward paths. In light of this information, what are the most important things that need to go on to that page—and in what order? Having a solid user research foundation at hand will make this process much simpler. In the case of the NCS workshop, the user research had identified cancer prevention as a top user concern, which made it clear that we needed to say something about prevention—sometimes even for cancer types that cannot be prevented.

4. Set forward paths

This last field is key to the core model’s success. After visitors have gotten the answers to their questions, where do we want to send them next? At this point you can allow yourself to think more about business goals in a general sense.

In the case of the lung cancer page, it could be forward paths like:

  • Contacting the cancer help line (so they don’t diagnose themselves)
  • How to prevent all forms of cancer, not just this specific type of cancer
  • Patient rights, if they are reading about treatment
  • Telling users about the political work and lobby work NCS does (e.g. trying to reduce treatment waiting times)

This has to be done in the context of user tasks. If someone is visiting the website in a fearful state, hoping to find solid information about melanoma, do we really want to conclude their journey with a flashy “Donate!” message? Not really—that would just be rude and insensitive, and is unlikely to encourage donations anyway. However, many users do look for general information on cancer research, and in this context, we can frame it more specifically: “If you think cancer research is important, you can help us by donating.” (And in fact, this more considerate approach might end up increasing donations, as it did for us at the NCS.)

The core model handout with additional details filled in, including inward paths, core content, and forward paths.
A filled-out core worksheet.

5. Think mobile to prioritize

After all these steps, participants are usually getting excited and they’re full of ideas. Their worksheets are full of ideas for content, modules, and all sorts of functionality.

The enthusiasm is great—that’s something we want!—but a worksheet full of discursive ideas is difficult to work with. Are all these things equally important?

That is why the final step in the workshop is to use mobile-first thinking to prioritize all the elements. We give the participants a new sheet and ask them: if you had just a small screen available, in which order would you place the elements you’ve identified throughout the workshop? They’ll also need to place those forward paths they’ve written down in the context of the main content.

A modified version of the core model handout for mobile screens, with narrow columns replacing the large core content field and the forward path fields.
At the final step, participants get new worksheets with narrow columns representing a mobile screen. How would they prioritize their content on such a small screen?
A completed example of the core model handout, modified for thinking about content on mobile screens.
A finished mobile core worksheet from a workshop with the Norwegian Association of the Blind and Partially Sighted.

From core sketches to a finished website

We rarely use wireframes, and you won’t see a photoshop sketch or prototype with lorem ipsum. Why not?

A wireframe says a lot about where something is placed on a page, but it rarely says anything about why it was put there. Because of this, wireframes imply a lot more about what the design could look like than you really want it to in the early stages of design.

The core sketches from our workshop, on the other hand, can be put to good use by any web discipline, because it tells you which elements need to be on which pages, and—just as importantly—why they are there. There really isn’t any web-related discipline I know of whose members shouldn’t care about what needs to be on the page and why.

With interdisciplinary teams, you’re more likely to come up with more innovative ways of solving the user tasks: should it just be text? A video? A quiz? Something completely different?

At Netlife Research, we usually work in close teams of 2-4 people with a broad combination of skills, such as user research, UX design, graphic design, front end development, and content strategy. At this stage we’re also typically in close collaboration with a work group from the client.

Together, we are able to identify what kind of modules and information we need on the core pages—but the visual design is still flexible at this stage.

Three sketches of a page in mobile view: an early paper sketch, an early Photoshop sketch, and a simple black-and-white HTML and CSS prototype. All sketches used real content, not lorem ipsum.

The next step is to begin content workshops with the organization, using core model thinking and writing in pairs

Ultimately, we delivered an HTML and CSS prototype with actual content, which (in this case) a subcontractor then developed for the NCS, along with a custom CMS to manage the website and make changes. We also designed several modules tailor-made for common forward paths, which their website editors can place as needed on various pages.

One such forward path module is a box advertising the cancer helpline. This helps the NCS achieve its goal of increasing the use of its services for learning about cancer, and it helps users get answers to their questions.

Screenshot of a page about breast cancer, showing text about causes and prevention on the left, and the cancer helpline box on the right.
The cancer helpline box as used on the page about breast cancer. See our presentation from Confab Central 2014 for more details about this and other forward path modules.

Results

The message gets out to more people

After launch in September 2012, the number of unique visitors on the NCS website has steadily increased each year, despite the fact that the project had no specific activities aimed at search engine optimization. User-focused content goes a long way.

Since the launch of the redesign in September 2012, the number of unique visitors has doubled. Before launch, the number of unique visitors had been steady since 2010.
Unique visitors to the Norwegian Cancer Society’s website. Wondering about those dips in the graph each year? That’s the effect of the (nearly) endless Norwegian summer holidays.

As a welcome side effect of restructuring the website and the content around user tasks, the Norwegian Cancer Society is also now being used as a source by news media more frequently than before.

Forward paths have a huge impact

One example of a forward path is the aforementioned cancer helpline. If you compare the number of cancer helpline conversations in 2013 with the number of conversations the previous seven years, the number of conversations is up 40%. Usually, organizations will be looking to decrease the number of calls, but when you’re in the business of informing, it’s a good thing when users reach out. More people at risk of cancer picked up the phone, or entered a chat, or sent an email, and talked to an oncology nurse.

And despite this increase in conversations on the support lines, the oncology nurses tell us they are actually receiving more informed and sophisticated questions than they used to, because more people have already found the answers to their most basic questions on the website.

Since 2006, the number of cancer helpline conversations had been about the same, but in 2013, the year after launch, there was a 40% increase.
The total number of cancer helpline conversations, including email, chat, and phone calls.

Fewer banners, but more donations

The previous NCS homepage had several banners and menu items pointing to different ways of supporting the NCS. Today, there’s just the “Support us” item in the menu, and the banners are gone.

Despite this, the effect on the digital fundraising has been astounding. Comparing numbers from 2011 (a whole year with the old website) with 2013 (a whole year with the new website):

  • The number of one-time donations has tripled (up 198%)
  • The number of regular donors registering each year has quadrupled (up 288%)
  • The total sum from regular donors each year has quintupled(!) (up 382%)

This is not only due to core model thinking, but also continuous improvement of the forms.

This graph shows that the number of regular donors registered online is six times higher in 2014 than in 2011. There has been a steady increase since launch in 2012.
Thanks to continuous improvements, by August 2014 the annual income from regular donors registering online in 2014 had already surpassed the annual income from 2013.

People will do anything on mobile

For several years, we have advocated the idea that people will do anything on mobile, if you just let them. Our work with the NCS is great testament to this way of thinking.

Users spend roughly the same amount of time on the page about lung cancer regardless of which device they are using; while tablet and desktop users spend on average 3 minutes and 48 seconds, smartphone users spend 3 minutes and 57 seconds.

In some forms, conversion rates are actually higher on mobile; in a recent membership campaign, the conversion rate was 7.3% on mobile whilst only 2.5% on desktop.

Membership conversion rates are 2.5% on desktop, 6.5% on tablet, and 7.3% on mobile.
To become a member, we need the person’s name, address, and birthday. That didn’t stop people from signing up on a smartphone.

From homepage first to homepage last

By devoting your time to the core pages first, you’ll avoid a number of turf battles about menu bar real estate, and enjoy the benefits of getting the whole team united behind the same essential parts of the website. You’ll prove to the team that you care about their content and their users (and, sure, maybe convince them to care a little more about their users, too)—and the end result is a website that knows exactly what it’s about. Next time you’re faced with a compromise-riddled situation where you’re designing a website by committee, give the core model a shot. In my work, it’s been a great way to get down to business and stay on positive terms with the whole team.

From Empathy to Advocacy

Posted by The fine folks at A List Apart |06 Jan 15 |

For the past several years, I’ve been privileged to work with a number of local advocacy organizations in my community. Doing so has made me keenly aware of the crucial role that advocates play. They operate on scales both large and small—from working with lawmakers to shape public policy, to helping a single parent fill out the paperwork to find child care that enables them to keep a job. But advocates have a few things in common:

  • They have a cause: in whatever context they work, there’s an existing pattern they’re not satisfied with.
  • They intervene when they perceive an imbalance of power.
  • They act as translators between “outsiders” and “insiders.”
  • They persuade others to care about their cause, using stories and hard data.

As people who make websites, we may find that thinking of ourselves as advocates for our users, rather than creators of a product or providers of a service, transforms the way we work.

The UX industry devotes considerable attention to the concept of empathy, and rightly so, as understanding our users and their needs is foundational to delivering quality experiences. Still, empathy and insights alone do not automatically create those experiences. What matters is how cultivating empathy alters our decisions and behaviors. My ability to understand the needs of another person does nothing to meet those needs until I take conscious action—becoming not just a listener, but an advocate.

Most of us probably feel that we practice user-centered design, but the work of web development doesn’t happen in a vacuum. It frequently means inheriting a legacy of past decisions and considering a multitude of business pressures. It’s messy, and users often suffer as a result. Advocacy is what we do to make it better. It’s how we navigate the complex world of business relationships and persuade others to care about the same principles we do. And by making the language of advocacy a part of our daily conversation, we’re constantly seeking to build a culture of respect for users, rather than waiting for a project that provides a convenient framework.

Imbalances of power

Advocacy can take many forms, but one way to think of it is that when any significant power imbalance exists between two parties, the risk of an injustice occurring is high. The greater the difference, the greater the risk.

A person can feel powerless for many reasons. Being a child is an obvious example, as are differences in social or economic status. I can be privileged in one context and powerless in another. We all feel powerless whenever someone else makes decisions for us. When I go to the doctor, I’m signing up for whatever procedures are ordered, often without knowing what the cost will be. When I file my taxes, the government decides whether I’ve gotten them right.

In the face of a large, complex system, someone who feels powerless needs an advocate, usually one who works within the system, to gain a hearing. Otherwise, it’s too easy for the privileged party to make every decision based on its own interests and preferences, even if unintentionally.

That’s why governments and large organizations sometimes employ ombudsmen, who operate outside the normal chain of command and elevate complaints that might otherwise go ignored. Other advocates wear the hat informally, simply as people who care.

In developing web applications, I might be tempted to think that ultimate power always lies in the user’s hands. After all, I assume, she controls the browser and can always take her business elsewhere. But in many cases, this is more of an abstract idea than a true lever of influence.

Will she really leave the social network that all her friends use? And if she did, would I, as a developer, ever know the reason? There are many applications that people are forced to use without a good alternative, like those provided by an employer. In many cases, the business offering a website holds much of the power in its interactions with users.

Even when choices do exist, users are still not the ones making design decisions—they can only react to decisions already made by developers and others, and hope that someone is listening. Voting for change by leaving a website is unlikely to mean much because it’s a passive statement.

Experiences can also be hard to quantify. For example, when language barriers are creating a UX problem, it’s hard to measure the resulting frustration or its cost in goodwill.

In a culture of advocacy, the conversation starts from an underlying value of respect for the user, rather than the balance sheet or even an abstract idea like “best practices.” We can’t always say that adding translation, or making our writing more accessible, will improve our customer satisfaction metric by a given percentage. But we can say, “We ought to be an organization that recognizes the diversity of our customers and respects their time. Let’s demonstrate that by…”

The most effective advocate is likely one who has direct experience in the user’s shoes. The bilingual team member is most likely to be sensitive to language barriers. This isn’t always the case—anyone can champion a cause—but it does mean that as developers, we need to pay extra attention to the people within our organizations who have such experience. We can encourage them to act as advocates in those areas, and to remind us of priorities that we might otherwise overlook.

We must put structures in place to give such advocates the power to be heard, though. Ombudsmen hold positional authority that, while not absolute, isn’t easily overruled. In the design or development process, that structure may be formalized as a specific role within the development team (“Eve is our user advocate on this project”), or an expression of shared values that says, “If anyone feels that a decision doesn’t demonstrate respect for our users, we stop what we’re doing and tackle the issue.”

Translating between insiders and outsiders

An advocate also serves as a translator, helping outsiders to navigate a complex system and helping insiders to understand an outsider’s position. Doing this effectively can be challenging and involves a mix of both technical and soft skills.

In web development, interviews and testing will, of course, yield insights into users’ needs. But users can’t be expected to articulate those needs in a way that makes sense to developers. A good advocate will listen, draw inferences, and re-interpret needs in ways that lead to practical application at a technical level, so they can negotiate effectively with developers or other business stakeholders.

An advocate’s analytical skills, and a level of impartiality, can be just as crucial. Users may ask for the moon. They may describe symptoms instead of the fundamental problem, or jump to conclusions about what the problem is. For example, when a user complains that “the system is slow,” it might mean that response time is poor, or that the system is confusing and accomplishing a task takes too long. The user might feel strongly that the solution is adding a search system, when in reality, a few IA improvements would be effective.

An advocate’s role is to distill core problems from the raw input of feelings, reactions, and data, and, just as a lawyer might, recognize the moments when a user asks for what is not in their best interest. What people like is not always what’s most effective (although this is not an excuse to simply replace their subjective preferences with our own).

Collective interests and individual stories

“Users” are a faceless and voiceless mass. Alice and Bob, on the other hand, are people. An advocate’s third task is to make the impersonal personal by articulating the interests of a group and helping decision-makers to see them as people rather than numbers.

One of the most persuasive presentations I’ve ever attended came from a Boys & Girls Club spokesperson describing their work. It was persuasive because she did a masterful job of combining big-picture data about the effectiveness of certain programs with specific stories of children she’d worked with. It’s one thing to advocate for early childhood programs based on economic data; it’s quite another to show how a particular child’s life was changed through a development program. Collective data represented through individual stories become compelling.

It’s easy enough to write off the experience of a group of people when we describe them with a label—“IE7 users,” for example. It’s even easier when the label describes a minority of our audience. But if I think about my friend Alice, who works in a healthcare setting where computers are difficult to upgrade because of regulatory concerns, it’s much harder to explain why she deserves to be marginalized.

Stories are persuasive because they humanize the subject matter and help us connect emotionally. That’s what makes personas a valuable tool. But when we encounter resistance, they’re also easy to dismiss as anecdotal unless they’re supported by harder data. If I want to make the point that we shouldn’t ignore the experience of IE7 users, I need to know how many of those users I have. The developer who really doesn’t want to deal with IE7 might say that they’re “less than 5% of the audience”—a purely quantitative argument that sounds reasonable. But perhaps that 5% represents thousands of individual people. When I tell Alice’s story, explaining that she’s powerless to change the browser her employer provides, and point out that we have thousands more customers just like her, the argument carries more weight.

Advocacy in practice

Design decisions always require that we balance competing interests, but as a user advocate, I believe that it’s the user’s interest that should generally carry the most weight. Likely, not everyone in a business will agree, at least not all the time. To build credibility in speaking on behalf of users, consider the following practical guidelines.

Affirm the legitimacy of other interests

Rarely is a business openly hostile to users, of course. But we all bring to the discussion a set of preferences and biases that stem from our experience and expertise. Executives have an interest in the financial performance of the organization. Security professionals have an interest in protecting systems from intrusion. Developers want maintainable code and database integrity. Marketers want a strong brand image.

These are perfectly valid goals, but each of them can easily find itself in tension with what the users of a web application care about. Users probably value things like a good price, a clear interface, and software that lets them complete a task quickly.

An advocate exercises empathy not only on behalf of the user, but also on behalf of the business. To be heard, I need to first understand and respect what decision-makers value. Over the years, I’ve had many discussions with security professionals about the inherent tradeoffs in balancing usability with security—the most secure system is always the least usable. The UX person’s “clear feedback” in a failed login interaction is the security person’s “information leakage,” for example. To strike that balance well, I have to respect the need for security and the very real threats that face modern web applications. If ease of use were my only priority, I could easily put an application at risk.

Frame the discussion in meaningful terms

Respecting the goals of business stakeholders enables us to make a case for user-first decisions in ways that command attention. UX considerations can often be framed as risk management, brand management, or other business values.

For example, imagine that a website is offering a survey to users to get background research for a potential new product. The data will drive critical decisions, so everyone believes it’s a user-first project. But the survey takes over the user’s screen about 10 seconds after page load, so it’s frustrating. The conversation could easily go like this:

UX person: We’ve got to do something about this survey. It’s driving people crazy.
Research person: We really need the data. And people want to have a voice in our design process, right?
UX person: We could make it less intrusive, though. It doesn’t have to take over the whole screen.
Research person: Then they won’t notice it, and we won’t get enough data. We have to make it obvious.
UX person: Our users are annoyed.
Research person: It’s worth it for a little while. They’ll benefit in the long run.

A more effective approach might be:

UX person: Can I talk to you about the new survey? I’m really glad that kind of research is going into the new product.
Research person: Yeah, it’s exciting.
UX person: We’re hearing some complaints about the timing, and the way it takes over people’s screens. Could we adjust that? I’m afraid that frustration could really bias your data.
Research person: Oh, I hadn’t thought about that. We really need it to be obvious, though. If we don’t get enough people clicking through, the whole thing will be useless.
UX person: Definitely. Can I show you a couple of design ideas?

To someone who lives and breathes UX, user frustration might be a sufficient reason to make a design change on its own. But to the analyst who needs that survey data, it might seem like an acceptable tradeoff. Articulating the risk that frustration poses to the business, like biasing the results of a survey, can make the argument far more persuasive. And proposing a workable alternative is always more effective than simply highlighting a problem.

Be pragmatic

If we recognize that other business interests have merit, we have to be prepared to lose UX arguments at times. A business is not a person, and the cold logic of operational calculus may determine that the cost of making a change to improve UX outweighs the benefit. Advocates learn to choose their battles and press for change where it matters the most.

In the case of language barriers, as much as I may like to see full translation of a website or application, it’s likely an expensive proposition many businesses won’t be prepared to accept. But perhaps there are a few key interactions where it could be especially helpful, and we can advocate for a limited expense there. And if that doesn’t fly, we can fall back to simplifying the writing as much as possible to make it accessible to non-native speakers. At each step, even though the solution isn’t ideal, it keeps the issue visible, and keeps people thinking about the needs of that group of users.

While a business may be an impersonal entity, it is also composed of people who, for better or worse, share a common culture. As web professionals who continually speak in the language of advocacy, we can cultivate an environment in which users are respected, even when we lose out on individual decisions.

Find a cause and start somewhere

The advocates that I’ve worked with recognize their limits. They are passionate about a cause, but they know they can’t change the world all at once. They tackle manageable problems while always watching for new opportunities. Start by finding the single UX issue that you care most about, and look for small ways to improve it and persuade others to care. It could be one of the big issues of our day, like front-end performance or the mobile experience, or something very specific, like the experience of a handful of internal users with a particular administrative interface (which are easy to neglect—and improving them is a terrific way to get buy-in for future efforts).

At the same time, just as solving major social problems depends on public policy, our industry can only improve when we advocate publicly—so it’s important to write, speak, and share our experiences, particularly those that may be unique or underrepresented.

But whether the scale is large or small, the key is to encourage, in ourselves and in others, a healthy level of dissatisfaction with the status quo and take daily actions that directly improve the experience of our users.

From Empathy to Advocacy

Posted by The fine folks at A List Apart |06 Jan 15 |

For the past several years, I’ve been privileged to work with a number of local advocacy organizations in my community. Doing so has made me keenly aware of the crucial role that advocates play. They operate on scales both large and small—from working with lawmakers to shape public policy, to helping a single parent fill out the paperwork to find child care that enables them to keep a job. But advocates have a few things in common:

  • They have a cause: in whatever context they work, there’s an existing pattern they’re not satisfied with.
  • They intervene when they perceive an imbalance of power.
  • They act as translators between “outsiders” and “insiders.”
  • They persuade others to care about their cause, using stories and hard data.

As people who make websites, we may find that thinking of ourselves as advocates for our users, rather than creators of a product or providers of a service, transforms the way we work.

The UX industry devotes considerable attention to the concept of empathy, and rightly so, as understanding our users and their needs is foundational to delivering quality experiences. Still, empathy and insights alone do not automatically create those experiences. What matters is how cultivating empathy alters our decisions and behaviors. My ability to understand the needs of another person does nothing to meet those needs until I take conscious action—becoming not just a listener, but an advocate.

Most of us probably feel that we practice user-centered design, but the work of web development doesn’t happen in a vacuum. It frequently means inheriting a legacy of past decisions and considering a multitude of business pressures. It’s messy, and users often suffer as a result. Advocacy is what we do to make it better. It’s how we navigate the complex world of business relationships and persuade others to care about the same principles we do. And by making the language of advocacy a part of our daily conversation, we’re constantly seeking to build a culture of respect for users, rather than waiting for a project that provides a convenient framework.

Imbalances of power

Advocacy can take many forms, but one way to think of it is that when any significant power imbalance exists between two parties, the risk of an injustice occurring is high. The greater the difference, the greater the risk.

A person can feel powerless for many reasons. Being a child is an obvious example, as are differences in social or economic status. I can be privileged in one context and powerless in another. We all feel powerless whenever someone else makes decisions for us. When I go to the doctor, I’m signing up for whatever procedures are ordered, often without knowing what the cost will be. When I file my taxes, the government decides whether I’ve gotten them right.

In the face of a large, complex system, someone who feels powerless needs an advocate, usually one who works within the system, to gain a hearing. Otherwise, it’s too easy for the privileged party to make every decision based on its own interests and preferences, even if unintentionally.

That’s why governments and large organizations sometimes employ ombudsmen, who operate outside the normal chain of command and elevate complaints that might otherwise go ignored. Other advocates wear the hat informally, simply as people who care.

In developing web applications, I might be tempted to think that ultimate power always lies in the user’s hands. After all, I assume, she controls the browser and can always take her business elsewhere. But in many cases, this is more of an abstract idea than a true lever of influence.

Will she really leave the social network that all her friends use? And if she did, would I, as a developer, ever know the reason? There are many applications that people are forced to use without a good alternative, like those provided by an employer. In many cases, the business offering a website holds much of the power in its interactions with users.

Even when choices do exist, users are still not the ones making design decisions—they can only react to decisions already made by developers and others, and hope that someone is listening. Voting for change by leaving a website is unlikely to mean much because it’s a passive statement.

Experiences can also be hard to quantify. For example, when language barriers are creating a UX problem, it’s hard to measure the resulting frustration or its cost in goodwill.

In a culture of advocacy, the conversation starts from an underlying value of respect for the user, rather than the balance sheet or even an abstract idea like “best practices.” We can’t always say that adding translation, or making our writing more accessible, will improve our customer satisfaction metric by a given percentage. But we can say, “We ought to be an organization that recognizes the diversity of our customers and respects their time. Let’s demonstrate that by…”

The most effective advocate is likely one who has direct experience in the user’s shoes. The bilingual team member is most likely to be sensitive to language barriers. This isn’t always the case—anyone can champion a cause—but it does mean that as developers, we need to pay extra attention to the people within our organizations who have such experience. We can encourage them to act as advocates in those areas, and to remind us of priorities that we might otherwise overlook.

We must put structures in place to give such advocates the power to be heard, though. Ombudsmen hold positional authority that, while not absolute, isn’t easily overruled. In the design or development process, that structure may be formalized as a specific role within the development team (“Eve is our user advocate on this project”), or an expression of shared values that says, “If anyone feels that a decision doesn’t demonstrate respect for our users, we stop what we’re doing and tackle the issue.”

Translating between insiders and outsiders

An advocate also serves as a translator, helping outsiders to navigate a complex system and helping insiders to understand an outsider’s position. Doing this effectively can be challenging and involves a mix of both technical and soft skills.

In web development, interviews and testing will, of course, yield insights into users’ needs. But users can’t be expected to articulate those needs in a way that makes sense to developers. A good advocate will listen, draw inferences, and re-interpret needs in ways that lead to practical application at a technical level, so they can negotiate effectively with developers or other business stakeholders.

An advocate’s analytical skills, and a level of impartiality, can be just as crucial. Users may ask for the moon. They may describe symptoms instead of the fundamental problem, or jump to conclusions about what the problem is. For example, when a user complains that “the system is slow,” it might mean that response time is poor, or that the system is confusing and accomplishing a task takes too long. The user might feel strongly that the solution is adding a search system, when in reality, a few IA improvements would be effective.

An advocate’s role is to distill core problems from the raw input of feelings, reactions, and data, and, just as a lawyer might, recognize the moments when a user asks for what is not in their best interest. What people like is not always what’s most effective (although this is not an excuse to simply replace their subjective preferences with our own).

Collective interests and individual stories

“Users” are a faceless and voiceless mass. Alice and Bob, on the other hand, are people. An advocate’s third task is to make the impersonal personal by articulating the interests of a group and helping decision-makers to see them as people rather than numbers.

One of the most persuasive presentations I’ve ever attended came from a Boys & Girls Club spokesperson describing their work. It was persuasive because she did a masterful job of combining big-picture data about the effectiveness of certain programs with specific stories of children she’d worked with. It’s one thing to advocate for early childhood programs based on economic data; it’s quite another to show how a particular child’s life was changed through a development program. Collective data represented through individual stories become compelling.

It’s easy enough to write off the experience of a group of people when we describe them with a label—“IE7 users,” for example. It’s even easier when the label describes a minority of our audience. But if I think about my friend Alice, who works in a healthcare setting where computers are difficult to upgrade because of regulatory concerns, it’s much harder to explain why she deserves to be marginalized.

Stories are persuasive because they humanize the subject matter and help us connect emotionally. That’s what makes personas a valuable tool. But when we encounter resistance, they’re also easy to dismiss as anecdotal unless they’re supported by harder data. If I want to make the point that we shouldn’t ignore the experience of IE7 users, I need to know how many of those users I have. The developer who really doesn’t want to deal with IE7 might say that they’re “less than 5% of the audience”—a purely quantitative argument that sounds reasonable. But perhaps that 5% represents thousands of individual people. When I tell Alice’s story, explaining that she’s powerless to change the browser her employer provides, and point out that we have thousands more customers just like her, the argument carries more weight.

Advocacy in practice

Design decisions always require that we balance competing interests, but as a user advocate, I believe that it’s the user’s interest that should generally carry the most weight. Likely, not everyone in a business will agree, at least not all the time. To build credibility in speaking on behalf of users, consider the following practical guidelines.

Affirm the legitimacy of other interests

Rarely is a business openly hostile to users, of course. But we all bring to the discussion a set of preferences and biases that stem from our experience and expertise. Executives have an interest in the financial performance of the organization. Security professionals have an interest in protecting systems from intrusion. Developers want maintainable code and database integrity. Marketers want a strong brand image.

These are perfectly valid goals, but each of them can easily find itself in tension with what the users of a web application care about. Users probably value things like a good price, a clear interface, and software that lets them complete a task quickly.

An advocate exercises empathy not only on behalf of the user, but also on behalf of the business. To be heard, I need to first understand and respect what decision-makers value. Over the years, I’ve had many discussions with security professionals about the inherent tradeoffs in balancing usability with security—the most secure system is always the least usable. The UX person’s “clear feedback” in a failed login interaction is the security person’s “information leakage,” for example. To strike that balance well, I have to respect the need for security and the very real threats that face modern web applications. If ease of use were my only priority, I could easily put an application at risk.

Frame the discussion in meaningful terms

Respecting the goals of business stakeholders enables us to make a case for user-first decisions in ways that command attention. UX considerations can often be framed as risk management, brand management, or other business values.

For example, imagine that a website is offering a survey to users to get background research for a potential new product. The data will drive critical decisions, so everyone believes it’s a user-first project. But the survey takes over the user’s screen about 10 seconds after page load, so it’s frustrating. The conversation could easily go like this:

UX person: We’ve got to do something about this survey. It’s driving people crazy.
Research person: We really need the data. And people want to have a voice in our design process, right?
UX person: We could make it less intrusive, though. It doesn’t have to take over the whole screen.
Research person: Then they won’t notice it, and we won’t get enough data. We have to make it obvious.
UX person: Our users are annoyed.
Research person: It’s worth it for a little while. They’ll benefit in the long run.

A more effective approach might be:

UX person: Can I talk to you about the new survey? I’m really glad that kind of research is going into the new product.
Research person: Yeah, it’s exciting.
UX person: We’re hearing some complaints about the timing, and the way it takes over people’s screens. Could we adjust that? I’m afraid that frustration could really bias your data.
Research person: Oh, I hadn’t thought about that. We really need it to be obvious, though. If we don’t get enough people clicking through, the whole thing will be useless.
UX person: Definitely. Can I show you a couple of design ideas?

To someone who lives and breathes UX, user frustration might be a sufficient reason to make a design change on its own. But to the analyst who needs that survey data, it might seem like an acceptable tradeoff. Articulating the risk that frustration poses to the business, like biasing the results of a survey, can make the argument far more persuasive. And proposing a workable alternative is always more effective than simply highlighting a problem.

Be pragmatic

If we recognize that other business interests have merit, we have to be prepared to lose UX arguments at times. A business is not a person, and the cold logic of operational calculus may determine that the cost of making a change to improve UX outweighs the benefit. Advocates learn to choose their battles and press for change where it matters the most.

In the case of language barriers, as much as I may like to see full translation of a website or application, it’s likely an expensive proposition many businesses won’t be prepared to accept. But perhaps there are a few key interactions where it could be especially helpful, and we can advocate for a limited expense there. And if that doesn’t fly, we can fall back to simplifying the writing as much as possible to make it accessible to non-native speakers. At each step, even though the solution isn’t ideal, it keeps the issue visible, and keeps people thinking about the needs of that group of users.

While a business may be an impersonal entity, it is also composed of people who, for better or worse, share a common culture. As web professionals who continually speak in the language of advocacy, we can cultivate an environment in which users are respected, even when we lose out on individual decisions.

Find a cause and start somewhere

The advocates that I’ve worked with recognize their limits. They are passionate about a cause, but they know they can’t change the world all at once. They tackle manageable problems while always watching for new opportunities. Start by finding the single UX issue that you care most about, and look for small ways to improve it and persuade others to care. It could be one of the big issues of our day, like front-end performance or the mobile experience, or something very specific, like the experience of a handful of internal users with a particular administrative interface (which are easy to neglect—and improving them is a terrific way to get buy-in for future efforts).

At the same time, just as solving major social problems depends on public policy, our industry can only improve when we advocate publicly—so it’s important to write, speak, and share our experiences, particularly those that may be unique or underrepresented.

But whether the scale is large or small, the key is to encourage, in ourselves and in others, a healthy level of dissatisfaction with the status quo and take daily actions that directly improve the experience of our users.