Showing newest posts with label communication. Show older posts
Showing newest posts with label communication. Show older posts

Monday, July 12, 2010

Charting Out Your New Website


Getting a new website made can be a heady experience, and the return on investment can be significant. But the process of getting from knowing that you need one to actually being online can be confusing.

The example above is designer Tom Hapgood's mock up for a site we're building for a company that's been around for a long time without a website. This is a local company, so we've been able to meet with the owner in person and discuss her precise needs and preferences. We've printed out physical documents for her and found things on her computer. We've helped her to envision how things will look onscreen --  a difficult task if you're not used to it.

What if you're working with a company that can't or won't do this for you? How can you increase the chances of being able to communicate your needs the first time around and save on costly changes?

Try charting out your requirements ahead of time. Think ahead of time about your goals for your site, the mood and colors you want to use, and can show some examples of sites that appeal to you.

Item example

Name Homefront

logo use current

goals authority marketing customer service
examples site.com example.com example.org
colors blue pink
mood happy reassuring professional

With this information, you'll be ready to answer the questions your web professionals will have for you.

Tuesday, May 11, 2010

Iterations

Do you hear your web workers talking about "iterations" and wonder what they mean? Here's an example:

This image shows BillWestRoofing.com at an early stage, when Tom had refreshed the design and put in the new content.

This image shows the page in its current state. The fade-out picture of a roofer was added, and some phone numbers, the bars of tiny roof images have been added, the green and yellow circles ave been changed to text links, links for social media have been added, an additional page has been included, and the text has been changed.

This page has gone through several iterations, or sets of changes, to reach its current stage.

This is normal. And fun. And it can also be a frustrating and difficult experience, sometimes. The frustration and difficulty arise, when they do, from communication.

In this case -- not a frustrating one, fortunately -- we've had a variety of communication issues, ranging from uncertainty about which logos are the current versions, to questions about where various links should go, to uncertainty about which phone number belongs to which location. As I say, this hasn't been frustrating. But it has allowed me to think about some of the things that can help make sure your next set of iterations won't be frustrating, either:
  • Use a web-based solution like Basecamp or Google Docs to keep everything in line. Relying on emails sent back and forth among all the people working on the project is a sure way to get confused.Ask the team for access if you want it.
  • Name your files in a useful way -- and get everyone to be consistent. On a recent project, we were shooting around files with names like "current_page" and "update." If you all name your files things like "content-update-5" or "homepage_5.11.2010," you have a better chance of identifying the latest thing. It also makes it easier to talk about stuff, because you can say, "I think we should go back to the call to action from content-update-12," rather than, "I think I like the one before John changed it best."
  • Agree on terms. On another recent project, various members of the team were calling the same item "slider," "gallery," "widget," and more. Add people who don't use the terminology and are therefore using phrases like, "thingamajig," and you have some communication complexities in the making. Just saying, "Let's all call this a slider," can solve the problem.
  • Follow up phone calls and IMs with a written record. Whether that's a summary document uploaded at  your online shared workspace or an email record, it can keep you from thinking you've agreed to something you haven't -- or keep your team from thinking you agreed to something you don't want. Get agreement before you end the call on who will do this follow up.
Iterations can be an exciting process of seeing your site or document bloom into a perfect representation of your company or your ideas. These ideas can keep them from being a source of stress.

Friday, April 30, 2010

Collaborating Across Time Zones

Today I have a meeting with a local doctor about his website. He said 3:15. I'll be there at 3:15. But I also have a meeting at 10:00 my time with an East Coast client and a West Coast designer. We're also working with one designer in Europe and one in the Philippines. So we have an 8:00 for her, a 10:00 for me, and an 11:00 for him. And then at some point we'll hook up with the overseas guys.

Remote collaboration is wonderful. It's great to be able to pick and choose among talented people all over the world. But the time zones can be tricky. I have met people who won't work with overseas clients or who won't hire someone more than a certain number of time zones away, but I think it's unfortunate and unnecessary to limit yourself in that way.

