BlogmyQuery – BMQ

WordPress is one of the most deployed content management systems around. One of the main reasons is the number of plugins available and the ease with which we can use the system. It is not uncommon to find websites using tens of plugins to accomplish various tasks and functions. Wouldn’t it be nice if you could share the site content with other websites?

You may have a need to share advertisements, product information or your photo gallery if you are a designer. Whatever the reason, this article will show you how to create an embeddable content plugin to share your WordPress content with other websites.

Ways Of Sharing Content

There are various ways with which one can share content across websites — RSS and Atom feeds, APIs and embeddable widgets. RSS feeds on WordPress are usually restricted to posts, while APIs are not easy to integrate on other websites without adding some extra code. This leaves us with embeddable widgets — like the ones used by Google AdSense to display advertisements on websites or Facebook “Share” and “Like” buttons — all of these rely on embeddable JavaScript code to display specific content on a website. The idea mentioned in this article is certainly not new, but in the context of WordPress it opens up many possibilities. The advantages of the technique mentioned here compared with others is that it will enable you to share almost any content, even content from other plugins on your blog, with other websites.

Our goal in this article is to create widget code that a user could insert in their website to display a list of recent posts from the parent website. Of course, this can also be easily accomplished using RSS, but this is just an example to show the technique. In reality, you would use it for more interesting purposes, like sharing popular product images if you are running a WordPress e-commerce website.

The Widget Code

The embeddable code will look something like the following. This is the code the user will insert into their webpage, which will allow them to display the content from the parent website. The crucial element of this widget is the wp-widget.js file, which calls the remote WordPress website, gets the content and embeds it as an iframe in the calling page.

<script type="text/javascript">
  var widget_embed = 'posts';
</script>
<script src="http://www.example.com/widget/wp-widget.js"
type="text/javascript">
</script>
<div id="embed-widget-container"></div>

Adding this block of code to any website page will display the list of recent posts from example.com. The content can be anything besides posts — images, comments, tags, data from other plugins — anything you as a WordPress website owner would like to share with other people. For this example, I’ve limited the content to a simple posts list, as this is a common denominator across all WordPress websites and will be easy to start with. Of course, you will need to add some extra code to share other content, but the base plugin skeleton will remain the same.

Creating The Plugin

The fist step in creating an embeddable widget is to design a small WordPress plugin that will intercept the widget calls from another website and return the required data. You may be thinking that this will be a knotty job, but nothing could be easier. Just a few lines of code and our plugin is ready. The complete code for the plugin is shown below. I’ll explain how this works as we proceed along.

To get the content from the plugin, we will need to pass a query parameter of what content we would like from the remote server in the em_embed variable. This query parameter will then be intercepted by the plugin and the corresponding content returned. We will also pass along implicitly the domain URL of the calling page, so we can later use it for analytics purposes or for restricting the websites which can embed our widget.

For example, to get the list of recent posts, we need to send a GET query to the main WordPress website as shown below. Of course this query will be created by our JavaScript widget, wp-widget.js.

http://www.example.com/?em_embed=posts

The complete code for the plugin is given below.

<?php

/**
 * Plugin Name: WordPress Widget Embed
 * Description: Allow people to embed WordPress content in an iframe on other websites
 * Version: 1.0
 * Author: Sameer Borate
 * Author URI: http://www.codediesel.com
 */

class WPWidgetEmbed  
{
    public function __construct()
    {
        add_action('template_redirect', array($this, 'catch_widget_query'));
        add_action('init', array($this, 'widget_add_vars'));
    }
    
    /**
     * Adds our widget query variable to WordPress $vars
     */
    public function widget_add_vars() 
    { 
        global $wp; 
        $wp->add_query_var('em_embed'); 
        $wp->add_query_var('em_domain'); 
    }
    
    private function export_posts()
    {
        $outstring  = '<html>';
        $outstring .= '<head><style>';
        $outstring .= 'ul {
                padding:0;
                margin:0;
              }
              li {
                 list-style-type:none;
               }';
        $outstring .= '</style></head><body>';
         
        /* Here we get recent posts for the blog */
        $args = array(
            'numberposts' => 6,
            'offset' => 0,
            'category' => 0,
            'orderby' => 'post_date',
            'order' => 'DESC',
            'post_type' => 'post',
            'post_status' => 'publish',
            'suppress_filters' => true
        );
        
