Wednesday, July 30, 2014

Selling The Value Of The Web To Small-Town Clients

Selling your services as a freelancer or a small shop is tough enough as it is. Selling to a small-town business that might not even see the need for a website adds an extra level of difficulty in turning a profit.
I’ve provided web design services to small-town businesses for the past few years, having had many happy outcomes, but also a lot of negative experiences from which I’ve learned hard lessons. One of the most important things I’ve learned is how to sell the value of the web. Many of my clients needed to be convinced that a website would actually be good for their business. A lot of them were almost naive about the web and about the impact and reach that a professional website and online strategy would have for their small business, even one whose target market lies within a 15-kilometer radius.
My experience with selling to small-town clients comes from running my tiny web design shop, Hetzel Creative, for three years now in rural Iowa. I started from a blank canvas after having moved to this town and building a clientele that now includes over 80 small businesses, mostly in southwest Iowa. I’ve gotten to the point that most new businesses around here are referred to my company, on the strength of my successful track record and portfolio.
For the purpose of this article, let’s assume you live in a rural town like mine, with a population of about 5,000. You’re a great designer and developer, and the compelling idea of breaking out on your own drives you to look for your first client. You’ve landed a meeting with Ned’s Remodeling. Ned heard about you through mutual friends and is interested in a website for his small construction company.
After your initial meeting, in which you gathered information, you hit Ned with the numbers.
That much to build me a website?!” Ned is shocked. “Forget it! I have a nephew who could give it a shot for free.”
Now’s your chance to sell the value of the web.

A Website Is An Investment

Cash flow is often tight for small businesses, and you don’t have the luxury of dealing with department heads who aren’t closely tied to the money they’re spending. When a small-business owner writes a check, that money is very dear to them. So, Ned is obviously going to be put back when he hears a realistic estimate of what a properly designed and developed website should cost. Still, the only thing more important to him than his bank account (and his family, friends, etc.) is the future and growth of his company. The trick, then, is to sell Ned on a website’s return on investment.

Educating clients on the ROI a website can bring is a great first step to closing deals.
Educating clients on the potential return on investment of a website is a great first step to closing the deal. (Image credit: Philip Taylor)
Aside from the popular “Your business will be open 24/7” argument, you can sell Ned on a professionally designed and strategic website in many ways. Listed below are just a few, but you can easily get creative and tailor your responses to different clients, whose understanding of the web will probably vary.

Everything Is Trackable

With just a free Google Analytics account, you can track so many more metrics for a website than you can with print ads and other traditional advertising channels. This is a wonderful selling point, because it will reassure Ned that he can always look at the metrics and visualize whether his investment in the website is paying dividends. And if the results are not ideal, then those metrics will tell you what to tweak.

Your Image, The Way You Want It

A website serves as a central online destination for the whole brand. Ned needs to know that without a website (or with one that is poorly designed or that lacks compelling content), his online image will stretch as far as Google reviews or the Better Business Bureau. That might not give potential customers enough information for them to pick up the phone, especially if a competitor is dominating local search results for home remodeling and has a website that projects a compelling, trustworthy image.

Effective Advertising

The money spent on online advertising to drive prospective clients to a website is much more manageable and trackable than money spent on traditional advertising like newspaper ads, flyers and phone book listings. Online ads and listings, SEO and web content are in a unique category of advertising. Not getting as many hits as you would like? Adjust! Change your content and experiment. Not on the first page of Google for a particular term? Optimize! Rewrite some content and change some keywords.
Spend your advertising dollars to get your website into a high-traffic area that your target audience will see. Spending as much as, if not more than, an offline budget for online advertising is a no-brainer because you get so many metrics and insights on how an online campaign is performing. Ned wouldn’t have such control and accuracy with his advertising if he didn’t have a website, so this is a great point to sell him on the investment.

Productivity Enhancement

This is probably the last thing Ned expects from a website, but if properly thought out, a website can certainly enhance a small business’ overall productivity and free up time that is used for manual tasks. Take a simple contact form. More people are willing to submit a form online than to pick up the phone. It’s just easier and a lower barrier. Not only will Ned gain more leads, but now he has more time to research thoughtful answers than he would have had he gotten questions over the phone. And he can set aside a certain time of the day for written questions, which is better than being distracted by a phone call while drawing a blueprint or repairing a roof.

You Get What You Pay For

If you’ve convinced Ned that he needs a website for his business, then his most pressing concern will still be the wad of cash he’ll have to drop to pay for it. Even if he does view a website as an investment, investing in anything without some disposable income is still tough. At this point, he’s probably thinking of ways to spend the absolute least that he can, which is most easily done by pushing you to the backburner to find someone cheaper.

Educating your client on why they need a website and why you’re the right person to deliver it is all that’s standing between you and that money.
Educating your client on the importance of a website and why you’re the right person to deliver it is all that’s standing between you and the money they’re willing to spend. (Image credit: Tax Credits)
The key here is to make absolutely sure that Ned understands he will get what he pays for. You could remind him that he would advise his own potential clients not to trust just anyone to remodel their home; likewise, he should be willing to do the same for the online face of his business. Clients should trust experts to perform the services that they’re good at. Sure, he could get a free WordPress theme or use some cookie-cutter website-building service, but that’s like using duct tape and cardboard to fix a broken window. It might work, but you wouldn’t get the efficiency and beauty that a professional would provide.

Explain The Possibilities

Many people like Ned simply don’t know what they can achieve with a website: bill payments, sales, content management, newsletter registration, customer portal, email drip campaigns, subscriptions — the list goes on. If Ned is clear on what can be done, he’ll understand that an expert is needed to pull it all off.
Make sure, however, that you’re not just selling a list of features. You want him to see you as a partner who will share in the joy of the success that your services will bring. The features are only part of what a client wants. After all, thousands of freelancers can design and code as well as you can. Ned has to trust that the other guys don’t care as much about him and his success as you do.

The Importance Of Design

Even in a small town, where your reputation hangs almost solely on word of mouth, having a professional image is still critical. You understand this because you’re a designer, but Ned probably doesn’t. Without getting too deep into research on brand recognition, make sure you can back up your claim that good design is important to Ned’s small business. Here’s a great quote from a Razorfish’s report on branding that you can have ready (it’s five years old but still makes a great point):
According to our findings, 65% of consumers report that a digital brand experience has changed their opinion (either positively or negatively) about a brand or the products and services a brand offers… For those brand marketers still neglecting (or underestimating) digital, it’s as if they showed up to a cocktail party in sweatpants.

Break Out A Statistics Sheet

