BlogmyQuery – BMQ

A design contract is like a business card—it comes from the same desk, and bears the same creative mark. But it’s also the business card you hate handing out: a folder of legal gibberish with terrible formatting that reminds the client of everything that could possibly go wrong before the work has even started.

Is this just a necessary evil? Why can’t contracts evolve like everything else?

Actually, they can—and should. Modernizing your contract will not only make it match your carefully crafted brand, but it can also help you reach an agreement faster, and even strengthen your position when negotiating. This is not an easy task. Legal content is a delicate matter, and you definitely can’t start tweaking your contract like it’s a blog post.

Before we start modernizing contracts, we first have to understand their purpose, and how and why they got the way they are. It’s a long journey back.

Five Roman principles of contracts still valid today

The Romans developed a sophisticated system of commercial law that has become the foundation for pretty much all of the Western world’s legal systems. A design contract was probably signed to make the incredible decorations of Ara Pacis. Such a contract would have been created to accomplish something not that different from today’s products of design: defining what must be done, the deadline, the client’s approval, and the price. The concept of copyright did not exist yet, but unauthorized and fraudulent copies of literary works were socially unacceptable. (As for non-literary works, good luck copying those marble statues.)

While our work has evolved, contracts have essentially stayed the same—for a number of good reasons. In fact, several principles are just as important in today’s contracts as they were in Roman times.

1. Verba volant, scripta manent

Spoken words fly away, written words stay.

In a world where few people could read or write, a written contract was much more difficult to obtain—and therefore much more valuable than a handshake. Romans were the first to establish a now-universal principle of civil procedure: The burden of proof is on the plaintiff (onus probandi incumbit ei qui dicit). Therefore, a written contract protects the wronged party. This is still true today, so don’t only use a written contract before work begins; make sure every modification is documented in writing.

That’s a much easier task today than in Roman times. You don’t have to run to a scribe, or even a notary. E-mail has been proved legally binding multiple times, so to amend a contract, you can just drop a line like, “As discussed in today’s meeting, we mutually agree to modify the statement of work as follows…�

Some contracts even have a clause that requires all amendments to be in writing. If that’s the case, you’ll want to make certain you follow it; otherwise, the client can make excuses for not paying you for extra work.

AIGA’s standard agreement for design services uses a nifty solution to make sure all modifications are in writing and that there’s a limit to the number of modifications that can be requested:

As you can see, it’s the same old verba volant, scripta manent still in use.

2. Aliquid dare, aliquid retinere

Give something, keep something.

The value of a project depends not only on what you put in a contract, but also what you leave out. This is particularly true for design, which is not strictly a product, nor strictly a service. It’s a hybrid set of “deliverables,� and the contract (not the e-mail with the design attached) is the place where you give them to your client.

Be wary of what you give and keep. If possible, hold onto copyright: Delay the assignment, or the effective date of the license, until the money is in the bank. This is the best leverage you have.

Clients will try to do the same with payment, of course. Welcome to contract negotiation.

On this inevitable battlefield, details make a difference. For example, imagine you are an illustrator who creates a set of characters for a story. Your client picks the ones they like, and those are the deliverables they buy. Why shouldn’t you keep the rest, and “recycle� them for future projects? If you don’t specify this in the contract, the client will be assigned all the work in connection with the project, including unused sketches.

Same thing if you are delivering code. It’s common to incorporate snippets of code into multiple projects, but just because that code ends up in that project doesn’t mean that client owns it. These are usually called “design tools� in a contract—which means instead of giving something away, you’re simply giving your client permission to continue using the tools.

3. Leges sine moribus vanae

Laws are useless without customs.

Just as graphical and technical standards are essential to designing, standards and industry practices play a crucial role in negotiating contracts. Following best practices not only lowers transaction costs and streamlines the process, but also fosters more balanced deals.

What are the contractual standards of design? The AIGA agreement mentioned earlier is a great start, but standards can also live in single clauses. Eric Adler, a lawyer who works with creative professionals, knows which clauses of his contract are more likely to be negotiated, and takes care to explain those to his clients.

An excerpt from Eric Adler’s contract annnotations.

When it comes to liability, Adler suggests that it’s standard to cover your asse(t)s up to the overall net value of the project. You could try to ask for more, but no one wants to make a client nervous over a legal boilerplate, and standards make sure this doesn’t happen.

Standards don’t just come from lawyers or unions. Andy Clarke’s Contract Killer is extremely popular among freelance designers—in fact, a version of his contract is one of the most viewed and downloaded items at my company, Docracy, which provides an open collection of legal documents. This is likely due to Clarke’s strict no-legalese policy. He even dropped the classic impersonal language, transforming it into a natural dialogue with the client: “What both parties agree to do.�

The result is a set of informal yet clear rules that cover essential legal provisions, like assigning copyright only upon full payment and reserving portfolio rights.

But where is all the horrible small print?