        $recent_posts = wp_get_recent_posts($args);
        
        $outstring .= '<div class="widget-posts"><ul>';
        foreach($recent_posts as $recent)
        {
            $outstring .= '<li><a target="_blank" href="' . get_permalink($recent["ID"]) . '">' . $recent["post_title"]. '</a></li>';
        }
        
        $outstring .= '</ul></div>';
        $outstring .= '</body></html>';
        
        return $outstring;
    }

    /**
     * Catches our query variable. If it's there, we'll stop the
     * rest of WordPress from loading and do our thing, whatever 
     * that may be. 
     */
    public function catch_widget_query()
    {
        /* If no 'embed' parameter found, return */
        if(!get_query_var('em_embed')) return;
        
        /* 'embed' variable is set, export any content you like */
        
        if(get_query_var('em_embed') == 'posts')
        { 
            $data_to_embed = $this->export_posts();
            echo $data_to_embed;
        }
        
        exit();
    }
}
 
$widget = new WPWidgetEmbed();

?>

To successfully intercept calls from another website, we need to first add the em_embed and em_domain parameters to our WordPress query_var variable. This will be used later to see what kind of data needs to be sent to the remote website. This is done by the following function.

public function widget_add_vars() 
{ 
    global $wp; 
    $wp->add_query_var('em_embed'); 
    $wp->add_query_var('em_domain');
}

Next, we will need to catch the query variable on the template_redirect hook and process any data if the em_embed variable is set in the global variable.

public function catch_widget_query()
{
    /* If no 'embed' parameter found, return */
    if(!get_query_var('em_embed')) return;
    
    /* 'embed' variable is set, export any content you like */
    
    if(get_query_var('em_embed') == 'posts')
    { 
        $data_to_embed = $this->export_posts();
        echo $data_to_embed;
    }
    
    exit();
}

In our example, we will be exporting a list of recent post titles, so our export_posts function will look like below.

private function export_posts()
{
    $outstring  = '<html>';
    $outstring .= '<head><style>';
    $outstring .= 'ul {
             padding-left:10px;
             margin:0;
          }
          
          li > a {
             text-decoration: none;
             font-family: Arial, Helvetica, Sans-serif;
             font-size:12px;
             
          }
           
          li {
             border-bottom: 1px solid #c0c0c0;
             padding: 3px 0 3px 0;
          }
    
          .widget-posts {
             width: 250px;
             border: 1px solid #c0c0c0;
             padding: 12px;
             margin-left: 3px;
          }';
    $outstring .= '</style></head><body>';
     
    /* Here we get recent posts for the blog */
    $args = array(
        'numberposts' => 6,
        'offset' => 0,
        'category' => 0,
        'orderby' => 'post_date',
        'order' => 'DESC',
        'post_type' => 'post',
        'post_status' => 'publish',
        'suppress_filters' => true
    );
    
    $recent_posts = wp_get_recent_posts($args);
    
    $outstring .= '<div id="widget-posts"><ul>';
    foreach($recent_posts as $recent)
    {
        $outstring .= '<li><a target="_blank" href="' . get_permalink($recent["ID"]) . '">' . $recent["post_title"]. '</a></li>';
    }
    
    $outstring .= '</ul></div>';
    $outstring .= '</body></html>';
    
    return $outstring;
}

This is all there is to the plugin. If you need to export any other data, you will need to replace the code for getting posts with code for getting the data you like.

Writing The Embeddable Widget Code

We have now completed only the part for the WordPress plugin. We still have to write the JavaScript embed code which will remotely access our website and insert the appropriate content into the calling page. The easiest way to display content from another website into your Web page is by using an iframe. The code needed to embed the content on a website is shown below.

<script type="text/javascript">
  var widget_embed = 'posts';
</script>
<script src="http://www.example.com/widget/wp-widget.js"
type="text/javascript">
</script>
<div id="embed-widget-container"></div>

If you are going to use the widget for returning only a single type of data,you can do away with the widget_embed variable. So you will have something like the following.

<script src="http://www.example.com/widget/wp-widget.js"
type="text/javascript">
</script>
<div id="embed-widget-container"></div>