If Ned still needs convincing on why he needs you, show him some statistics. I’ve prepared a document for new clients that lists statistics on the number of Americans online, the number of people browsing on mobile devices (for selling a responsive solution), figures on how consumers are persuaded by a brand’s online image, and more.
Plenty of statistics are available for you to refer to in your sheet, like this one from a September 2013 report by BIA Kelsey:
94& of the consumers surveyed have gone online for local shopping purposes within the last six months. Among those surveyed, 59.5% have completed a local purchase of merchandise or services online, within the last six months.
Or this one, from a September 2013 survey by and Toluna:
83% of surveyed US consumers reported that having a website and using social media was a factor considered of high importance when choosing small businesses.
Or this one, from a June 2012 survey by 99designs (a great one to show Ned that others in his position think professional design is important):
80% of small business owners consider the design of their logos, websites, marketing materials and other branding tools either “very important” or “important” to the success of their companies.

Analyze Competitors

Another great way to convince Ned of the need for a website is simply to do a Google search right in front of him. If “glenwood iowa remodeling” brings up a list of all of his competitors, then he’ll see that he’s missing out. Even if you don’t offer SEO, Ned has to have a website in order to optimize it. If you do offer some SEO (or even include basic optimization in your service), then Google some of your current clients in front of him to show how you have helped companies get to the top of search results. Just don’t lead the client on if you don’t have the results to show for it — especially if they can so easily check how capable you really are.
Aside from search rankings, analyze some of Ned’s competitors’ in front of him. Point out what’s good and not so good about them. I always like to tell clients what I would do differently with their competitors’ websites because that helps them understand our expertise in a context they’re familiar with.

Bring Social Into The Mix

Several clients have come to me looking for the whole online package: website, Facebook page, Twitter account and branding, etc. Other clients had to be sold on these “extra” services. If you’re looking for extra angles to hook clients, offer a broad range of services, because — let’s face it — Facebook and Twitter are highly visible these days (Ned probably has a Facebook account already). The average client already has (or at least should have) an active Facebook page for interacting with customers and marketing to the public. So, offering a social strategy, or at the very least designing a nice profile and cover photo, is usually an easy sell.

Facebook for Business.
Facebook strategies and promotional designs are good services for clients who are looking for the full package. (Image: Sean MacEntee)
Beware of working with clients who solely want to use Facebook or Twitter, though. Many small businesses start with Facebook as their only online presence. While it’s a cheap way to get online, clients need to understand that their social pages should ultimately drive people to their “home”: their website.

How Did We Meet Ned In The First Place?

Contact with a prospective client can come from many different sources. The things that have always landed me contracts are word of mouth and a strong portfolio. Of course, I had to build my reputation for people to refer me, and that can be done in various ways.
The single most important thing that I did for my small business was to join the local Chamber of Commerce. I got leads simply from being listed on its website as a trusted local service provider, but the more important leads came from attending its events and talking to people. I never went to an event (coffee nights, banquets, golf outings, etc.) to land a contract that day. Rather, I went to become more acquainted with other business owners and to build their trust so that, when they did need a website, they would call me first.
Other ways to get your name out there include joining a committee (I was on the Chamber of Commerce’s marketing committee), attending events for entrepreneurs (who are your target market, after all), doing some pro bono work if you’re starting out, and giving current clients 10% off their next invoice if they refer you to someone. Just being around other business owners and making friendships in their circles should be enough to get you at least one contract; if you do a great job with them, the referrals will start coming in.
I’ve definitely tried things that don’t work, too. For instance, don’t waste your time on newspaper ads, cold calling, phone book listings or mass emails. You’re in the business of selling value, not just a service. Your best clients will arise from trusted relationships and from their belief in your ability to increase their bottom line.
Above all, make sure that your own website is killer. Experiment with different content until you’re at the top of search results for local web design and development. Of course, make sure to show off all of your latest and greatest projects. Case studies do a great job of selling (especially if the website visitor is in the same industry being profiled). Plenty of resources are out there to help with your online strategy, so don’t skimp on the quality of your website.

The Sky’s The Limit

Hopefully, this article serves as inspiration for those of you with the same target demographic. Keep in mind that working in a small town is not necessarily your best bet to raking in a ton of money and designing glamorous websites. But you’ll sleep well knowing that you’re benefiting the community by providing expert services. And keep your eye out for other markets to get into. With the number of fully distributed companies on the rise, you can do business with just about anyone from the comfort of your home.
Remember that selling to small-town businesses is a lot about education. Ned doesn’t know just how much value a website can provide. Educating him on the possibilities and the state of the web might just convince him to go with you, without your even having to explain “why me.”

Declarative Programming And The Web

Like most web developers, I spend my days giving instructions to computers. These instructions generally involve some input (a request for a web page), some logic (get the right content from a database) and some output (send the content to the requesting browser). This process of telling a computer how to perform a task, such as generating a web page, is what we commonly call “programming,” but it’s only a subset of programming: imperative programming.
There’s another type of programming, declarative programming, that most web developers also use every day but don’t often recognize as programming. With declarative programming, we tell a computer what, not how. We describe the result we want, and the details of how to accomplish it are left to the language interpreter. This subtle shift in approach to programming has broad effects on how we build software, especially how we build the future web.
So, let’s take a moment to investigate declarative programming and the web we can build with it.

Hidden In Plain Sight

Declarative languages tend to fade into the background of programming, in part because they’re closer to how we naturally interact with people. If you’re talking with a friend and you want a sandwich, you don’t typically give your friend step-by-step instructions on how to make the sandwich. If you did, it would feel like programming your friend. Instead, you’re far more likely to talk about the result you want, such as “Please make me a sandwich” (or, perhaps, “Sudo make me a sandwich”). If your friend is willing and able to follow this instruction, then they would translate the phrase “Make me a sandwich” into a series of steps, such as finding a loaf of bread, removing two slices, applying toppings, etc.
This type of result-focused instruction is how declarative programming works, by leaving the logic of how to implement requests to the system that is interpreting the language (for example, your friend). When we want an image in an HTML document, for example, we simply include an <img> tag, and then the system that interprets the HTML (typically, a browser) would handle all of the steps needed to display that image, such as fetching it from a server, determining where exactly to render it, decoding the binary data, scaling the image and rendering it to the screen. We don’t have to explain any of this, so we often forget that it’s all happening and that someone programmed both how it happens and how that complex process is derived from a simple <img>.
Another factor that makes declarative programming hard to see as programming on the web is that it “just works.” A lot of work went into making languages like HTML, CSS and SQL capable of providing enough clarity on what needs to be accomplished that the steps required to achieve a result can be determined without detailed instruction. But most web developers began using these declarative languages long after the hard work of building them was complete, so we just see them as normal and ordinary and just a natural part of the way the web works.
When web developers do get involved in declarative programming before the interesting work is done, it’s typically while developing an API for a website. Most APIs are implemented via declarative programming. Rather than provide a way to give a website step-by-step instructions, APIs usually have a simple language that can be used to express the desired result. When we want to get some tweets from Twitter’s API, for example, we give a description of the tweets we want, such as “everything from @A_single_bear.” If the API is imperative, we would instead describe the specific steps we want Twitter to implement on our behalf, explaining how to load, format and return the tweets. Thankfully, the API hides all of that logic behind a simple declarative language, so we only need to describe what we want, not how to get it.