How can you keep the time zone issue from being a problem?
  • Get savvy.  You don't necessarily need to memorize all the time zones and learn to make lightning calculations in your head. Still, it helps to have some idea of the time frames you're dealing with. I have clocks on my desktop showing the times in the three alternate time zones I most often deal with. The World Clock time converter can help, too.
  • Sleep on it. When you're in very different time zone from your collaborator or worker, be prepared to send a message at night and get a response in the morning -- or vice versa. I don't like waking up to an email from 1:00 a.m. asking me to do something followed by emails at 3:00 and 4:00 a.m. asking if I got the first email, and you probably wouldn't either. If you're on the other side of the world from your collaborator, you just have to accept that there'll be a longer lead time.
  • Specify. I used to say, "I'll have that for you tomorrow morning," not considering that I was talking to someone in London. My tomorrow morning wasn't his tomorrow morning, which led to confusion and possibly disappointment. Get in the habit of adding "PDT" or "EST" or whatever it might be when you set a time.
It gives "time management" a new meaning.

Wednesday, March 31, 2010

Using Notable


I've mentioned Notable before, but I think I've mentioned it in a sort of "We all know about this" kind of way. I've discovered that in fact we don't all know about this, so I want to share a little more about it. Click on the name of the site back in that first sentence to visit and try it out yourself.

As you can see from the examples here, it's a simple concept. You can capture a screen from an existing page (either online or at a development site). You can also use a picture of a screen -- so a screenshot or a mock up will work, too. Just type or cut and paste the web address in, or browse for an image from your files.

Having captured the image of your web design, you can click on any spot in the image and make a comment. The examples here were downloaded as PDF files. When you do this, you can send them to people and they can read your comments. I like to upload them at Basecamp so I don't have to say things like "The upper left hand side, right under the search box..."  However, you can also invite people into your Notable workspace to see your comments right on the screen.

It's easy to invite people in -- you type their email addresses in right at the Notable website. Then they also can make comments.



As you can see, Notable captures the whole site, so it's better than a screenshot. There's also an iPhone app, which helps with mobile discussions, when you may not be seeing the same thing if one person is at a computer and the other is using a phone to navigate to the site.

You can make comments on the site and what needs to be changed, on mock ups for a new site you're having built, or on content. The labels let you narrow in on the particular thing you'd like to discuss, and the comments are clear -- no "Love this!" scrawled on a corner or "Could we make the gray box -- no, not that gray box, the other gray box --"




The price is certainly right -- if you just use it occasionally, you can have a free account. Paid accounts range from $24 to $119 per month, depending on factors like the number of users, the amount of storage space, and the level of security you want.

Try it out. Let me know what you think.

Friday, March 26, 2010

Website Misery

A recent study of small businesses found some surprising results.

The majority of respondents were dissatisfied with their websites in some way -- 76% thought they needed improvements, 40% were unhappy with the amount of business the site generated, 23% didn't like the quality of the design...

Well, it's true that there are plenty of bad websites out there, but I'm not sure that these numbers necessarily show intense dissatisfaction. After all, we're seeing that 60% are happy with the amount of business their sites generate, which seems surprisingly high. How many businesspeople are satisfied with the amount of business they have? And more than three quarters of respondents like the quality of their design -- in fact, the percentage of people satisfied with their design is higher than the percentage who feel their sites could use improvement, and I'm inclined to think that most sites could use improvement.

Here's the stuff that caught my eye:
  • 44% said "Commissioning a website was a confusing or frustrating experience."
  • 41% said "Web designers try to confuse us with jargon."
  • 30% said "It was hard to find a web designer who understood our business."
Now, this is a true/false test, and we're still looking at 70% finding someone who understood their business. Having worked with everything from a stage hypnotist to manufacturers of biologicals, I know that grasping the nature of a business can be a challenge -- though it's a challenge that I enjoy. Not all of my clients understand my business, either. 30% doesn't seem that bad.

Still -- 41% believe that web designers intentionally try to confuse them with jargon? Nearly half found the whole business confusing and frustrating? Add those concerns to the feeling that these people don't even get what your company does, and you can be looking at some unhappiness.

