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 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 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.
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 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.”
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 activitygraphs
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.
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:
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
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 false — true if the device is a tablet or other mobile device.
Of course, you can immediately do things like this:
console.log(WURFL);
Or this:
alert(WURFL.complete_device_name);
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 example.com (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, wurfl.io/wurfl.js
(3). When the request reaches WURFL.io, 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 WURFL.io 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 WURFL.io 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:
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:
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:
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:
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:
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:
switch(WURFL.form_factor){
case "Smartphone":
if(WURFL.complete_device_name.indexOf("Apple") !=-1){
showAppStoreAds();
}else(
showWebAds();
)
break;
case "Tablet":
showSpecificProportionAds();
break;
case "Feature Phone":
showTextAds();
break;
default:
showGoogleAdwords();
break;
}
Conclusion
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.
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
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.
Issue-Tracking
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.
Meetings
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.
Conclusion
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