Two Paths Forward

Once we realize how widespread declarative programming languages are on the web, it’s hard to imagine the web without them. Hard, but not impossible. As JavaScript has grown to be ubiquitous, the tools we would need for an imperative-only web are easy to find. We could swap out HTML and CSS for rendering directly in JavaScript. We could swap out SQL for a JavaScript-native database (or two). And we could swap out calls to declarative web APIs with imperative calls to JavaScript functions, even across the gap between client and server.
We could put all of this together and entirely stop using declarative languages on the web, even before we get into more advanced technologies heading in our direction, like asm.js. We can, now, build the web equivalent of mainframes: large, powerful systems built not as a collection of disparate parts but as a cohesive whole. We can now JavaScript all the things. We’ve tried this before, with technologies like Java and ActiveX. And some organizations, such as AOL, have even had success building a less messy web-like stack. The difference this time is that the technology available to build these “mainframes” is part of the open web stack, so that anyone can now make their own self-contained web-like stack.
An imperative-only JavaScript web is enticing if we understand the web as open technologies and connected documents. But if we expand our understanding of the web to include connected systems, then declarative programming is a key part of how we connect those systems. With that understanding, we should be heading in another direction. Rather building more complex systems by replacing declarative programming languages with imperative programming, we should be wrapping more and more of our imperative code in more and better declarative languages, so that we can build future complex systems on top of our current work. Rather than looking at JavaScript as the modern Java or C++, we should be treating it as the modern shell script, a powerful tool for connecting other tools.
By defining the implementation details in the language itself, declarative programming allows imperative languages such as JavaScript, PHP and Ruby to use the results as steps in more complex behaviors. This has the advantage of making a behavior available to a variety of languages, including languages that don’t exist yet, and it also gives us a solid foundation on which to build higher. While we could build our own document-rendering system in JavaScript or Python, we don’t need to because HTML has already solved that problem. And we can reuse that solution in any imperative language, freeing us to solve new, larger problems. JavaScript can draw an image on a canvas and place it into a document with HTML. Your friend can make you a sandwich and a fresh lemonade. But we’ll get to this future web only by valuing declarative programming as an approach worth maintaining, now that it’s no longer the only option.

Declarative First

When we start building a tool on the web, we often jump right into making it do what we want it to do. A declarative-first approach would instead start with defining a language to succinctly describe the results we want. Before we build a new JavaScript library for building sandwiches (or, of course, another), let’s consider how we might describe the results in a declarative programming language. One option would look something like {"bread": "rye", "cheese": "cheddar"}, while another would look more like <sandwich><cheddar /><rye /></sandwich>. There are many choices to make when designing a declarative language, from high-level format choices (JSON? XML? YAML?) to details of data structure (is cheese an attribute of a sandwich entity or an entity in the sandwich’s toppings list?). Making these decisions early could improve the organization of your later imperative implementation. And in the long run, the declarative language might prove to be more important than the amazing sandwich-making implementation, because a declarative language can be used far beyond an individual implementation.
We can see some of the advantages of a declarative-first approach in public projects that have taken both approaches. For example, three years ago the Sunlight Foundation started working on a project to make it easier for people to contact members of the US Congress. They began with a Ruby app to automate the submission of contact forms, Formageddon. This year, they launched a new declarative-first effort toward the same goal, the Contact Congress project, starting with a declarative language that describes contact forms.
The activity graphs and timelines of the two projects make it clear which approach won out, but the benefits of the declarative approach go beyond the direct results. The YAML files produced by the declarative approach can be used to build apps like Formageddon, but they can also be used for other purposes, ones not even intended by their creators. For example, you could build an app to analyze the descriptions of contact forms to see which topics members of Congress expect to hear about from their constituents.
Successful declarative programming is in some ways more challenging than imperative programming. It requires clear descriptions, but also requires knowing enough about imperative implementation to know what needs describing. You can’t just tell an app where a form is and expect a valid submission, nor can you say <greatwebsite> to a browser and get what you want. But if you’re up for the challenge, the rewards of a declarative-first approach are also greater. Declarative languages often outlive their imperative implementations.
Try starting your next web project with declarative programming. See what languages you can find that already describe what you’re making, and write your own simple languages when you can’t find anything. Once you have a declarative definition of what you want to make, build it with an interpreter of those languages. You’ll probably end up making something more useful than you would have with an imperative-first approach to the same problem, and you’ll improve your imperative approach in the process.

Monday, July 7, 2014

Server-Side Device Detection With JavaScript

There are many strategies to choose from when developing a modern, device independent website nowadays. How should capabilities of the device or browser be determined? Should the presentation logic be server side or client side? Traditionally, mobile optimization had to happen server side.
Over the last couple of years, Responsive Web Design and tools like Modernizr have become very popular. Recently, combination techniques (often called RESS), where optimization is done both server-side and client-side, has become a trend. The recently launched WURFL.js tool, fits into this category.
In this article, we will look at some basic use cases of how to use WURFL.js to optimize the user experience both in HTML and CSS, and an example of how to choose the right ads to display on different devices. We will also see how WURFL.js is different from, but complements, the popular feature-detection library Modernizr.

Once Upon A Time, Device Detection

Whether we are using regular expressions in JavaScript, Modernizr or a complete device-description repository (DDR) for server-side detection, the purpose is usually the same: to give users a better experience. This typically happens at two levels:
  • presentation of content and interaction with the service,
  • analysis of user behavior to determine usage patterns.
The challenge is to do this in ways that are both scalable, maintainable and, as much as possible, easy to implement. For some projects, the cost and complexity of deploying third-party tools on servers is too high. Yet a low-maintenance solution that lets a website look good and perform well is possible, despite the constant diversification of devices. This is where WURFL.js plays a role, by providing a scalable alternative to traditional server-side device detection, all the while complementing other client-side techniques and tools.
Before diving in, let’s look at the basics.

Copy, Paste, Done

No registration is required, and WURFL.js can be used at no charge. So, the first thing to do is copy and paste this line of HTML into your page:
<script type='text/javascript' src=“//"></script>
Both HTTP and HTTPS are supported. If you plan to use the device information provided by the script to make rendering decisions, then you might want to include the script in the <head> element. Otherwise, you can load it asynchronously.
Now that the script is in your HTML page, you can access the WURFL object in JavaScript. The WURFL object looks like this and is ready to use:
  complete_device_name:"Apple iPhone 5",
The object has three properties:
  • complete_device_name
    This is the name by which the device is known — typically, the make and model or a category of devices or a more generic definition.
  • form_factor
    • desktop
    • app
    • tablet
    • smartphone
    • feature phone
    • smart TV
    • robot
    • other non-mobile
    • other mobile
  • is_mobile
    This is true or falsetrue if the device is a tablet or other mobile device.
Of course, you can immediately do things like this:
Or this:

Under The Hood

Because WURFL.js detects the device based on the User-Agent string and other information provided in the HTTP header, the contents of the JavaScript file will depend on the device. So, you can’t just copy the contents of the file and put it inline in the HTML or combine it with another JavaScript resource.
To understand this in detail, let’s look at the illustration above. The browser makes a request for (1). The markup returned by the Web server (2) contains the <script> reference to WURFL.js. Next, the browser renders the HTML and starts fetching assets — among them, (3). When the request reaches, the HTTP request is analyzed by WURFL. Usually, based on that request, there will be an instant hit, and the device is identified without further ado, and a single WURFL JavaScript object is returned. However, in certain cases when the device cannot be identified on the server side alone (notably, in the case of iOS devices), the JavaScript file will contain a few more checks to determine the device. The browser then evaluates the JavaScript, and the WURFL object is ready to use (4).
WURFL.js is capable of, for example, distinguishing between an iPhone 5 and an iPhone 5S, thanks to this extra client-side logic. This is a big deal because this use case is supported neither by sheer User-Agent analysis nor by Modernizr tests.

A Note On Performance

If you use WURFL.js to make rendering decisions or, for some reason, you need to place the <script> tag inside <head> (without deferring it), then the browser will wait for the script to be downloaded and evaluated before rendering the page. Depending on the use case, this might be the only way; but, for the record, WURFL.js can also be loaded asynchronously to increase rendering performance.
The size of the returned JSON object will be fairly small, varying from 0.5 to 3 or 4 KB, depending on the device. Compared to Modernizr (about 14 KB) and jQuery (96 KB), WURFL.js is arguably light.

Use Cases

Assuming that you have WURFL.js up and running, let’s look at some cases in which using WURFL.js makes the most sense, either by itself or in conjunction with Modernizr and/or other solutions. To illustrate, we’ll refer to the website itself, which utilizes WURFL.js in multiple ways.

Optimizing the User Experience

When it comes to mobile, responsive and adaptive design and all that, the most common thing to do on a website is improve the user experience for certain device families or form factors. Much can be handled by media queries, of course, but sometimes you need the help of some JavaScript.
When you visit on your laptop, the top section of the page has a video background, some simple parallax scrolling and text that changes dynamically according to the device or browser. It looks very cool on a laptop, but video backgrounds, not to mention parallax scrolling, would not be ideal on a tablet or smartphone, to put it mildly.
We could use Modernizr, of course, or decide whether to implement these features in other ways. But in many cases, knowing the physical device is just as important as — perhaps more important than — knowing whether the browser claims support for a feature. We might encounter a problem whereby the browser claims support, but the support is actually not good enough to make a great user experience.
To avoid these situations, you would use WURFL.js and Modernizer together. Note also that comparing WURFL.js and Modernizr directly is not quite fair. Modernizr detects features claimed by the browser, whereas WURFL.js categorizes the device in different ways. So, if you don’t know whether a particular device or form factor supports a certain browser-detectable feature, then you are better off with Modernizr or a full-fledged device-detection solution.
However, in this example, we’ll rely on WURFL.js and demand that only non-mobile clients get the video background and parallax scrolling:
/*video background*/