wp-widget.js is the JavaScript that does all the work of calling the remote WordPress website and adding the content to the iframe. You need to place the wp-widget.js file in a subdirectory on your WordPress website; the exact name and location does not matter.

The complete code for the wp-widget.js is shown below, and is self-explanatory.

/**
  * wp-widget.js
  *
  * Inserts an iframe into the DOM and calls the remote embed plugin
  * via a get parameter:
  * e.g http://www.example.com/?embed=posts
  * This is intercepted by the remote 'WordPress Widget Embed' plugin
  *
  */

(function() {

// Localize jQuery variable
var jQuery;

/* Load jQuery if not present */
if (window.jQuery === undefined || window.jQuery.fn.jquery !== '1.7.2') 
{
    var script_tag = document.createElement('script');
    script_tag.setAttribute("type","text/javascript");
    script_tag.setAttribute("src",
        "http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js");
    if (script_tag.readyState) 
    {
      script_tag.onreadystatechange = function () 
      { // For old versions of IE
          if (this.readyState == 'complete' || this.readyState == 'loaded') 
          {
              scriptLoadHandler();
          }
      };
    } 
    else 
    {
      script_tag.onload = scriptLoadHandler;
    }
    
    (document.getElementsByTagName("head")[0] || document.documentElement).appendChild(script_tag);
} 
else 
{
    // The jQuery version on the window is the one we want to use
    jQuery = window.jQuery;
    main();
}


/* Called once jQuery has loaded */
function scriptLoadHandler() 
{
    jQuery = window.jQuery.noConflict(true);
    main(); 
}

/* Our Start function */
function main() 
{ 
    jQuery(document).ready(function($) 
    { 
        /* Get 'embed' parameter from the query */
        var widget = window.widget_embed;
        var domain = encodeURIComponent(window.document.location);
    
        /* Set 'height' and 'width' according to the content type */
        var iframeContent = '<iframe style="overflow-y: hidden;" \
                             height="550" width="400" frameborder="0" \
                             border="0" cellspacing="0" scrolling="no" \
                             src="http://www.example.com/?em_embed=' + widget + '&em_domain=' + domain + '"></iframe>';
                             
        $("#embed-widget-container").html(iframeContent);
    });
}

})();

The task of inserting the iframe and the WordPress content in the DOM is accomplished by the main() function. The iframe size needs to be changed depending on your requirements or created dynamically by letting the user pass additional parameters along with the widget_embed variable in the main widget code.

Adding Custom CSS To The Content

You can also add custom CSS to the displayed content through the plugin. Sample CSS to go with the above plugin is given below. You can also specify a style sheet URL if needed.

private function export_posts()
{
    $outstring  = '<html>';
    $outstring .= '<head><style>';
    $outstring .= 'ul {
             padding-left:10px;
             margin:0;
          }
          
          li > a {
             text-decoration: none;
             font-family: Arial, Helvetica, Sans-serif;
             font-size:12px;
          }
           
          li {
             border-bottom: 1px solid #c0c0c0;
             padding: 3px 0 3px 0;
          }
          
          .widget-posts {
             width: 250px;
             border: 1px solid #c0c0c0;
             padding: 12px;
             margin-left: 3px;
          }';
    $outstring .= '</style></head><body>';
    .
    .

The type of CSS you add to the content will depend on what content you are displaying. With a little creative coding, you can also allow the user to add certain display options to the widget with which they can control the display style of the embedded widget.

Restricting Display To Certain Domains

You may want to allow only certain domains to be able to display your content using the widget. This can easily be made possible, as we already have the calling website’s url in the em_domain variable. All we have to do is check the domain and selectively allow the content to be displayed.

public function catch_widget_query()
{
    /* If no 'embed' parameter found, return */
    if(!get_query_var('em_embed')) return;
    
    /* 'embed' variable is set, export any content you like */
    
    if(get_query_var('em_embed') == 'posts')
    { 
        $allowed_domains = array('site1.com',
                                 'site2.com',
                                 'site3.com');
                                 
        $calling_host = parse_url(get_query_var('em_domain'));
        
        /* Check if the calling domain is in the allowed domains list */
        if(in_array($calling_host['host'], $allowed_domains))
        {
            $data_to_embed = $this->export_posts();
            echo $data_to_embed;
        }
        else
        {
            echo "Domain not registered!";
        }
    }
    
    exit();
}