There is none. This contract shows that it’s possible to enter a binding agreement using everyday English. Your lawyer may not like it, because he may fear not being taken seriously enough, or feel uneasy not following his standard. Fortunately, this is something that has actually changed since the Romans. They had to use formulae and magic words to make sure the contract would be upheld in court, while we typically enjoy shared language and literacy skills.

4. Clausulae insolitae indicunt suspicionem

Unusual clauses will raise flags.

We all like standards, but let’s face it: Everything is negotiable, and people will always try to sneak advantageous clauses into the contract. You need to make sure you don’t sign anything you’ll regret, and spotting bad provisions is not a lawyers-only job. Scanning contracts is a necessity sometimes, so always look closely at the following parts:

• Parties, particularly when companies are involved: Make sure the people you’re dealing with have the power to bind their companies.
• IP provisions: Who owns copyright and when, and what the licensing limitations are.
• Your representation and warranties—the fewer, the better: underpromise and overdeliver!
• Termination: What happens if someone wants to get out of the deal early?
• Dispute resolution: The clause no lawyer ever wants to give up. Watch this one, because you don’t want to let a client drag you to a court a thousand miles away. If you can agree to arbitration or mediation, even better.

The more contracts you read, the better you’ll get at spotting weird provisions. Trust your judgement: If something doesn’t seem quite right, it probably isn’t.

At minimum, you should ask for an explanation. This is never a waste of time. If you have a lawyer do this, just find someone who doesn’t bill by the hour, or this negotiation will take forever.

5. Pacta sunt servanda

A deal is a deal.

Both in Roman times and today, if you don’t deliver, it’s on you. Keeping promises is fundamental for a professional reputation. That’s why you have to be clear and consistent in the promises you make.

How do inconsistencies arise? One common way is having a statement of work (SOW) that’s not compatible with a master service agreement (MSA). This happens more often than you might think, particularly if no one has ever read that thirty-page agreement. If it’s not clear which one prevails (yes, you have to write it down), you can find yourself in a legal mess.

For example, capping your hours in the MSA is a great way to mitigate the fixed-fee or milestone-based pricing you agreed to in the SOW, but only if the cap prevails! Vice-versa, if you know you’ll only be looking at the SOW and all the special payment provisions are in there, then it should probably override any older pricing rule buried in that thirty pages of small print.

Even better, an MSA doesn’t really need to include thirty nasty pages of small print.

Making a modern contract

I bet you didn’t read iTunes’ latest Terms and Conditions before clicking “I Agree.� We try to read contracts when we think it’s important, but it’s not easy, for several reasons:

• Contracts are optimized for print, but today we read mostly on screen.
• They are often poorly formatted and typographically awful.
• Many elements are difficult to read, like definitions and ALL CAPS PARAGRAPHS.
• They’re full of legal jargon, not plain language.

The good news is, these problems can be fixed.

Typography

Let’s start with font. Designers and clients alike now mostly read on screens. Electronic signing is a reality, so there are few arguments for optimizing a contract for print.

If you’ve studied typography, you know how to use contrast, proximity, and alignment to create emotional and persuasive effects, and you can apply these same principles to legal text.

Matthew Butterick, author of Typography for Lawyers, has even developed a font optimized for legal text: Equity, a serif font that also looks good on screen—a nice compromise. Whatever you choose, ensure you give your contract balance and contrast.

Typesetting

Contracts are a very peculiar subset of legal documents. How can you use typesetting skills to improve their layout?

• Structure them in nested lists. HTML does such a great job handling nested lists and headings, so why use a crappy text editor? You often see reckless tabbing and manual line breaks made by frustrated people desperately trying to keep order. Using tools of the trade like Markdown, LaTeX, and Illustrator, you can do better in no time.
• Divide the boilerplate from the custom terms. Highlight relevant content like party names, important numbers, and percentages so they stand out from the boilerplates and can be easily skimmed.
• Make important clauses stand out, but never use all caps. The law only asks the drafter, in specific situations, to highlight certain provisions—and there are ways to do that without sacrificing readability. If your lawyer thinks differently, she’s wrong.
• Allow longer paragraphs. Words need to “breathe,â€� but contracts also need to cluster like clauses for readers. For this reason, line length is a delicate choice that depends both on the length of the clauses in your contract and on the font you choose to use. If you opt for a sans serif, you might get away with longer lines, but be sure to keep generous margins and line spacing (ideally, 120 to 145 percent of the point size, according to Typography for Lawyers).

You’ll also need to decide whether to justify or left-align text. The general rule is that justified text only works with proper hyphenation. This means you’ll have to manually input non-hyphenated breaks for the words you want to keep on the same line. Unless you’re drafting the contract yourself from start to finish, this is a daunting task. And, if your contract manages to have short paragraphs, ragged-right looks more natural, particularly on screen.

When we redesigned Docracy’s PDF typography, we opted for a longer line with lots of white space on the sides. This lets even the longest contract breathe, yet creates a compact final look:

Plain language

Now for the million-dollar question: Why are contracts written in legal jargon? Sadly, it’s because lawyers are too lazy and change-averse to rewrite their forms. The good news is, this is changing. And you can contribute; most formulaic “legalese,� like herein, thereof, or hereby, can just be replaced with “this.� You might even be able to remove entire lines, but better check with a lawyer to make sure.

Here’s an example of traditional contract language rewritten in plain English. Not only is the new version half the length, but it’s much easier to understand:

Classical roots, contemporary documents

There are many reasons the core rules of contracts are still in place two millennia after the fall of Rome. But there are other elements that we can, and should, take to the twenty-first century.

If we want to address the readability problems unique to our era—and improve communication with our clients—then it’s time we fix the language, layout, and typesetting of our contracts. And who better than designers to do it?

We talk a lot here at A List Apart about designing for the future. About being thoughtful, accessible, forward-thinking, and compassionate. About building a web that serves more of us, more fully.

And yet, when it comes to building our own communities—the events and conferences in which we learn new skills and discuss new ideas—we’ve spent precious little time designing with this inclusivity in mind. We accept conference lineups loaded with white men because “we couldn’t find any other qualified speakers,� or “all the women we asked said no.� We host bro-tastic hackathons fueled by beer-serving babes. Sometimes, we even give straight-up harassment and vitriol a place at the podium.

This isn’t good enough.

If the web’s ideal is universality, as Sir Tim Berners-Lee says, then shouldn’t this be the driving principle behind our own communities and organizations as well? If we want a web that works for everyone, then don’t we need a web profession that reflects just as much diversity? After all, the best way to understand the audiences we design for is to know those audiences. And the best way to know people is to have them, with all their differences of perspective and background—and, yes, age and gender and race and language, too—right alongside us.

“But I don’t want to exclude anyone,� you might be thinking. “I’m not trying to keep women or people of color or those from different backgrounds out of the spotlight.� I’m sure that’s true. Yet our community is far from diverse: According to the 2011 findings from our very own Survey for People Who Make Websites, just 18 percent of you are likely to be women, and even fewer of you are non-white. Add in the fact that women, people of color, and those from outside the U.S. are all much more likely to perceive bias in their careers, and it starts to get pretty hard to pretend everything’s OK. In fact, sexism at “geek� events is so prevalent, there’s a whole wiki devoted to cataloging known incidents.

However you participate in the web community—organizing conferences, holding hack nights, publishing articles, hosting meetups, or simply attending events—you have the power to do something about this, and in turn bring the web closer to its ideals. And it’s not as hard as you might think.

We have the tools

The web’s ability to connect people, facilitate understanding, and amplify ideas has enabled us to build incredible things. It’s also given us a wealth of lessons in how to design thriving, thoughtful communities. Lessons it’s time we turn toward ourselves—toward reaching this more personal, more intimate goal.

What can we learn from designing online communities, social systems like Flickr and Facebook? I propose four key skills: setting expectations, making it easy to report abuse, fostering diverse participation, and avoiding blaming our users.

Set expectations for behavior

Online communities are fertile ground for misunderstandings. Without the benefit of nonverbal cues like nods, smiles, motions, and postures, we misinterpret sarcasm. Our jokes fall flat. Our feelings get hurt. So what do we do when building these communities, besides writing up explicit terms of service? We set implicit expectations.

Implicit expectations include the voice and tone of an interface—from the signup forms to the welcome messages, the email reminders to the error notifications. Design, too: Typography, color, and layout choices all influence how a user sees an experience, and help her form an impression of not just what the site is, but how it feels, and how she’s expected to behave there. With every bit of content you communicate, you’re modeling the discourse you expect from others.

In addition to having explicit rules of conduct (and training your volunteers to enforce them), you can also create these types of implicit expectations in IRL. In fact, if you organize events, you already have models for behavior: the people who take the stage. Placed on a platform, both literally and figuratively, your speakers’ and organizers’ behavior and actions become your event’s norm. Their tone becomes your audience’s tone.

It’s your job to make sure it’s the right one.

If you’re in charge, talk with presenters, organizers, and volunteers about the expectations you want to set. Remind them that their actions are on display, and will reverberate across the event. Empower them to model the sorts of behavior you want to see, and be explicit about what’s inappropriate—like slides that objectify women or statements that marginalize non-U.S. attendees.

If you’ve picked the right speakers, this won’t impose on their creativity one bit.

Provide easy-to-navigate outlets to report abuse

Imagine a 14-year-old girl logging onto Facebook to find that she’s been called a slut and tagged in obscene photos by a classmate intent on ruining her reputation. She’s got enough on her plate without having to also wrangle with an interface that makes it hard to stop the harassment, right? So Facebook offers the option to delete any item posted to your page, right alongside the post—and to block a user and report abuse, just by visiting that user’s profile.