Those are distressing numbers.Clearly, we web professionals need to work on our communication skills.

But I'd like to suggest that you -- if you ever find yourself in such a situation -- take the bull by the horns.

If you don't understand something, ask. It's easy for us to lose track of which terms are jargon. You spend a few years referring to pictures as "images," and you forget that most people don't use that term in that way. Don't assume that an unfamiliar term is being thrown around in order to confuse you.

If your web professionals don't understand something, offer. It's easy, as I said, to lose track of what's jargon and what isn't. Plan on spending a little time explaining your business, providing documents, or paying for research time. If it turns out not to be necessary you're ahead of the game.

My own company makes a priority of communication, and we strive to make sure that the website building experience is a positive one. Numbers like these reinforce the importance of this goal.

    Thursday, March 4, 2010

    Keeping Track of Your Web Projects

    Often a business owner will tell me that he or she has a web site being built. "I think so," they'll frown. "I haven't heard from them in five months..."

    Sometimes websites take a long time, for various reasons, and sometimes that may be fine with you. A good web firm will keep you informed, making sure that you know where they are in the process and getting your approval at the expected points. The image above shows a mockup for a site Tom Hapgood and I are working on for Ozark Natural Foods. We've had the content approved, and now we've sent this on to the client for approval, and we've stayed in touch throughout the process. The client can trust us to be communicative, and they seem content.

    But what if you want to keep up with the growth of your site on a day to day level?

    You can of course call and email back and forth. There are some real disadvantages to this.
    • It's time-consuming. If you choose this method, I promise you that your team has said, at least once, "Do they want us to talk, or to work?" in exasperated voices.
    • It can be confusing. We've all scrolled through lots of emails trying to figure out which one is the most recent, or which one had that piece of information we've been looking for. Conversations can include a lot of, "Which document are we talking about?" and "I thought you changed your mind about that -- wait, I have your email here somewhere..."
    • It's easy to leave people out. It's equally easy to send people lots of information they don't want or need, in order to avoid leaving them out.

    It's better to work in the cloud.

    One way to do this is with a development site. I'm doing that with site changes for The Retreat at Skyridge and for Clevertech. The client has a link to the pages which aren't actually public yet, and we can communicate directly as the changes are made.

    This approach still puts you at the mercy of phone and email, though. And it isn't comfortable for everyone. I work with some perfectionists who couldn't tolerate having people see their work before it's completely ready.

    You can avoid these problems with a shared workspace, where people can upload what they're ready to share. One option is Basecamp, a 37signals product. The screenshot below shows the a page at the Basecamp workspace for Ozark Natural Foods' website. It's not very exciting to look at, but you may  be able to tell that we have conversations, our calendar with milestones, our files, our time logs, and everything else in there.

    I use Basecamp with a lot of my clients, but there are other, similar tools. Solve360 combines the shared workspace with customer relationships management. OfficeLive is free, and it works well for me since I use Word and Excel, but not so well for designers using Mac and Adobe. Notable gives a space specifically for giving feedback on websites. oDesk lets you peep at your team's screens and upload files.

    As you can imagine, there are pluses and minuses to all of these tools. Basecamp is the most versatile, but it has so much information in it that it may work perfectly for your team and not so well for you, as you slog through arcane discussions about boring things and wonder why there aren't any pictures yet. OfficeLive doesn't work well for everyone's software and operating systems. Notable lets you give feedback, but it doesn't have a place to keep content files. Solve360 may have too much sensitive information to allow everyone full access. oDesk only works if you hire your team through their system.

    If you are relaxed and happy waiting for your website to emerge, that's great. If you can scarcely resist going into your team's offices and hanging over their shoulders, though, discuss the possibility of using a shared workspace. It might be just the ticket.

    Thursday, February 18, 2010

    The Van Halen Method















    This morning I read that Van Halen was known for rock diva irrationality because they insisted on having M&Ms brought backstage with all the brown ones removed. The authors explained that it was actually  a quick check: the contracts the band worked with included lots of technical details, and they figured that people who followed through on the "no brown candy" clause would also have paid attention to the technical specs.

    It makes sense to do the same thing when you hire someone rather than doing a task in-house.

    I don't hire designers who don't write html code that's easy to get into and work with. When I post a job at a freelance marketplace, I put in a phrase like "Please provide links to a similar project you've completed. Since we want to be sure of excellent communication, applicants who fail to do this will not be considered." If I were hiring writers, I would eliminate any candidates who weren't clear on the correct use of apostrophes.

    Less eccentric than requiring an M&M sort, but then I'm not a rock star.

    Are there items you can build into your hiring process to ensure that you're getting someone who reads the contract or specs and shows sufficient attention to detail? It could save a lot of trouble later.

    Thursday, January 28, 2010

    Choosing an SEO Professional
















    Years ago, I worked for a company that had a website that did nothing. No one shopped there, and as far as we could tell (which wasn't very far, because we didn't know how to keep track) no one went there. The owners went to a round table discussion on websites for people in our industry, and returned with a very clear conclusion: everyone had websites, and none of them did anything.

    You have to have a website, we figured, because people asked if you had one, and you couldn't say you didn't have one without looking unprofessional. But it was largely a big hole into which you poured money.

    We decided to change that, at least for our company. I was chosen, since I was the marketing person, and I set about learning how to make a website do its job.

    I remember how frustrating it was to search for that information. There were no books on the subject at the time, and the online information was written for specialists by specialists. What's more, SEO forums made it clear that a) there were a lot of shady characters in the business, an b) a lot of SEOs didn't have much respect for their clients. The undertone of "Stupid clients don't know anything" was unmistakable at a lot of otherwise excellent sites.

    We looked for a local SEO professional, therefore, since we figured we'd be able to meet face to face and ask around. There weren't any. I had to learn to do it myself. That's why I write this blog, actually: competent businesspeople should be able to learn how to help their company websites produce a good ROI, in my opinion, without being mystified or condescended to.

    Things have improved. As SEO becomes more mainstream and less mysterious to businesspeople, more information is available, and of course there are more of us SEO professionals around.

    So what should you look for when you seek to hire someone to help you in this area?
    • People who can and will tell you what they do. There's no reason for SEO to be cloaked in secrecy as though it were a dark art. While I think it takes a certain amount of ability, or at least an analytical turn of mind, SEO isn't mysterious. It just requires specialized skills, experience, and time that most businesspeople don't have.
    • People who can distinguish between black hat and white hat strategies, and who will tell you exactly how gray they are willing to get. If they can't or won't answer this question, you may find yourself in murky waters, with potential consequences for your website.
    • People who give you realistic expectations and honest information. While you want someone effective, reputable SEOs won't make guarantees. We know that there are too many factors involved for anyone to give you an honest guarantee of performance.
    • People who communicate with you honestly and respectfully. There's no reason to tolerate poor communication. You have a choice.

    Tuesday, January 5, 2010

    Common Web Courtesy



    The other day a client of mine asked if I could work with an associate of his. Of course, I was happy to. But the striking thing about this was why the organization he was introducing was eager to leave the web firm they were working with.

    "The current vendors," my client explained, "talk down to members."

    This isn't the first time I've heard this kind of thing, but I'd like it to be the last. Perhaps we could all make New Year's Resolutions to keep the web -- or at least web work -- courteous.

    Here's the least you should expect from your web team:
    • They should respect you and your knowledge in your field, whether you happen to be knowledgeable about their field or not. You will doubtless do the same.
    • They should explain unfamiliar terms clearly when asked. Ideally, they should use normal English when they talk to you. If they slip up, though, they should be prepared to clarify whatever jargon-laced thing they've said, without behaving as though you should have known that. You, in turn, should remember that people sometimes forget they're using jargon, and speak up if you get confused.
    • They should accept your ideas about their field, and be willing to explain what they're doing, within reason. Lots of humor among web people is about clients who have some vague idea about web practices and how much trouble they cause. Your web people should appear never to have heard of this type of humor, and not to find it funny. You, if you hear these jokes while you're studying up on what your web people are doing, should stop doing anything you recognize.
    • They should be able to cope with cultural or geographical differences, if that happens to be a factor. Checking on your time zone, recognizing the existence of holidays, double-checking on slang they're not sure of, following the spelling conventions of your country or of your corporate handbook -- all of these are reasonable adjustments.
    • They should try to work on a normal time schedule. Many web workers have very abnormal schedules, and of course there are often time zone issues to complicate matters. But when your web people say "I'll have it for you tomorrow," they should not mean midnight. Or next week. You, in return, should not get so dependent on their abnormal schedules that you think they are required by law to work nights and weekends. When I get an email at 11:00 p.m. and a "Didn't you get my email?" at 3:00 a.m., I feel nagged. Unless it's from the Southern hemisphere, in which case see the point above.

    As long as clients accept being talked down to, it'll continue to happen. Together, we can stop that. It'll make the web a better place to work.

    Monday, October 19, 2009

    Diary of a Website: Communicating About Your Website



    We're getting to the last stages before launch with the new site for GraysLland Acres llama and goat farm, so there are last-minute things that need doing: captions for the photos, final decisions about information architecture, little changes to the text. I send the analytics code to Tom and he sends the files to Shan.

    Even after launch, there are often little things that need to be discussed or changed.

    So how do you communicate about them?

    I'm not talking here about the kind of language to use. I've written about that before (links at the bottom of this post), but today I'm just talking about the logistics. We have so many options, from Adobe Share to sitting around a laptop at the coffee shop, that it can be hard to know what will work best.

    Here are some things to consider:
    • Who's involved? While I like email, emailing back and forth among a group of people can become complex and confusing. If you have several people involved in the decision making, consider getting everyone together in one physical location, or with a program like GoToMeeting, so that everyone can see the screen and hear everything at once.
    • Where are you? First, where are you geographically, because if you're in much different time zones, that may limit your methods. But there's also the question of where you are relative to the various communication media. Since I work at a computer most of the time, I prefer email, but let's just try a quick experiment. Complete the following sentence: "My email...
    * rings when it reaches my phone, and I check it as soon as it's convenient for me.
    * flashes silently on my screen, and I see whether it's important -- if I'm not in the middle of coding or something, or if I'm not in a meeting as I so often am.
    * goes to one of my many inboxes, and waits till I get around to checking that particular account.
    * chirps when it hits my inbox, and I look at it right away.

    If some of the people you're communicating with would answer this question differently from you, then email might not work for all of you. I know that texting works best for some of the people I work with, while Twitter is best for others. Find out before getting cross about people not answering you.
    • What do you like best? If you're the client, this is relevant. The phone is never my first choice for communication, but I use it with clients who prefer that. I've even had clients who liked to come and physically hang out with me at my desk, and I'll do that, too. I had a client once who wrote letters. If your writer or designer naturally goes with IM but you hate it, speak up. We have so many options nowadays that you can't expect anyone to guess your preference if you don't express it.
    Other relevant posts:

    Wednesday, August 26, 2009

    Making a Website for a Nonprofit Organization



    Last night Jon Schleuss and I presented the new website we built for the local chapter of the American Association of University Women. This excellent organization has been supporting equity for women for more than a century, and we were glad to have the opportunity to create their new site.

    We showed them which pages they could change themselves, which ones had to have changes made by the webmaster, how to use the blog and the calendar.

    The experience brought out some of the differences between working with businesses and working with other kinds of organizations. Here are some things to keep in mind when you build a website for your organization:

    • There may be a lot of different responses. While workers in a business generally are invested in the success of the website, members of an organization may not be. Some of the members of the AAUW didn't see the point of having a website at all. Others worried that the new functionality would interfere with the current methods of communication within the group. There were concerns that changes might offend the webmaster. It may be necessary to spend some time with the membership paving the way for changes.
    • There might be too many cooks. During most of the creation of the website, there were only one or two people from the organization involved in decision-making. Once the site was up, there were suddenly dozens of decision makers. With other organizations, we've seen all decisions have to go through multiple committees, or be passed around informally for weeks waiting for consensus. The AAUW currently has a couple of empty pages. Jon expressed it by saying, "Rebecca and I have personal websites, but this is a website for your whole group, so it should reflect the whole group. We're waiting for your input as a group, and as soon as you've decided what information you want there, we'll add that." My past experience is that members usually want changes after launch -- no matter how much discussion there is ahead of time or how long the conversation is left open -- so your organization may need to budget for the cost of making changes after completion.
    • There may be rules. The AAUW has lots of rules, ranging from the way logos should be displayed to the punctuation of the content. Corporations sometimes have this sort of rule as well, but national organizations nearly always do. Whether to use "e-mail" or "email," whether abbreviations and acronyms are allowed, and whether to use honorifics like "Ms" or "Dr." are among the usage issues that often come up. The central site for the organization usually has these rules posted, though local members may be unaware of them. It's worth checking for such rules and passing them on to your web designer and copywriter.
    I've done web content for religious institutions, professional associations, community organizations, and nonprofit groups. Invariably, the benefits of the website are similar to those for businesses, in terms of improved communication, new members, and increased funds. The process may be a bit different, but it's worth doing. In this case, the members of the local chapter are proud to say that their new website is the best branch website in their state. They're right about that. Their new design expresses the lively, diverse, dedicated nature of their organization, and should help to bring the next generation of educated women into the group.

    Monday, August 10, 2009

    Does Your Website Need a Team?




    Yesterday I was talking with some friends about working teams. The people involved in the conversation were as follows: the director of an airport, a high school music teacher, the director of a nonprofit, and me.

    We'd been reading articles by Stephen Graves and Marcus Buckingham, and we were considering the value of being well-rounded and ready to jump in and do whatever needed doing, versus the value of choosing the right team members for a project.

    Naturally, I began thinking about the websites I'm writing right now:
    • Over the weekend, I wrote content for a company with a tech team of their own. I wrote the thing and shot it over and now -- though I'm still getting cc'd on the error logs -- I'm through until they get back to me.
    • I'm working on two with a designer/ developer/ web host for which I'm content writer/ SEO/ linkbuilder.
    • I'm working on two for which I'm the content writer and there's also a designer, a project manager, a linkbuilder, and a webmaster.
    • There's one with a content writer (that's me), a graphic designer, a web designer/ webmaster, and a linkbuilder, all working sequentially rather than together.
    • I've also got one with me as content writer, a designer, and a webmaster.
    So I'm working with teams ranging from two people to -- well, I don't really know how large that first example's team is. Projects like that tend to involve some faceless group of people known as "the boys," "the guys," or "the lads," depending what country you're in. There could be two of them, or thirty-five, for all I know.

    I have clients who built their websites all by themselves or have their site build by an individual, and then just call me in for marketing. I also have some clients who assemble their websites by going to a variety of different companies or individuals for different things. They don't have a team, since the various groups or individuals aren't working together, but just get each item -- content, logo, design, hosting, etc. -- from a different source.

    Which is the better approach?

    There are advantages to teamwork:
    • You can choose each member of the team, or spread out the assignments to the members, according to the needs of a given project.
    • You have people doing the things they do best.
    • Work can be dovetailed for maximum efficiency.
    • Team members support and inspire one another.
    • You can choose to communicate with one team member, and still keep up with everything.
    • You don't need to know the best people for all the tasks -- you just need one person who can assemble the team.
    • That saying, "Jack of all trades, master of none" has merit. The best developer isn't also going to be the best writer.
    • You can develop an ongoing relationship and expect to have your future needs covered.
    • You can sometimes get the best price this way, since the whole is greater than the sum of its parts.

    There are advantages to piecework:
    • You can manage the entire project yourself, according to your own ideas.
    • You can choose an individual or company for each element of the job without concern about the synergy among them, or matching up their calendars.
    • You can sometimes get the best price this way, choosing providers from different circumstances at different rates.

    There are advantages to the one man band, too:
    • You can control the entire project by doing it yourself, or choosing one person to do everything.
    • There's a single point of contact, rather than multiple workers with whom you might need to communicate.
    • There's a single vision, rather than multiple inputs.
    • One person has responsibility for everything.
    • You can develop an ongoing relationship with an individual for future needs, though that individual may not be able to meet all your future needs.
    • You can sometimes get the best price this way, paying only one person a fixed price.

    Consider how you like to work, who you know, and what your goals are. Do you want to be able to order your website and then attend to your business until launch date? Then you don't want a piecemeal arrangement where you have to oversee everyone. Do you want to be able to drop in and check on the work every day? A team is harder to check in with than one individual, unless they're all in one physical location. Do you like brainstorming sessions? More heads can be better than one.

    In yesterday's conversation, the other people I was talking with didn't have the luxury, as I do, of bringing together a carefully-chosen new team for each new project. Neither did they have the experience I have, of being brought into different teams all the time. I like that, but not everyone would. For your website, you can make your choice.

    Friday, July 10, 2009

    Giving Feedback that Gets Results



    This morning I found in my email the very best kind of feedback on an assignment: "It's perfect!"

    I'm not going to pretend that I don't like getting things exactly right on the first attempt.

    But there are other kinds of feedback that I like almost as well.
    • Here's exactly what I didn't like, and how I want it changed. The first draft is always my best guess, based on careful listening and research, about what will work for the client. Feedback like "It sounds like we're bragging" or "It needs to be warmer" or "I wanted it to be more fun" tell me not only how to change the particular assignment, but also how to adjust my guess for the future.
    • Here's why I don't like it. Sometimes the reason for a change clues me in to a need for explanation on my part. An explanation about how the choice I've made helps searchers find the client's website may help the client see the benefit of keeping it. Knowing the reason for the dissatisfaction can also help me come up with a solution that will please the client and still meet the goals of the project -- often a solution that neither the client nor I would have thought of without pinpointing the dissatisfaction.
    • Here are my pet peeves, or my industry-specific quirks. I hate the word "utilize." Just do, that's all. I have clients who like "e-mail" and others who like "email." "Hauling" isn't incorrect when speaking of liquid freight, but it just isn't the term they use in that field. We all have preferences. They don't need to be defended, either. They're important information and should be passed along as soon as they occur to you.
    And there are some kinds of feedback that aren't that useful:
    • "Hmmmm....." Actually, I loved that. I really got that response once (or perhaps the designer I was working with did -- it was hard to tell) and I was so amused by it that I told all my friends. But it doesn't convey any information beyond "I don't like this," so it isn't going to lead to improved results. Some of us are more articulate than others. If you find yourself unable to say what needs changing, you might need to meet face to face or by phone and let your provider ask you questions till you figure it out.
    • Saying nothing. If you're not happy with your freelancer's or your firm's work, say so. Just being unhappy and accepting it isn't good for either side. It can happen that you reach a point where you feel that the person you've hired just isn't up to the job (didn't you check their portfolio first?), but chances are they've just misunderstood what you had in mind. Professionals don't get hurt feelings when you ask for changes -- we want you to have what you want.
    • Rewriting it completely. I had this happen once, and I really didn't know what to do with it. It wasn't as good as what I'd written, and editing it would have been a different assignment. I think I said, "Do you like this? Good!" If your freelancer's work inspires you to do your own writing and you like it better, that's fine. Their job is done. It just isn't feedback.
    Keeping these points in mind will help you get what you want -- which is your goal, and your provider's goal as well.

    Friday, June 12, 2009

    Ways to Collaborate with Your Professional Blogger

    josepha_haden_chomphosy

    Here's one way to collaborate with your professional blogger: meet on the balcony with a nice bottle of wine and a couple of notebooks.

    This is so rare, you wouldn't believe it. However, there are lots of practical methods for having a writer keep your company blog up to date:
    • Give your blogger access to your blog and leave it to the pro. This method works best when your blogger already knows something about your field, or has worked with you for a while. Settle on a posting schedule (three times a week, for example), let your blogger know any special preferences you have (time of day to post, word counts, etc.), and relax.
    • One client, when I told him we could do it that way, said, "I'm not that relaxed." I assured him that he didn't have to relax if he didn't want to. He has his staff post all the interesting things they hear during their workdays at Basecamp, and I pull stuff from that for his blog, Twitter, and newsletter. This works very well when your blogger doesn't have direct experience with the industry.
    • Give your blogger topics as assignments, and have posts either sent to you or posted as drafts for your approval before they're published. Frankly, this tends to result in a blog that isn't posted regularly. Let's face it, if you had the time and inclination to come up with topics and edit the posts, you wouldn't need to hire a blogger. However, I sometimes begin with this set-up and then shift to the first style once the client feels completely confident.
    • Have posts done in bulk and sent to you. I have a couple of clients who prefer to work this way. I'll send ten or twenty posts, and they can post them on their preferred schedule. In some cases, they save these for days when they don't have time to do their own posts. Not only does this allow you a high level of control without excessive time commitment, but it can be a very economical approach, too. I charge by the hour, but bulk blogging is so efficient that the cost-per-word can be half as much as for weekly posts.
    • Have your staff write blog posts and let your blogger edit them. This is a good method when you want full control over the content, but still want a professional quality blog. This method can result in your paying far less to your blogger -- I can edit a post, even a really badly written one, in five or ten minutes. However, you still have to pay whoever's doing that bad post in the first place, and they probably can't do it as fast as a pro. This works best when you have staff with special knowledge and free time you're already paying for. Put your blogger on retainer, too, if you take this approach. No one is going to be willing to bill you in five or ten minute chunks.
    The marketing value of a blog is incontestable at this point, but blogging regularly is rarely the best use of your time.Collaboration with a professional writer is the solution. Any of these approaches can make it a simple and stress-free process.
    Stumble It!

    Monday, March 30, 2009

    Client and Contractor Crossing Swords?

    fencers
    Actually, I never fight with clients. But I do sometimes disagree with them. And sometimes I tell them so.

    This came to my mind recently when I was talking with one of my favorite local hardware guys. I'm not going to tell you his name, in case what he said was an unguarded remark that he wouldn't really want to own up to.

    "Web people are crazy," he said firmly.

    I am myself a web person, though I don't usually describe myself that way. I first encountered the term last Hallowe'en, at UAMS, our local medical school. I was chatting with the associate dean, and someone came in saying, "I need to take Rebecca down to the basement to meet the Web People." We made our way through a variety of creepily costumed people, on our way down to the meet the Web People, and no one else seemed to think it was funny at all.

    It was at that moment that I knew I probably didn't want to become one of their Web People, much as I liked everyone. How could they not find it funny?

    But I digress.

    The hardware guy went on to explain his views on web people. "They ask the clients what they want!" he said with unconcealed scorn. "Clients don't know what they want!"

    I gave a rueful nod.

    "I'm a web person," I reminded him, "and I'm not crazy."

    I felt that I was on stronger ground with this objection than I would have been had I objected to the idea that clients don't know what they want, because sometimes that's true, in a way.

    I do both copywriting and SEO, and I approach the question differently in the two cases. When I'm writing for someone, I assume that they know what they want. I write the thing and send it off, and if they come back with "I don't want to reference those publications" or "I don't like the last paragraph," or "That's not the focus I wanted," or "I want more/fewer/different technical terms in there," or "I wanted 480 words and you've given me 492; please cut," or "Can't you make the part about rules-based systems sound more fun?" -- well, I do just that and send back another round. The customer, as far as I'm concerned as a writer, is always right.

    In SEO, it's another thing entirely. My clients in that case are not actually paying me to enscribe their visions. They're paying me for results. I know that, however happy they might initially be with something that precisely meets their preferences, they're not going to stay happy if they don't get those nice rankings.

    So when it comes to SEO, I argue with clients. Politely and respectfully, of course. But if they want something that's not going to be good for them, I'll try to talk them out of it. I want them to end up with a usable, well-optimized site, whether they happen to know what that is or not.

    If they insist, of course I'll go ahead and do what they want. After all, I'm not a hardware guy.


    Stumble It!