Archives

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.

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.

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.

Rian van der Merwe on A View from a Different Valley: How to Interview

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

It’s not like my life goal was to become an expert on interviewing. I’d much rather be an expert on work than on finding work. Like a corporate version of Frodo, in the midst of a grueling interview cycle I’d often lament that, “I wish it need not have happened in my time.” And then Business Gandalf would show up in my head to tell me, “So do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.” Ugh.

But I did what I had to do. I got good at interviewing. Now, I don’t plan to go anywhere anytime soon, so I have a chance to take a breath and reflect on what worked and what didn’t work when I was trying to change jobs. Here I’ll share some of the experience I picked up while interviewing for a variety of jobs as I moved across the world—twice—in a relatively short time.

Of course, this whole thing comes with an obvious disclaimer: This is what worked for me. It might not work for you, so proceed with caution. With that out of the way, let’s split the discussion up into two sections: how to get an interview, and how to get through it.

How to get an interview

One of the most common pieces of advice people give when they know you’re looking for a job is that you should never apply through a company’s website or respond to a general job ad. I’ve found this to be true—clicking the “Apply” button and pasting a text-only version of your résumé is a very effective way to get ignored. But what works, then? This is the process I used very effectively to get that all-important first email back:

  1. Find a job you’re interested in. That’s not really what this article is about, so I won’t go into too much detail except to list some of the usual suspects: use LinkedIn, go to the websites of companies you like and click on “Careers,” sign up for industry-specific job boards like BayCHI, etc.
  2. Find the two or three most likely hiring managers. This step is crucial. For example, if you’re applying for a design role, use LinkedIn or the company’s “About” page to find the VP of Product, or the Design Manager, or the Chief Product Officer, or any number of fairly senior roles that the job likely reports into.
  3. Use Rapportive to guess their email addresses. It’s usually not hard to figure out people’s corporate email addresses. the first thing to try is “firstname.lastname@”. There is only a finite number of combinations it could be. But the way to be sure is to install the Rapportive plugin, compose a new email in Gmail, and try a bunch of addresses (without sending the email) until Rapportive finds the person’s LinkedIn profile.
  4. Send an extremely short introduction email. Send separate, personal emails to each of the likely hiring managers you found. Make it really, really short. Don’t go on about how awesome you are—you’ll get a chance to do that later. Tell them you like their company, you like the role, you’re interested in talking. Link to stuff you’ve done: your LinkedIn profile, your portfolio, articles/books you’ve written, etc. Then ask them if they’d be willing to have a call, or forward your information on to the right person. The point is to not burden people. If they see a long email, the chances are high that they will delete it. But if they see a short email that’s respectful of their time and gives them the information they need to make a quick decision—that’s a different story.

You won’t get an email back every time, but of all the different ways I’ve tried, this method has had the most success. Your goal at this point isn’t to get the job, it’s to get that first email back. Once you get the email and the first call is set up, you move on to your next objective…

How to have a successful interview

Note that I didn’t title this section “How to get the job.” Remember that you might not want the job. Or, you might want the job but you shouldn’t take it because it’s all wrong for you. That’s what the interview process is all about. It’s not about looking good enough so someone will hire you. It’s about finding out if there’s a good fit between you and the company you’re interviewing with.

Your first call will usually be with a recruiter. The recruiter call is mostly a formality. As long as you’re able to condense your (obviously) illustrious career into a five-minute history lesson of past experiences, you should be fine. Recruiters get in trouble when they waste hiring managers’ time, so they’re just trying to avoid that. Your objective at this point is still not to get the job—it’s to get to talk to the hiring manager. And you do that by not sounding like an idiot when you talk to the recruiter.

The call with the hiring manager is a different story. I’ve approached this a bunch of different ways, but here’s the general approach that works best for me.

First, it’s important to look at the interview through the right lens. Don’t go into it with the primary goal of impressing the hiring manager. That is a waste of their time, and it makes you sound desperate. Instead, seek to have a mutually beneficial conversation with a fellow industry leader. You want to learn something from the conversation, and you want them to learn something as well. Your best outcome is if, at some point, the hiring manager says, “Huh, I’m going to read up on that a bit more when we’re done here.”

So how do you do this? You usually start with that five-minute history of your career. But then take the next step, and ask the first question… How do you do product development at your company? How do you prioritize roadmaps? What’s your design process like? By guiding the discussion and asking questions about how things work, you not only demonstrate what’s important to you, you also open a door to talk about the areas you’re most knowledgeable and passionate about.

Sure, you’re still going to get the odd, “Tell me about a time you’ve failed and how you dealt with that” question, but that will be few and far between. Most of the time what you’ll do instead is go over your allotted time and have a spirited conversation about the best ways to design and develop software. And that’s exactly what you want. You want to be seen as a peer right away—someone who would fit in.

That, to me, is a good interview. It’s not a venue for one person to test another person. Sometimes you can’t get away from that—you get bombarded with questions the minute the call starts. But that’s probably a good indication that it’s not a good place to work anyway. If the interviewer doesn’t bite, or insists on following a script that doesn’t really allow for conversation—it’s the first sign that you should probably walk away. If you can’t have a conversation as equals, you’ll never be treated as a valuable member of the team—you’ll always be a resource. And you don’t want that.

Which is to say…

If I could convince people of one thing that will make them more successful in interviews, it would be to change their framing of what an interview process actually is. Many of us grew up thinking an interview is a test that you need to pass. However, if you instead look at the interview process as a meeting of equals to understand if a good fit exists, you’ll not only be more confident and relaxed in the process, you’re also more likely to impress the company. And who knows, maybe they’ll even become better interviewers themselves.

This week’s sponsor: An Event Apart

Posted by The fine folks at A List Apart |26 Dec 14 |

Thanks to An Event Apart for sponsoring A List Apart this week. Register now for AEA Atlanta, February 16-18.