Now think about the last conference you attended. If you’d been harassed, would you have known where to go for help? Would you have had a clear outlet to voice concerns? Or would you have been @-messaging a generic conference avatar, unsure who was on the other end? Sidling up to a harried registration desk to discuss your grievances in public?

Would you have said anything at all?

I didn’t. A couple years back, I was propositioned by an employee of the company organizing the conference—a much-older man who was also a vendor for my then-employer. We’d had drinks with another colleague of mine, where we’d made mundane cocktail talk about business and spouses. We said goodnight, and approximately two seconds after he knew I’d be alone, he sent me a demanding, aggressive text message—one that assumed I’d already consented to a liaison. I was disgusted and furious, but unsure what to do: He was my main contact at his company, and knew the owner of mine well. The prospect of explaining all this over and over to people I wasn’t sure would understand seemed like a further humiliation waiting to happen.

So I let it go. And I spent months feeling ashamed of myself for it.

No event organizer wants attendees—especially those dropping hundreds or thousands of dollars on a conference pass—to feel this way. But if you’re in charge, you’ve got to do more than want. You’ve got to plan, and you’ve got to make it clear to the people attending that there’s an outlet for their concerns—before they have any.

Hearing about inappropriate behavior is difficult, sure. But no matter how awkward it is for you, I promise it’s much worse for the person who’s been made to feel uncomfortable or unsafe, who’s trying to hold it together while telling you, and who’s scared you’ll just write it off.

Don’t let that happen. If you organize events, name a person or provide a place—virtual or physical. Promise confidentiality. And publish this on your website or in your collateral, right from the start. You don’t need to make it scary—just include a simple note reminding attendees that everyone should feel welcome, and if they don’t, there’s a place to go and a person who’ll listen.

If you volunteer or speak at events, make a point to ask about policies for harassment or inappropriate behavior: Does the event have any? What are they? Raising the question may be all that’s needed to get an organizer thinking about these issues.

Whatever you do, don’t you make it a burden for someone to figure out how to tell you they’ve been harassed. If you do, many of them never will.

Foster diversity to foster longevity

Back in 2010, when Twitter first started suggesting people for users to follow, it made a rookie mistake: recommending the same people to everyone, all the time. This created a dynamic where “the rich got richer,� as Heather Champ, who’s known for her work building communities like Flickr, has noted. In other words, it made a few big names even bigger (Bieber, anyone?), but it failed to foster deeper connections or build robust communities. Over time, Twitter realized this wasn’t working and responded with major updates designed to give users more varied, relevant suggestions.

As we design community events, it’s important to ask the same thing: Are we just allowing the same people to keynote each year? Are we creating a divide between the haves and the have-nots—those with all the speaking experience, and those with none? If so, which people are we leaving behind? What value could they bring, what new connections could they build across our community, if we amplified their voices instead? What is our industry not learning, where is our industry stagnating, because we’re inviting the same cast to perform the same show each night?

Sameness is boring. It’s predictable. It’s stale.

Perhaps worst of all, it’ll only sell tickets or entertain audiences for so long. The best events feel fresh and different each time—they bring forth a variety of voices, tell a range of stories, and share a breadth of perspectives. They shift and adapt—just like the web.

As an attendee, you might argue that you want to see polished speakers and big names. There’s nothing wrong with that, and it’s normal to seek out lineups that have a few. But how many times have you looked at a speaker roster and thought, “man, that guy’s at everything�?

The best events avoid this sort of speaker fatigue by mixing in fresh faces and ideas—and that requires actively looking for new voices. If you’re recruiting talent, ask past speakers whom they’ve been reading recently. Trawl Twitter for interesting blog posts hashtagged to your field. Invite longtime attendees to submit a talk. Consider whether women might be declining your invitation to speak for reasons you hadn’t considered, and address those, too.

A star-studded speaker roster might generate buzz, but a diverse lineup adds texture, depth, and color. It adds richness and fullness. Done well, it makes people remember how your event changed the way they think and feel—not just which internet celebrity gave the keynote.

Don’t blame your users

Users aren’t perfect: They’re busy. They’re distracted. They’re human.

When we design for humans, we know we need to be forgiving. We know that when they need help, we can’t talk down to them. We know they deserve respect, understanding, and compassion.

Perhaps most of all, we know that when they fail, it’s our job to get better.

The same is true in person. Every time you make an excuse for a bad experience—“It was just for fun. I don’t know why you’re so offended,� or “We’re not trying to exclude anyone…you must be imagining things!�—you’re blaming your user. You’re making it his problem, not yours.

I’ve felt like this, too. Recently, I was accosted by a conference organizer at an official event happy hour. He had always come on a bit strong—too many cheek kisses, too much touching, too-tight hugs, too everything—but I’d always ignored it, figuring he wasn’t worth getting worked up about.