/*The parallax scrolling*/
window.onscroll = function () {
  if (!WURFL.is_mobile){[prefixedTransform] = "translate3d(0px," + window.scrollY / 2.3 + "px, 0px)";[prefixedTransform] = "translate3d(0px," + window.scrollY / 1.1 + "px, 0px)";["opacity"] = (1 - ((window.scrollY / 6) / 100));
The example above simply checks whether the device is mobile (a phone or tablet) and introduces features accordingly. Of course, we could also leverage the more fine-grained WURFL.form_factor.

Put More In CSS?

The examples above show how to make use of the device’s data in JavaScript. However, we can make the device’s information available in CSS, too. We can assign different styles depending on the device, form factor and whether it is mobile. The first technique we will look at is similar to how Modernizr works. Modernizr adds a certain class to the HTML document depending on whether its test returns true or false.
Let’s say you want some specific behavior defined in the CSS for mobile devices. You would need to add the following JavaScript snippet to your page:
document.documentElement.className += ' ' + (WURFL.is_mobile ? '' : 'no-') + "mobile";
This will add a class to the html element. For mobile devices, it would say <html class=”is_mobile”>; for other devices, it would say <html class=”no-is_mobile”>.
If you know Modernizr, then you are probably familiar with this approach. Your CSS might take the following form:
.mobile #menu a{
  padding .5em;

.no-mobile #menu a{
  padding .1em;
In this simple example, we’ve increased the padding on menu items so that they are easy to tap with a fat thumb.
This method can be used for all of WURFL.js’ capabilities. However, because complete_device_name and form_factor are not boolean values (like is_mobile), the CSS part can become quite a headache. A bit more flexibility might come in handy, then. Here is an example using data- attributes:
document.documentElement.setAttribute('data-device_name', WURFL.complete_device_name);
document.documentElement.setAttribute('data-form_factor', WURFL.form_factor );
This will put data attributes with WURFL capabilities in the html element. We get several cool features with this method: We can target specific devices, form factors and even groups of devices combined with form factors by using CSS selectors:
html[data-form_factor = 'Smartphone'] #menu a{
  background: green;
Thanks to the wildcard attribute selector *, we can even match strings:
html[data-device_name*='Nokia'] [data-form_factor = 'Feature Phone'] {
  background: yellow;
The CSS above will match Nokia feature phones of any model. It also illustrates what the DOM looks like with the two methods implemented — in this case, with an iPhone 5S.

Help With Banner Ads

Many different ad networks are out there, each with its own specialization. Some are good for mobile, others for desktop. Some support text ads, other have ads of fixed size. If you are beyond a beginner’s level in ad networks, then you might want to assume some control over this. WURFL.js can help you make your own decisions or influence the network to make the right decisions for you.
The obvious approach is to ask WURFL.is_mobile to choose networks or ads that are good for mobile and others that are good for non-mobile.
Moreover, from a design perspective, being able to fit the sizes and proportions of ads to your breakpoints and to design for different form factors of ads is nice. In the extreme, you could do something like this:
  case "Smartphone":
    if(WURFL.complete_device_name.indexOf("Apple") !=-1){
  case "Tablet":
  case "Feature Phone":


If you’ve tackled the diversity of devices in the past, then you’ll know that many developers have been looking for JavaScript tricks to detect browsers, devices and their respective features. Traditionally, a DDR required server-side libraries and data to be installed and for the device-description repository to be updated. WURFL.js is a freely available option to manage these issues.
You might want to consider WURFL.js or similar libraries for analytics, optimization of the user experience or advertising, and the library can complement Modernizr nicely. While Modernizr detects support for certain features of the browser, WURFL.js provides information about the user’s physical device.
WURFL.js is a bridge between the server side and the client side, making it easier for front-end Web developers to take advantage of functionality that used to belong on the server. It can also be used for current websites that have been designed responsively or that enhance progressively.

Sunday, July 6, 2014

Facing Your Fears: Approaching People For Research

When working on a project, have you ever felt that you and the rest of the team were making a lot of decisions based on assumptions? Having to make choices with limited information is not unusual — especially in complex projects or with brand new products.
Phrases like “We think people will use this feature because of X” or “We believe user group Y will switch to this product” become part of the early deliberation on what to develop and how to prioritize. At some point, though, these phrases start to feel like pure guesses and the ground under your feet feels shaky. What can you do about it?
Regardless of your role in the project, one activity in particular will help your whole team build a solid foundation for product strategy and design: that is, approaching potential users for research, such as interviews and usability tests.
Such research is an important aspect of user-centered design. It helps you build products that are rooted in a deep understanding of the target audience. Among other benefits, interviewing potential users helps you achieve the following:
  • more precisely define who the target audience is (and isn’t),
  • face and challenge your assumptions,
  • uncover unmet needs,
  • discover the behaviors and attitudes of potential users firsthand.
You can conduct informal yet valuable user research yourself with practice and with guidance from great sources like Steve Portigal’s Interviewing Users and Steve Krug’s Rocket Surgery Made Easy. One thing that stops a lot of people from trying their hand at research isn’t just lack of experience, but a fear of approaching people and asking for their time. This obstacle is greater than many would care to admit.

The Difficulty Of “Face To Face”

I was teaching an experience design class in high school when it really hit me. Students were engaged in the design process until they were told that they had to request interviews from strangers. The anxiety levels went through the roof! A look of shock covered their faces. Shortly after, two of the students asked to receive a failing grade on the activity rather than have to face strangers (a request that was not granted)!
This was no longer a case of time, opportunities, resources or priorities. The interviews were a part of the class and were considered essential. The students were presented with a clear set of expectations, provided with aid in planning and writing questions, and taken to the location (a college) to conduct the interviews.
When all of the usual obstacles were removed, what was laid bare? A strong fear of approaching strangers, made even stronger by the fact that so many interactions nowadays are done online, rather than face to face. Ask someone to create an online survey and they’re all over it — ask that same person to pose those same questions to a stranger face to face and they’ll freeze up.
One might assume that the problem afflicts only those in high school, but such a deep-seated reaction is felt by many working adults who are suddenly responsible for requesting something from strangers — even when the thing being requested is a relatively low commitment, like 10 minutes for an interview.
Are you at the point in a project when you would benefit from insights gained from face-to-face discussions with potential users but find yourself blocked by a fear of asking? Read on for techniques to help you approach people for research, the first step to gaining the knowledge you need.

“I’m Afraid I’ll Be Bothering People.”

I’m sure you’ve been approached by a stranger at one time or another. The negative occasions stand out the most, when you were annoyed or felt guilty because you didn’t want to say no to a request for money or personal information or a signature.
When a stranger approaches, the person being approached has several concerns at once:
  • “Who is this person?”
  • “Are they trying to scam me?”
  • “Are they going to ask me for money?”
  • “Are they going to ask me to sign something that I don’t agree with?”
  • “Am I going to have to figure out how to get rid of them?”
  • “How long is this going to take?”
Your memories of being approached could make you uncomfortable if you’re the one approaching others.
The good news is that approaching people for interviews can be a lot easier than requesting a donation. If you make it clear quickly that their time is voluntary and that you won’t ask for anything they don’t want to give, then you’ll generally get a positive response. After all, you’re not asking people for money, just for their time and attention. Time is valuable, but its value varies according to the person’s situation at that moment — and you can do certain things to communicate the value of agreeing to your request.

Increase the Value of Participation

Interview requests are accepted when participation is perceived to be as or more valuable than what the person is doing at the time. People calculate that value in their heads when you ask for their time.
Below are some of the factors that can swing the calculation in your favor.

Find the Right Time

If someone is in a rush to get somewhere, then making your research seem more valuable than their desire to get to their destination will probably be difficult. Someone who is walking briskly, looking tense and not making eye contact is not the ideal candidate.
Approach people who appear to be one or more of the following:
  • Between tasks
    If you’re asking about a particular activity, go to areas where people tend to be finishing up that activity, and talk to them as soon as they’re done with it. You’ll get a fresh perspective on the whole experience, and they likely won’t be in a rush to get to their next activity. For example, if you want to interview runners, wander the finish line of a race. Look for runners who are cooling down and checking out their swag but not yet heading home.
  • Bored
    Waiting in line, waiting for a bus or waiting for an elevator — if someone seems to be idly swiping their phone or staring off into space, they might actually welcome a distraction.
  • Procrastinating
    Some activities take a long time. The human brain needs a change of focus every now and then, and your research could be just the thing. If your target audience is students, visit a study area. When a student comes up for air, ask for some time. They might need the mental break!
Regardless of whom you approach, give them an idea of how long the interview will take (about 10 minutes, for example), so that they can do the mental math of calculating the value of saying yes.

Be Aware of Body Language

As mentioned, pay attention to the candidate’s body language. Do they seem tense? Are they frowning at their phone? Are they power-walking? They might be late for a meeting, so the timing would be wrong. Someone gazing around or strolling casually is a better bet. People on phones are a bit harder to read because many check their phone when bored or procrastinating — still, their facial expression might tell you whether they’re open to being interrupted for something more interesting.
Your own body language is important, too. Planting yourself in the middle of a person’s path and facing them squarely will come off as aggressive, likely triggering a negative reaction. They might feel like they’d have a hard time getting rid of you if they’re not comfortable with your request.
Approach within clear view, but from the side. Also, try angling your body slightly away from the person. You want to seem engaged but also make them feel like they could end the conversation if desired. This will give them a greater sense of control and increase the likelihood that they’ll give you those precious seconds you need to make your request.

Fostering Interest

The feeling one gets from participating in research can be rewarding in itself. Interest is one positive feeling that leads people to say yes to research, which you can emphasize when approaching strangers.
Mention early on that you’re conducting research, which makes clear that you’re not asking for money and tends to generate interest.
Being approached to participate in research is fairly unusual for most people. The fact that you’re conducting a study might inspire a healthy curiosity. People will often be curious about what topic is being researched, what kinds of questions might be asked, and what they might find out about themselves in answering. The prevalence of quizzes and personality tests online is a good indication of this interest; those researchers are gathering data from the tests, but many of the respondents feel like they are learning about themselves (and potentially others) by considering the questions being asked.
The person might not be expecting to learn whether they’re a “benevolent inventor” or an ENFP by the end of the interview, but they might still find your questions interesting to consider.
Will the interviewees be shown something that others don’t have access to yet, like a new product or campaign? If so, bring that up quickly. It really boosts curiosity!
Furthermore, people might be flattered that you’re interested in their thoughts and opinion. Build on that! If there’s a reason you approached that person, share it. If you’re interviewing people about healthy food choices near a health food store and you stop someone who has just purchased something at the store, you could mention that their interest in health is one reason you approached them. Stick to obvious observations — you don’t want to come across as creepy!

Fostering Goodwill

Donating to a cause feels good, and volunteering time for research is no different. If your efforts are for a worthy result, like making texting easier for the elderly, share that benefit.
Another magic phrase? “I’m a student.” If you are, say so quickly to allay the person’s suspicion about your motive. Your effort on the path of learning will appeal to their goodwill.
If you’re not a student and your topic doesn’t sound particularly socially relevant, people might still be willing to help out if they connect with you. If you’re friendly and enthusiastic about the topic, then they’re more likely to say yes.
To keep the goodwill flowing, express your gratitude for their time and thoughts. Let them know before and after the interview that their time will have a great impact on the success of the research.

Offer Incentives

This one might seem the most obvious: You can increase the value of participation by offering an incentive. A $10 or $20 gift card from a popular vendor like Amazon or Starbucks can incline someone to accept a 15 to 30 minute interview. As the inconvenience to the participant increases, so should the incentive — whether that inconvenience is the length of the interview, the location or the time of day.
The incentive doesn’t have to be monetary. Be creative in what you offer. It could be access to a service that most people don’t have or a fun gadget that’s related to your topic (like a pedometer if the topic is health).
Offering an incentive can be useful, but don’t let it turn into a crutch. The point is to get comfortable with approaching people; associating a cost with that adds pressure that you don’t need. Learning to request participation without an incentive — and learning to increase the perceived value of participation without one — will take the cost out of the equation. Nevertheless, if you’re conducting formal research with a specific audience for a lengthy period of time, offering an incentive is definitely a best practice.

“I’m Afraid Of Rejection.”

Rejection is people’s number one fear when approaching strangers. Hearing no has always been difficult, whether it’s a polite no or an angry no followed by a rant. Either way, it stings. Your response to that sting, though, is what matters. How do you explain the rejection to yourself, and does your explanation help or hurt you?
Martin Seligman, one of the originators of positive psychology, conducted a study in the ’70s that gives insight into the types of mindsets that make people feel helpless. Seligman found that those who exhibit long-term “learned helplessness” tend to view negative events as being personal, pervasive and permanent. In other words, if a person is rejected, they might rationalize that the rejection is a result of their own failing, that everyone else is likely to reject them as well, and that they can do nothing to lessen the likelihood of rejection.
When you prepare to approach someone, consider instead that, if they say no, they aren’t really rejecting you, but rather rejecting your request. It’s not personal. Maybe they’re in the middle of something, or maybe they’re just not in the mood to talk. The rejection is fleeting, and the next person might be perfectly happy to participate.
Even knowing this, your first attempt will be the most difficult. Think of it like jumping into a pool: The initial shock is certain, but you’ll quickly get used to the water and will be swimming in no time!

Turn It Into a Game

When my brother was in college, he had a friend — let’s call him Bob — who had been single for a long time. Bob wanted to develop his ability to approach a woman and strike up a conversation, but he constantly froze up because of his fear of rejection.
One night at a lively bar, the two of them decided to make a game of it. If an approach led to a conversation — fantastic! He got 1 point. If the approach led to rejection, he still got 1 point for making the attempt. This turned failure into a small win and encouraged Bob to try and try again. The person with the most points at the end of the night won a free drink from the other. This shifted the focus and value onto the attempt, not the result.
Try this technique with someone who also wants to practice approaching people for research. Award a point for each approach, and reward the winner. Choose a prize that you both value but that doesn’t outweigh the good feeling of a successful approach. Not that you want to be turned down, but it helps to have a reward for plucking up the courage to try.

Variation: Football Rules

If you find the incentive to approach is still not enough, award a field goal (3 points) for every unsuccessful approach and a touchdown (7 points) for each successful one. Because interviews take time, the person who is trailing in points could pull ahead even if they’re mostly getting rejections.

“Only Extroverts Are Good At This.”

Google tells us that an introvert is “a shy, reticent and typically self-centered person.” Not a pretty picture! (An extrovert is defined as “an outgoing, overtly expressive person” — a more positive description, at least in the US).
Introversion has been erroneously associated with characteristics like being “bad with people” or being unsuccessful in approaching others.
In psychology, the field that gave us the terms “introvert” and “extrovert” (thanks to Carl Jung), the definitions are fairly different. The focus is on how people recharge their energy. Introverts tend to recharge by spending time with their own thoughts and feelings; extroverts recharge with external stimulation, such as time with friends or adventures in new destinations.
Jung stated that, “There is no such thing as a pure introvert or extrovert. Such a person would be in the lunatic asylum.” We all fall somewhere along the continuum. It turns out that some of the most fantastic researchers out there fall almost in the middle (called “ambiverts”). They balance an extrovert’s drive to interact others with an introvert’s skill in observation and reflection.
Daniel Pink explores this in his book To Sell is Human, which summarizes a variety of studies that find no link between high extroversion and major success in sales. (Pink defines sales as “persuading, convincing and influencing others to give up something they’ve got in exchange for what we’ve got” — a broad definition that could include asking someone to give up their time to participate in research.)
In fact, in the studies Pink cites, such as one by Adam Grant of the University of Pennsylvania, the highly extroverted — who tend to talk too much and listen too little — performed only slightly better than the highly introverted. Who did the best by far? The ambiverts, who balanced a drive to connect with an ability to observe and inspect.
If you consider yourself an introvert, then you’re probably relieved to hear that you don’t have to swing to the other side of the scale to be successful in interviews. You can use your skill in observation to pay attention to the environment and identify people to approach. You might need to tap into your extroverted side to approach someone, but once the conversation begins, you can call on your skill in observing and listening intently. With practice, this introverted quality will become an important part of the process that leads to the payoff: generating important insights.
Let’s explore a few techniques to ease gently into the ambiversion zone, exercising your interviewing muscles!

Practice Playfully

Practice your requests with a friendly audience and in a comfortable location to make the experience more playful and less stressful. Learning and playing go together!
Set challenges for yourself that expand your skills but that don’t have serious consequences. Instead of waiting for an intense, highly visible project at work to make your first attempt at approaching people, give yourself a short interview challenge. Pick a friendly location and choose a topic of research that would be of interest to most interview candidates and whose results you would not formally present.
Can you think of a local restaurant or cafeteria? Try interviewing its employees about their experience with the lunchtime rush to identify ways to better manage lines (of course, wait until after the rush to approach them). Taking a taxi? Interview the cab driver about their use of technology and how it has changed in the last three years. Do this as though you were conducting research for a real project (for example, ask to interview them, rather than launching right into your questions).
Here are two introductions you can practice:
“Excuse me! I’m a student, and today I’m conducting research on ways to improve transportation information for commuters. Hearing about your experience would be really valuable. Do you have 10 minutes to answer some questions?”
“Hi! We’re conducting some research today. Would you like to be interviewed on your lunchtime eating habits? It’ll take about 10 minutes, and your thoughts will help us improve the availability of nutritional information.”

Make It Meaningful

Whether you’re interviewing for practice or for work, tap into the aspects of the topic that make it deeply meaningful and personal to you. Genuine enthusiasm for a topic is hard to fake and will override fear to a large extent.
Remember the high-school students who were so afraid of approaching people? The class ended up going through the research process a second time with different topics. Instead of being told to interview college students about financial planning, students picked their own topics, like helping other students complete their homework, eating healthier meals and handling peer pressure.
The class picked students to interview, a mixture of friends and strangers. Because they were passionate about the topics (and had practiced once already), the second round of requests was much easier.
Likewise, consider practicing with more than one round of interviews:
  • Round 1
    Choose a topic that you know will be of interest to the people you’re interviewing.
  • Round 2
    Choose a topic that you’re passionate about. (Try to be objective, though!)
  • Round 3
    Take on a challenge for a product or project with support from other team members. (See the section below, “Pair Up Personalities,” for an example.)
If you’re on a team that wants even more practice, you could take turns suggesting practice challenges for each other. The more you practice, the easier it gets — promise!

Pair Up Personalities

If you consider yourself an introvert, pair up with someone who considers themselves an extrovert, and play to each other’s strengths for the first few interviews.
Using your observational skill, you could identify candidates to interview, and the extrovert could approach the first three people.
After the first three or four approaches, take a break and share your techniques with each other. You could share your insight from observing the environment and suggest tips on which people in which location might be best to approach. The extrovert could share tips on conversation openers that seem to be working well. When you’re both comfortable, switch roles to exercise the other’s skills.
This method situates you as mentors to each other, bringing you both closer to the middle of the introversion-extroversion scale.

Go Face To Face

Now that you’ve learned some techniques to get started, don’t let another week go by without trying one of them out! A good first step? Think of topics that you’re passionate about, the ones that are intriguing enough to propel you forward. You’ll find that the skills you develop will give you confidence to pursue the answers you need, leading you to better experiences for yourself and others.

Saturday, July 5, 2014

One of the most important factors in the success or failure of any IT project is communication. Communicating effectively can be quite difficult, especially when a project involves many people with different backgrounds, experience, skills, responsibilities and levels of authority. The problem compounds when the people involved belong to different organizations with different working guidelines.
Effective communication happens when a message is delivered whose content has the same meaning for the recipient as it does for the sender, thus inciting the desired action.

Why Communicate Effectively?

Consider a few scenarios. You will probably recall similar situations from your own experience.
  • A team leader has to keep an eye on the status of a project. All tasks are stored in an issue-tracking system. Unfortunately, the tasks haven’t been named very descriptively. For example, a bug in the contact form is described as “Something is wrong with the form,” and a need for a database backup is described as “Please help! URGENT!” The team leader would have to open each ticket every time to recall what it’s about. Of course, any sane person would change the descriptions immediately to “Contact form does not validate” and “Back up db0234@host1 database.”
  • A developer receives an email whose subject line reads “Just one question.” He can’t tell at a glance that the email is about a bug in the search engine and should be forwarded to his colleague. He has to spend time opening the email and digesting its contents in order to decide to forward the message.
  • A project manager organizes one or two hour-long meetings every week to discuss the progress of a project with the whole team. Each person speaks about their part for a few minutes and then sits bored for the rest of the meeting. From time to time, someone brings up a bigger issue that matters only to them and the project manager. In short, considering the hourly wages of the employees, a lot of money is being wasted on these counterproductive meetings.
  • A developer is trying to concentrate on a complicated problem but is constantly distracted by phone calls or by colleagues who walk in to ask about non-urgent matters.
As we can see, effective communication is critical. Without it, many problems arise: lost time (which means lost money), bad code, inefficient development, delays and products that don’t meet expectations. Ultimately, the reputation of the company and the client’s trust are at risk.
In this article, I will share some observations from an IT project I’ve been involved in for almost three years. As the development team leader, I work with about 30 people from different professions: developers, testers, administrators, designers, usability experts, project managers and people on the client’s side. Working in such an environment, I’ve identified the main obstacles to effective communication.
I’ve also been involved in devising techniques to overcome those obstacles. Most of the problems and countermeasures we’ll discuss apply to team environments, but freelancers might see value in them with their clients and partners.
Effective communication saves money, time and effort, and it happens when you do the following:
  • make a message’s subject easily identifiable (by “message,” I mean not only email, but any form of communication);
  • make a message’s content quickly understood;
  • be explicit in your message;
  • manage effectively;
  • involve only those resources (people, tools, etc.) that are needed to complete a task.
Proper communication leads to the following outcomes:
  • the pace of a project is sustained;
  • team leaders maintain control of the project’s progress;
  • people with different responsibilities and levels of involvement are better engaged in the project;
  • people feel their time is respected and well used.
Effective communication in IT projects can be encapsulated by three words: explicitness, traceability and readability.


Email is the primary means of internal and external communication at most companies. Surprisingly, many people still don’t know how to use it properly.
The subject line is the first thing that a recipient notices. It should be brief and should explain the contents of the email. The recipient might want to refer to the correspondence in future, perhaps weeks or months later. Therefore, the subject line should clearly identify the project (including the customer, depending on the organization) and the subject matter.
Of course, not every subject fits neatly into a project — in such cases, take extra care to make the subject line clear. Consider that, while you might be working on only one project for a given customer and “ACME Corp: new images” sounds like a good subject line to you, your coworkers in the marketing department might be working on many projects for the same customer, all of which involve “new images.”
Here are some examples of good subject lines:
  • ACME Corp. | HR Portal | draft of functional documentation, v. 0.1
  • ACME product page — questions after the meeting with marketing dept. on March 5th
  • Please, send your report — deadline: March 10th
Nicknames for clients and projects and the separator symbol should be agreed on by everyone involved in the project, because they enable recipients to sort their inbox according to filtering rules (especially for managers, who get hundreds of emails an hour).
Here are some real-life examples of bad subject lines:
  • ACME
  • Question
  • Request
  • New images
  • We’re going for lunch at 1 pm
That last one is from a follow-up email that contained important documentation — true story!
A clear subject line quickly tells the recipient the contents of the message and whether they need to respond in any way. For this reason, avoid changing the topic of conversation during an email thread (“BTW, about that other thing, did you…” is a dead giveaway). Either change the subject line or send a separate email.
The “To” and “Cc” fields are useful ways to indicate who is the addressee of a message and who just needs to be informed without taking any action. By default, the person in the “To” field should read and probably respond, while the person in the “Cc” field would do enough to just read the message. Many managers want to stay informed on matters that they are not directly responsible for, and they’ll configure their filtering rules accordingly, browsing those messages from time to time. Don’t “Cc” someone if you expect a prompt response.
One last rule, perhaps a lifesaver, is to do everything in writing. People tend to forget about arrangements made by phone or in meetings. Perhaps a form of communication other than email would be appropriate in these situations. We’ll discuss that next.


When you’re managing — whether it’s one large project or many small projects — compile all issues in one place to enable all team members to track their progress and know what needs to be done. Many teams make the mistake of assigning tasks and documenting important details in email. That might be easy to track when you have only one or two tasks to complete. In all other cases, it is the road to failure.
Issue-tracking systems — including Redmine, Mantis BT, Bugzilla, Jira and many more — enable clients, developers and managers to work together in well-structured process. Every issue — be it a bug report, feature request or question — becomes easy to track, with information about the person responsible, a full history and often even time-tracking and deadline reminders.
Every company employs a workflow that make sense for its business. Still, some rules apply to all situations, and here are ones that I’ve laid down after analyzing thousands of issues over the last few years:
  • Title each issue as descriptively as possible. Remember that most people — whether developers, project managers or testers — deal with dozens of issues every day. They should get at least some sense of an issue’s subject from its title. Thus, avoid titles like “Something’s wrong” or “A typo.” Rather, use self-explanatory titles, like “API throws NullPointerException when no attributes provided” or “Typo in the telephone number on contact page.” Issues with such titles will be processed more quickly because they are easier to manage.
  • Use attributes accordingly. Many trackers let you set special attributes on each issue, such as status, priority and category. Use them! The issues will be easier to sort, delegate and review.
  • Most trackers allow you to set relationships between issues. For example, you could mark an issue as being blocked by another issue or being a duplicate or just being similar. Relationships make it easier to assign tasks and find solutions.
  • Write about only one thing per issue. For example, if you find many bugs in an application, treat every bug as a separate issue. This way, tasks can be assigned to different people, who can work on them simultaneously. Different issues demand different people: designers, front-end coders, programmers, etc. When everything is in one task, managing and completing it takes much longer.
  • Provide as much information as possible. Link to the buggy web page; write all of the steps needed to replicate an issue; attach screenshots. I worked with someone who attached a Word document with a few words and screenshots, titling the issue “Everything is in the attachment” — a big no-no.
  • Write down in the comments section everything that happens with an issue. If someone explains something to you by phone or if a task is changed, document it. Don’t write, “We spoke about that issue on the phone, so now you know what the problem is.” Imagine that another developer will be assigned to this task in future and that anything not written down will be lost. Keep your project’s bus factor as high as possible.
To sum up, keep everything in the issue tracker. Give each task its own issue. And describe the issue as best you can.


Some people consider meetings to be a corporate nightmare. Many hours are wasted every week on meetings that contain no content and that don’t end with any useful decisions. “Status meetings” are the most popular kind of this: A dozen or so people gather to talk about different, often unrelated, projects. In fact, most of them are bored and not paying attention, waking up only when they need to talk for a few minutes about their situation.
A better way to stay in touch with team members is to speak with them frequently in person. When a team is working on a project, organize short morning meetings (5 to 15 minutes), like the “stand-up meetings” popular in agile development. This way, every member of the team will always know the status of the project. One member (usually the leader) could report to the boss, freeing up everyone else. Another good way to collect information about the status of a project is daily one-on-one communication. This will take up some time of the team leader, but it yields great results and saves time overall.
If you really do need a meeting with certain people, follow these practices:
  • Prepare an agenda. This way, invitees can prepare themselves for the meeting and — if necessary — submit their opinion, send someone else to fill in or just avoid the meeting if their attendance is unnecessary.
  • Stick to the agenda. Moderate the discussion and discourage talk of things that could be handled by a smaller group.
  • Don’t make decisions “together” — that won’t work. Instead, the small team that is responsible for a task should propose a solution, which should be discussed briefly and then decided on by the person in charge.
One last remark about meetings. Many people in IT do work that is creative in nature. Programmers, for instance, need time to build their concentration, and breaking this process is very destructive. Not all questions need to be answered immediately in person or by phone; some could be sent by email or instant messaging, thus protecting the creative process.

Other Guidelines

Let’s move on to guidelines that are useful not just in IT projects, but in life in general.
Having a common vocabulary with others is essential to communication, in both professional and personal life. This means using the same names for activities, projects, customers and so on. Misunderstandings arise when two people are talking about the same thing but don’t understand each other because they are using different terminology. Formally establishing a common vocabulary using a tool such as a wiki or whiteboard would be useful.
Managing the knowledge that is generated in a project is important, too. Documentation often gets outdated because no one cares to update it when the project’s requirements change. Important decisions and guidelines are lost in email and other communication. This often leads to misunderstanding or, worse, conflict with the client. Therefore, confirm every new version of documentation with everyone involved. When updating the issue-tracking system, remember to record details of phone conversations and email, noting who took what action or made which decision or provided what information. In short, log of every action and piece of information regarding an issue.
When working on a complicated project, I often find it useful to post important tasks on colorful sticky notes on a whiteboard (in addition to the issue-tracking system). Some are marked “waiting,” others “in progress,” yet others “done.” The color of the magnet affixed to each note indicates which team member is assigned to the task. People tend to ignore email notifications from issue-tracking systems; marking a task as complete on a whiteboard requires someone to stand up and reposition the note. Everybody can see the status of tasks and the progress of the project at a glance, which is the big advantage of this method. I also tend to write down other essential information, such as the time when the production environment was last updated or the number of bugs left to be resolved, broken down by team member.
If you develop software, then you probably use tools to manage your source code, such as Git, Mercurial or SVN. To facilitate your team’s work, implement some sort of workflow such as a branching model. Remember also to describe your commits informatively.

How To Introduce These Strategies

Forcing everyone to work according to specified rules is hard. Some people are reluctant because they feel that crafting their message more carefully would take a lot of time. Others don’t see the benefit or are just unable to formulate concise thoughts.
I suggest two ways of working with such people. First, show them that the amount of work necessary to better communicate is much smaller than the time wasted otherwise. For example, if a ticket in the issue-tracking system has a meaningless subject line and its contents are hard to process, then the time wasted will accumulate with every person who needs to work on it. A simple countermeasure is to invest a few minutes to prepare the issue better, so that time is not wasted afterwards. Other ways to enforce the rules are by implementing validation mechanisms (for example, in the issue-tracker) or by rejecting communication that doesn’t conform to the standard. It might sound brutal, but it’s effective.


The rules of communication can be summarized in a few points:
  • Communicate clearly. Load the most important information at the beginning of your message (in the subject line, title and first sentence). Learn how to encapsulate a message in one sentence.
  • Involve only the people who are necessary to move something forward. Don’t waste anyone else’s time.
  • Keep everything in writing and easy to access.
  • Read everything you write to make sure it’s easy to understand.
  • Break down big problems into small tasks that are easy to digest.
I hope you find these insights useful to your work. If you have any thoughts, please share them in the comments section below