Performance Concerns

Allowing other websites to access your content via widgets means additional load on your servers. A few hundred websites using your widget could easily slow down your server, so take this factor into consideration when promoting widgets. However, plugins like WP Super Cache can be used to cache widget data and reduce server load. If you are not using WP Super Cache or any other cache plugin, you can try using the WordPress Transients API to save the results into the database.

The WordPress Transients API offers a simple and standardized way of storing cached data in the database temporarily by giving it a custom name and a time frame, after which it will expire and be deleted. The catch_widget_query() function after adding the WP Transient API code is shown below.

public function catch_widget_query()
{
    /* If no 'embed' parameter found, return */
    if(!get_query_var('em_embed')) return;
    
    /* 'embed' variable is set, export any content you like */
    
    if(get_query_var('em_embed') == 'posts')
    { 
        /* Here we are now using the 'WP Transient API'. 
           See if we have any saved data for the 'ewidget' key.
         */
        $cached = get_transient('ewidget');
        
        /* Oops!, the cache is empty */
        if(empty($cached))
        {
            /* Get some fresh data */
            $data_to_embed = $this->export_posts();
            
            /* Save it using the 'WP Transient API' using the 'ewidget' key,
               set it to expire after 12 hours.
             */
            set_transient('ewidget', $data_to_embed, 60 * 60 * 12);
            echo $data_to_embed;
        }
        /* Yes we found some, so we return that to the user */
        else
        {
            echo $cached;
        }
    }
    
    exit();
}

In Conclusion

Sharing your content across different websites is a nice way to market your services and create brand awareness. With millions of WordPress websites around, there is a huge amount of content out there that can be profitably shared among users. Not just text, but also images, videos, advertisements, etc. This article is just a simple implementation of an embeddable widget. You can customize it in various ways to include security, analytics code to track widget usage and other functionality.

(cp)

© Sameer Borate for Smashing Magazine, 2012.

What you tolerate defines your community.

—Heather Champ at Web Directions South 2012

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

The right tone of voice can turn someone’s confusion into trust, skepticism into optimism, boredom into curiosity. The wrong tone of voice can turn someone’s interest into annoyance, anticipation into disappointment, frustration into full-on anger.

—MailChimp’s Voice & Tone guide

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.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

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:

The human moment, then, is a regulator: when you take it away, people’s primitive instincts can get the better of them. Just as in the anonymity of an automobile, where stable people can behave like crazed maniacs, so too on a keyboard: courteous people can become rude and abrupt.¹

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

When dealing with people, remember you are not dealing with creatures of logic, but with creatures bristling with prejudice and motivated by pride and vanity.

—Dale Carnegie, How to Win Friends and Influence People

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:

Perhaps most importantly, professionalism means, in every situation, wilfully gathering responsibility rather than avoiding it.

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 your job as a designer, and a communication professional, to find the right language to communicate with your client. When you say a client doesn’t “get it� you might as well be saying, “I couldn’t figure out how to get my point across. I am a lazy designer. Please take all my clients from me.�

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.

People fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not communicated with each other.

—Martin Luther King, Jr.

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.

Footnotes

[1] From “The Human Moment at Work� by Edward M. Hallowell (Harvard Business Review, January 1999). The article is behind a paywall, but you can preview or purchase it.

[2] See more in Rework's (Crown Business, March 2010) chapter “Hiring� in the section “The best are everywhere.�

[3] In The Upside of Irrationality (Harper, June 2010), Ariely describes an experiment where three groups of participants were asked to solve as many sheets of word puzzles as they wanted, with decreasing compensation for each subsequent sheet. In the first group, participants wrote their name on each completed sheet before turning them in. Facilitators would give them an approving nod, and then place each sheet on a pile of others’ sheets. In the second group, the facilitator would place the sheet on the pile, minus the name and the nod. In the third group, facilitators would take and immediately shred each sheet—no nod, no name. Those in the first group completed many more sheets than the others for the same compensation; the only difference was that their work was acknowledged.

Translations:
Italian

RSS readers: Don't forget to join the discussion!

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.