I was wrong. This time, when I questioned something he’d said in his talk that I considered divisive, things turned a very different direction. He screamed at me, in public, pointing his finger and advancing on me aggressively. I kept reiterating that I wasn’t sure why he was so upset, but the yelling continued for what felt like an eternity. I finally told him that the way he was talking to me was inappropriate, that I needed to be treated with respect, and that if he continued, I wouldn’t speak to him anymore.

I’d gone from someone he thought he could paw at to someone he thought he could scream at, and the combination left me shaken. I felt degraded. I felt humiliated.

But most of all, when trying to talk to people about what had happened, I felt marginalized. “He was probably drunk!� some folks said. “Oh, you just got him agitated! You know how he is,� I was told.

Whether or not I’d said something controversial doesn’t really matter. Disagreement and discussion aren’t the problem. His response was abusive and inappropriate, if not overtly sexist, and excusing his bad behavior made it my fault: If I’d just avoided him while he was drinking, just not asked a question, just not gotten him so “worked up,� then this wouldn’t have happened.

You know how condescending, blame-ridden error messages—like “FAILURE. FILL OUT ALL FIELDS CORRECTLY�—frustrate the hell out of users? It’s no different here. Blaming someone who’s been treated poorly is taking what’s already an alienating, isolating experience and deepening it. It’s making them feel incompetent and ashamed.

It’s like the lite version of telling someone she shouldn’t have been wearing a short skirt if she didn’t want to be groped. And it’s a problem you can fight, even if you’re just an attendee, by taking a stand against bad behavior—one that puts the blame squarely on the person who’s really responsible.

It’s up to us

I don’t pretend my experiences are tragic. I wasn’t terrorized or physically assaulted. My life goes on.

But my stories also aren’t unique. I could regale you with hours of anecdotes from friends and colleagues—mostly women, but not all—who’ve poured their time and love and attention into preparing presentations and articles, only to be humiliated or marginalized. People who’ve chosen not to talk about their piss-poor experiences for fear of being retaliated against. People who’ve stopped attending events or speaking up, because it’s just too damn hard to keep smiling while feeling left out, degraded, or attacked. Instead of outing others, though, I’ve told you my own stories. Stories I wish I didn’t have. Stories I wasn’t sure I’d ever share.

I’m sharing them now because I believe we have the power to improve things.

We already know how to make design choices that support inclusivity, set expectations for users, and model the interactions we want. There’s no excuse not to fix this—and, in fact, there’s a real danger in not trying.

We’ve spent two decades talking about a web that’s inclusive and flexible. We’ve devoted countless hours to creating spaces where conversations and relationships can thrive. The longer we tolerate a community that excludes others, the more we, as an industry, are defined by exclusion—and the further away we remain from the universality we’ve worked so hard to build.

As designers, we pride ourselves on being great communicators. We go to extreme lengths to communicate with users in a language they understand, enabling them to engage with our messages and feel like they’re part of a story we built just for them. Yet, we do a poor job of communicating with those whom our work requires us to talk to every day—and we need to, and can, get better at it.

In fact, as much as we consider ourselves designers, significant parts of our working hours are actually spent communicating with one another. At least, mine are. Here’s a list of tasks I perform on a typical workday:

• Log onto IRC (the way people at Canonical—the company behind the Linux operating system Ubuntu—communicate with anyone who’s on the clock) and greet my colleagues.
• Check my e-mail; reply to some, save some to deal with later.
• Log onto Basecamp; check my to-dos, update some notes, and comment on a hot thread.
• Make a quick phone call to my manager to get the daily update and clarify priorities.
• Log onto Onotate, a tool we use to provide feedback on designs and wireframes; read feedback I received on my designs and provide feedback on others’.
• Do a bit of designing based on feedback and planned tasks; upload them again for quick reviewing.
• Meet with my team via Google Hangout to discuss a particular ongoing project.
• Reply to the e-mails I left for later.
• Do some more designing.

Sound familiar? Whatever your specific situation, I’d bet much of your days are spent communicating with other people, too: talking, writing, being silent, smiling, frowning, asking, answering, listening, and, at worst, yelling.

Good communication skills are what allow us to sell our work, justify our decisions, and stand behind our positions. This (along with doing good work) is how we gain the trust and respect of colleagues, bosses, and clients—something every design professional aspires to. And it’s why all these little pieces of communication we constantly deliver are so important.

So what’s so hard about communication, and how can we get better at it?

Digital communication

We hate our inbox, but don’t know what we’d do without it. We have chats on Skype. We have back-and-forth conversations on Basecamp. But most of these communication channels don’t really satisfy us, make us feel better, or dissipate our concerns. On the contrary, they often seem to make us even more anxious about work. Why is that?

People need human contact and interaction to flourish.

Psychiatrist Edward Hallowell calls the interactions that makes us happier “human moments�—being in the physical presence of someone and having her emotional and intellectual attention—and argues that not having enough of them can lead to oversensitivity, self doubt, rudeness, and worry.

Why? Because digital communication makes us miss all the benefits that come from communicating to while being in someone’s physical presence:

This sounds incredibly familiar. All you need to do is think of Twitter.

Hallowell explains how the human moment increases the release of hormones that promote trust and bonding, which are at lower levels when you’re not in the presence of another person. These hormones make us less prone to worrying or overreacting.

Digital communication removes all the cues that mitigate worry. As more and more people work like I do, alone from home offices, without much face-to-face interaction, it’s important that we’re aware of this both in ourselves and others.

So what can we do about it?

One answer comes from 37signals, which hires great talent regardless of geography and encourages others to do the same. In their book Rework, founders Jason Fried and David Heinemeier Hansson report that meeting in person is important for remote teams.²

I work remotely from my home in Belfast, but I meet with the rest of my team in our main offices in London at least once a month. Then, not only do we have lots of meetings and face-to-face discussions, but we also make time to grab a cup of coffee, have lunch, and basically just interact casually—something that simply doesn’t happen when you have to type out everything you want to say.

Other teams within Canonical are fully distributed, and they tend to meet every few months for about a week at a time. This is usually when a project is getting started or nearing launch, because close interaction and immediate answers are so critical during these times.

The phone used to scare me, but since becoming a remote worker, I actually hope people will pick it up to ask me something instead of writing an e-mail. And even better than that are tools like Skype and Google Hangout. My team tries to have at least one “hangout� every week, sometimes every day of the week. Regardless of what you’re discussing, relating expressions, gestures, and a space to faceless e-mails or IRC messages will make a difference.

While many good things come with working from home, such as no commute and being able to truly focus on a task, moments of loneliness inevitably assault me every now and then. This makes it critical that both parties—the remote worker and the main office—try to make those at a distance feel like they’re part of something.

Even if you’re not working remotely, it’s very likely that someone you or your company works with is, or will be soon—which makes it crucial for healthy communication that you consider how to create bonds and develop trust without interacting every day.

Emotional creatures

Human beings desperately seek approval, dread condemnation, and thrive on appreciation and encouragement. Not you or I, of course—all the others.

One key point Carnegie makes is that people are prodigies at rationalizing their decisions and actions. From the most merciless criminals to devoted grandmothers, we all tell ourselves—and others—that it’s not our fault.

The problem, of course, is that as professionals we must be accountable for our own shortcomings—as Andy Rutledge makes clear in his book Design Professionalism:

But our irrationality isn’t all bad. Dan Ariely, a professor at Duke University who writes about behavioral economics, has noted several experiments that prove that humans will work harder when their efforts are acknowledged and their work is appreciated and meaningful than they will for financial gain alone.³

It’s normal for irrationality, emotions, and cravings to influence our behavior in the workplace. Understanding this is the first step to communicating with colleagues. When you see that someone feels discouraged, you can quickly offer a few positive words. When you need to make a point in a meeting, you can avoid remarks that would blame others—remarks that only make people uncomfortable and create animosity. If you do need to point out a mistake, you can choose to do so in private, and also communicate that you trust your colleague to do a better job next time.

Considering others’ feelings might not sound like your top priority, but it’s important to understand that the faintest insight into how we actually think, what motivates us, and what makes us disagreeable will only improve communications and, in turn, influence the responses and value we receive back.

A shared vocabulary

As designers, one trap we typically know how to avoid is assuming that a user understands our jargon. Yet we do this to everyone else around us: other team members, clients, and people in our company who aren’t designers. When these people don’t seem to care about what we’re doing, we write them off and say, “they don’t get it.�

It’s a lot easier to blame other people than to admit the obvious: We don’t really know how to get our point across in a language those different from us will understand.

Sometimes, we can even have a laugh about it.

A few months ago, my team was working on a project in conjunction with another, more developer-focused team within the company. Even though we had prepared several documents illustrating the project plan, which involved various research and discovery steps, we felt this other team didn’t completely grasp our role, as they’d occasionally send us things like “finished wireframes.�

My reaction was the same as most designers’ would be: I brushed it off as failing to understand the discipline of design.

I was wrong. A member of the other team eventually explained that when we showed them research plans filled with words like “IA card sort,” that meant nothing to them. If we wanted everyone’s buy-in, we had to do a better job at explaining our jargon, as Mike Monteiro explains in Design is a Job:

It’s funny because it’s true.

We want people to care about design as much as we do, but how can they if we speak to them in a foreign language? It’s important that, as we do with any user, we find a shared vocabulary and empower everyone else to become evangelists for our cause.

Once we took the time to actually define all of those funny words in our research and discovery phase, we turned the other team into advocates for design—people who, armed with a shared vocabulary, can and will spread the word of design within their own networks. In this case, that network was extremely important to us: other developers within the Ubuntu community whom we desperately wanted to engage with in our design process.

All this takes work, yes. But aren’t showing and communicating what design is all about?

Building a narrative

We like to create stories for our users—narratives that are engaging and compelling, that delight them and make them feel like they’re part of something. We want them to feel invested in us, our products, our sites. We want to bring them along on a journey we carefully curate.

We think, “If I were this person, what would I want to feel once I land on this site? What would I be thinking? What would make me stay?� We consider their point of view.

Then we step into a meeting and expect everyone to consider ours.

Instead of showing your work to your colleagues with a few mumbled words and a shrug and expecting them to get its sheer brilliance, it’s important to involve them from the start, making everyone feel invested and part of the solution. Map out the future you see in front of you, and make them walk the same journey.

My team is responsible for the design, build, and maintenance of Canonical’s main websites, but we also have some involvement with several other peripheral sites—for example, consulting on design or providing front-end development. Because we’re called the “Web Team,� we’re generally the first to hear about problems with any of these other websites, too—even though we don’t manage them.

Instead of quickly dismissing those complaints, I find it a lot more interesting to try to understand where they are coming from. Why do they think something is wrong? What would a better solution look like for them? Clarifying what our responsibilities are and explaining the obstacles my team is facing at that particular time (such as too few resources, impending release deadlines, or technical constraints) also improves the conversation.

Sharing a vision for where we want to be in a few months’ time and how they will benefit from it brings other teams along. And when everyone participates or at least understands the process, they’ll also better understand how and why you got there.

Final words

We know we need other people to do our jobs well. But we often say this—to ourselves and to everyone else—without taking the time to truly listen to, be inspired by, and understand the reasons behind others’ words or actions. We desperately want everyone to understand our motivations, to see that we’re upset and tell us something positive, to listen to us and marvel at our wisdom—yet we rarely bother to reciprocate.

We already have the right tools to communicate with one another effectively. We just need to put the same effort into communicating with colleagues as we put into communicating with users. When we truly understand our colleagues and respect their needs, we will build stronger, more trusting relationships within our teams and organizations—and better design because of it.

It’s easy to get frustrated by the pace of change in mobile. Companies drag their feet about actually delivering content and services optimized for mobile devices, commissioning yet more research to “prove� the need for a mobile strategy. Meanwhile, we tap away at our ever-more-capable smartphones and tablets, pinching and zooming our way through sites designed for a much larger screen.

Now we can find inspiration for taking quick action in mobile from an unexpected source: the government. President Obama has ordered executive branch federal agencies to make at least two key services available on mobile devices over the next year.

The initiative to optimize content for mobile is part of the larger Digital Government strategy aimed at building a twenty-first-century platform to better serve the American people. This strategy outlines a sweeping vision for how to deliver government services more efficiently and effectively, and it covers everything from how government agencies can share technology and resources more effectively to how to maintain the privacy and security of sensitive government data.

But running through the entire Digital Government strategy is a consistent thread: The government needs to communicate with and deliver services for its citizens on whatever devices they use to access the web.

If it’s true for the government, it’s probably true for your company, too. Your customers are using mobile devices to access your content—you need a strategy to communicate with them where they are.

The latest personal computing revolution

Imagine you don’t have a broadband internet connection at home. Your employer could see how many hours you waste looking up elementary school classmates on Facebook. Your ridiculous Google searches for things like “What is the probability of being killed by a Pop-Tart?� and “What does rhino milk taste like?� and “Ned Flanders shirtless or nude�—all visible to the eyes of prying co-workers as they walk past your desk. All your por… okay, let’s not go there.

Sure, we all indulge in embarrassing behavior on the internet, best left to the privacy of our own homes. But don’t forget about all the perfectly normal information we want to look up online—research we might not want our employers, coworkers, or strangers in a public computer lab to know about. Looking for a new job. Learning more about a medical condition. Checking a bank statement. Even shopping for Christmas presents.

If you’re like me, you’ve enjoyed the convenience of having a home internet connection for almost twenty years. It’s easy to lose sight of the fact that for many people, access to the internet is a luxury.

Thirty-five percent of Americans have no internet access at home. More than a third of Americans don’t have easy access to personal medical information, tools for financial planning, and animated GIFs of surprised cats.

Race, income, and education level all influence whether people will have a home broadband connection. Roughly 50 percent of both Black Americans and Hispanic Americans have no broadband connection at home. Nearly 60 percent of Americans making less than $30,000 per year don’t have a broadband connection at home. And Americans who don’t have a high school diploma? A whopping 88 percent of them lack a broadband connection at home.¹ The digital divide is real.

But as of early 2012, 88 percent of American adults reported they do have a mobile phone.² As of July, 55 percent of those Americans who own a mobile phone have a smartphone—and two thirds of people who had acquired a new phone in the previous three months chose to get a smartphone.³

As more and more people acquire smartphones, many of those who don’t currently have access to the internet will suddenly have it in the palm of their hands. A growing number of people who cannot afford to pay for both mobile phone and broadband internet access pick one device—the phone.

The mobile-mostly user

The stories about how mobile computing has changed human behavior often emphasize the developing world. Billions of people will only ever connect to the internet from a mobile phone. That development may seem positive and exciting, but remote. We assume that a “mobile-only� user is as foreign to us as a villager in Africa, in India, in China.

We’re wrong.

A large and growing minority of internet users in the U.S. are mobile only. As of June 2012, 31 percent of Americans who access the internet from a mobile device say that’s the way they always or mostly go online—they rarely or never use a desktop or laptop computer.⁴ Most tellingly, people who are less likely to have a broadband connection at home are more likely to rely solely or mostly on their mobile device for internet access:

• 51 percent of Black Americans
• 42 percent of Hispanic Americans
• 43 percent of Americans earning less than $30,000 per year
• 39 percent of Americans with a high school or lower education

Even some populations who do have access to a broadband connection and a full-size computer prefer to browse the internet on their phones. Do you want to communicate with people in the coveted 18–29 demographic? Good luck pulling them away from their smartphones. A whopping 45 percent say most of their internet browsing is on their phones.

By 2015, more Americans will access the internet through mobile devices than through desktop computers, according to a prediction by International Data Corporation. Some of these people may still have access to the desktop web, but, for reasons of context, ease, or sheer laziness, will choose their mobile first. For others, there will be no other way to view your content.

For this growing population, if your content doesn’t exist on the mobile screen, it doesn’t exist at all.

It’s never too early for content strategy

Will your organization be ready? Are you moving right now to develop a content strategy for mobile?

Or are you telling yourself that mobile is a blip, a grace note, a mere satellite to the larger desktop website? Do you think that offering a full set of content on mobile is a “nice-to-have,� something to think about only after investing in yet another redesign of the “real� website?

Delivering content on mobile isn’t an afterthought. It’s a requirement. It isn’t a luxury. It’s a necessity.

Think of any piece of information people may want to access on the internet. They will need to access it on a device that isn’t a desktop computer. Do people want to look it up? They’ll want to look it up on mobile. Do people need to search for it? They’ll want to search for it on mobile. Do people want to read it, deeply and fully? They’ll expect to read it on mobile. Do they need to fill it out, document it, and enter it into the system? They’ll need to do it on mobile.

This goes double for any organization that needs to reach people outside mainstream desktop users. Government agencies have a civic responsibility to deliver content to all citizens, which means providing it to them on mobile. Organizations seeking to deliver public health messages to the most at-risk populations won’t reach them—unless that content is available on mobile. Are you an equal-opportunity employer? Not unless you’re delivering your content where African American and Hispanic users can find it. You can’t assume all people in these groups will take the extra step to go find your desktop website.

You need to bring it to where they are. Which is mobile.

How to do it

The United States’ Digital Government strategy outlines a customer-centric approach to optimizing content for mobile. Your organization might not need to take a page from the government procurement handbook, but the roadmap for getting government information and services onto mobile might help you get your content out there, too.

A few highlights from the U.S. government’s approach that you should consider for your organization:

Manage structured content

Today, 57 percent of domains under development by American federal agencies are not being built with a CMS.⁵ As a result, managing and updating content is a cumbersome and difficult process. Content is locked up in static web pages (or worse, in printed documents), which makes it difficult or impossible to move content to a new platform.

The government encourages agencies to explore open-source CMS tools—and to model their content, turning unstructured pages into structured data with appropriate metadata attached.

Create presentation-independent content

Instead of focusing on the final delivery and presentation of the information—whether publishing web pages, mobile applications, or brochures—government agencies now are encouraged to take an “information-centric� approach. This means separating content from presentation, and instead describing the content more fully with a complete taxonomy and authoritative metadata, so the same content can be reused in a variety of contexts.

Treat content as a service

Making government content and data available through APIs increases the value of that data. When the government made GPS and weather data available to the public, it fueled multibillion-dollar industries.

By structuring their content and data, then treating it as a service that can be accessed via an API, the government can make content available to more people and more devices—while maintaining security and control over confidential information.

You can do it. Start now.

The U.S. government has recognized that their goal is not to publish brochures, handbooks, or binders. Their goal is not to publish web pages, either. Their goal isn’t even to publish apps. Their goal is to keep American citizens informed.

The government’s challenge and responsibility is making information available in whatever format American citizens want to consume it. We get to decide what device we want to use—the government can’t impose that on us.

The same is true for your organization. You already have customers who only access your content from their mobile device—and that number will only grow. If your web content isn’t fully optimized for mobile, you’re invisible to a large and growing subset of Americans.

It’s not too late, but the time to start is now. Develop a roadmap and put a strategy in place to start publishing your content on mobile devices.

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (http://bkaprt.com/csm/16; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for mobile.united.com. When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant (http://bkaprt.com/csm/27). Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (http://bkaprt.com/csm/28).

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (http://bkaprt.com/csm/29).

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” (http://bkaprt.com/csm/30). (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of CloudFour.com and MobilePortland.com, says:

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

• People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
• Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
• Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
• Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.