The value of lurkers

In online community management, the holy grail is to have active participation from the majority of the members of your community. That is what online community managers work so hard to achieve. A lot of time and effort is put into getting everyone participating (posting comments or forum posts, friending each other, etc.).

As someone who is naturally a bit of an introvert, this always struck me as a little odd. Maybe I don't want to spend all of my time talking. Maybe I get more value out of an online community by reading (ie., listening). If you look at physical human communities, it is a diversity of personalities that makes them work. If everyone was standing in the town square -- all the time -- all trying to talk at the same time, how is that useful to anyone?

...Unless your goal was to measure and increase the amount of noise in the town square.

Lurkers (people who just read and don't actively contribute content) make up the vast majority of any online community. Are they of no value at all to growing a vibrant online community? I'm a lurker. I visit sites often, I subscribe to email newsletters, and I click on ad links. I feel a personal affinity to the site. I also talk about what I read to friends and family and I will buy (or not buy) things based on what I read on the community site.

Most of the experienced community managers I've met would meet this challenge with a heavy sigh and say "No, it's not that simple. Of course you need diversity. Of course every community member has value."

So why are community managers constantly setting up participation rates as community goals? What are participation rates so often the basis of a community's ROI (return on investment)?

I can make an educated guess. From a business perspective, providing an online community can be expensive. It takes a lot of people to keep everything running and friendly. Finding an overt measure of its value to a business is tricky. You often can't tell if reading a random blog post actually influenced a lurker to follow through with an action such as trying out a new brand of peanut butter, cleaning up a neighborhood park, or voting for a political candidate.

Are we using participation rates for ROI as a convenience because the web servers give it to us? Heaven knows I've done that. I was pushed into a corner and had to come up with something I could measure. I knew as I did it that it was a convenience and that it would likely bite me later. It did. What I found is that those participation rates didn't really do anything to predict or support the end goals of the community. I found myself managing two things:

1. Making sure I met my participation goals, and
2. Trying to move the community toward the stated goals of the community/organization.

I believe with all of my heart that the online community was doing what it was supposed to. I just couldn't prove it. If you can't prove something, it's hard to keep getting funded. I came away from the experience thinking that we need two things:

1. Some more targeted, creative ways to measure ROI, and
2. Some realistic expectations based on organizational goals.

If the goal is to sell gadgets, no problem. It's an easy value proposition. If your organization is a nonprofit with a goal like "improving the quality of life of one-legged hermaphrodites around the world", that's a bit trickier. A community, logically, must support the organizational goal. How do you measure that?

Come on. Really.

Will having 500 one-legged hermaphrodites whining to each other on your forums really make their quality of life better? Isn't it more likely that allowing people to see that they are part of a larger, global community -- whether they choose to put up profile photos or not -- is supporting the organizational goal better?

I'd like to argue that lurkers are an important part of any online community and need to find their way into more ROI measures. Some quick ideas:

• You can measure the number and turnover of lurkers.
• You can segment users into groups and start tracking email open rates more carefully.
• You can measure how long a person remains a quiet part of your community.

I know I'm not the first person to think or write about this, but I think the value of lurkers to your online community is easy to forget. It's worth raising the flag every now and then and, as we learn more and more about the ROI of online community to business, brainstorming how to measure their value.

Did you just get stuck managing a web site?

It's been a crappy economy and companies/organizations are scaling down dramatically. If you are a "survivor" of layoffs, you are probably doing the work of someone who... well... wasn't.

Maybe you are now managing the corporate web site -- whether you know anything about managing a web site or not.

What's the first thing you should do? Cover your butt. What's the adult, professional version of a Huggy's Pull Up with princesses on it?

Talk to your boss about your personal performance expectations and expectations for the site.

If you still have another full-time job to manage, you really need to be clear with your boss about how much time is to be spent on this. If you are stepping into a web site that either has been running along pretty easily with no big redesigns on the horizon, you'll probably be able to manage it on a part-time basis. If your web site has been sort of ignored and you are stepping in to "get it back on track". You'll be able to manage the amount of time you have to spend if there aren't already many expectations around it. If you get to set what is going to get done, you can control your time.

Just be really conservative about what you plan to do.

If you are being asked to oversee a large-scale redesign or replatform, you are looking at a full-time job. This is true even when you are outsourcing the design and technology. Here's a quick list of the things you'll need to do even if you are outsourcing all of the work:

• Work with internal stakeholders to figure out what the site needs to do/look like.
• Document this in as much detail as possible since you'll need to communicate it to vendors.
• Create an RFP to find a vendor (or multiple vendors).
• Analyze the proposals as best you can with a limited background in this stuff.
• Sit through the "dog and pony" shows from vendors and try to figure out who is bullshitting you.
• Negotiate a schedule and contract with the vendor(s).
• Work with the vendor's project manager to write up some requirements for design and technology.
• Talk to the vendor's designers about what your need.
• Talk with internal stakeholders about the designs you came up with. (Everyone is a designer so stakeholders will demand approval of visual designs and ignore discussions about the technology. That's a little backwards, but such is life.)
• Make a million micro decisions about what the site does and looks like in order to keep it on schedule and on budget.
• Find or create graphical resources (logos, photos, etc) for the designers.
• Find, create, or get others to create an awful lot of editorial content.
• Make a million more micro decisions about the technology. The programmers need a lot of information from you. For example, a coder working on a form would need to know what the questions are, what the answers are, what font and typesize they need to be, what colors need to be on the form, whether each question is multiple choice or yes/no, and what happens when the "submit" button is pushed.
• Deal with changes/new ideas from internal stakeholders as time passes. Keep managing these changes to your budget and schedule.
• Write more content. You'll need a little backlog of stuff so the site changes shortly after its launched.
• Do technical and content QA (checking for mistakes) on the initial software. This is important. The minute you say it's OK, the vendor has completed his or her contractual obligation. Additional changes will cost you extra.
• Communicate internally to your boss and your coworkers about the new site and how it will help them/impact them.
• Oversee the launch -- do another QA. Fix any problems you uncover.
• Create some documentation for the person who will follow behind you and maintain/grow the site.
• Possibly hire the person who will follow behind you and maintain/grow the site.

I don't care how amazingly organized you are, you won't be able to effectively maintain your other job. Just trust me on this. Save yourself the ulcer and find a way to take a leave of absence from your other role until about a month after the redesigned site has been launched. (You'll need the month to clean up little things that came up during the main development process and get everything organized for the person who will come in after you to do the maintenance.)

If that's not an option, then you'll need to start getting creative. One possible alternative: Get a buddy. See if you can get your organization to assign at least one other person to help you manage all of this. Two organized people who work well together could pull this off while doing other jobs.

If you are going to be juggling another job, here's another hint. Be really up front with your vendor when you are talking to them initially -- before you sign a contract. Tell them that you are juggling two jobs here and that you'll have limited time for feedback. They can take a lot of the microdecision-making, stakeholder stuff, and documentation off your plate. You'll need to pay the vendor for the extra time, but it'll be cheaper than hiring a full-time person.

A note on social media. Be careful here. Participating in other social networks takes a mind-boggling amount of time over and above the time you are spending on just maintaining/redesigning the site. The catch is that, in order to be noticed, you have to participate a lot -- many times every day. You have to be offering valuable information to the community you are participating in. You have to create personal relationships with people in this community. If you don't slog in the hours, you are just part of the background noise. You won't be noticed, you won't push new people to your web site, and won't hit your organization's goals.

Don't try to keep up with more than one or two social networks. Prioritize according to where your site's people are already congregating and then focus on those. If you are pretty sure that the members of your site's audience aren't heavy social media users, then lobby to get this off your plate until you have some help.

*salute*

Good luck. You'll need it.

Usability, part 2: What could go wrong?

So just plan for regular site-wide changes a couple of times a year. Sounds easy enough. Well, as with so many things in life, it is easier said than done. I do still think this is the way to go and the solution most likely to work, but there are some things to kind of keep in the back of your mind.

1. Keep everyone busy and focused

If you have an in-house staff, don't plan to do a bunch of design work or testing during this time without giving them something to do. With all due respect to software and hardware engineers, interface design generally isn't the thing you are best at. If you are going to focus on bug fixes, don't leave those design/content folks sitting around bored in their offices (I'm bunching editors and designers together as they have to work together to do site-wide changes). *sigh* It goes both ways. Bored design/content people and bored techs will get you into equal amounts of trouble.

Make sure everyone knows what they are supposed to do and by when. Keep a "scut list" of little tasks useful to the entire effort that someone can do when he or she hits a stopping point.

2. The stakeholders

This sort of depends on the culture of the place you work in. I've been in some places where everyone is just so busy that being left out of a furious two-week development effort will get you a wide grin, a kiss on each cheek and happy "see you in a couple of weeks!" This approach works beautifully in that environment. I've also worked in places where paranoia reigns and if you tell someone they can't participate in something -- anything -- like a six-hour, unanesthetized root canal -- they'll beat you about they head and shoulders until you vacate the dental chair because they are sure you are hiding something really cool.

If you are in that kind of place, this approach might not work. When I faced this, it didn't work. The paranoid stakeholders demanded a place at the table in a way that I couldn't stop and then proceeded to derail every conversation back into the day-to-day noise where they were most comfortable. *sigh* They weren't trying to be evil. They honestly wanted to learn more about web strategy and to participate in the effort... but two weeks is just not long enough to bring people who don't live this stuff up to speed.

Regardless of which culture you are dealing with, be sure to communicate to anyone who is interested:

• what you are doing,
• why you are doing it,
• how what you are doing will affect their stuff,
• what you hope to accomplish, and
• when it will be over.

Even if no one asks, being able to answer these questions keeps you honest and focused.

3. Keep everyone in the loop

If you are pretty much a one-man- or one-woman-show, be sure that your tech vendor has a heads up that you are going to be messing with things site-wide. Be specific that this is A VERY BAD TIME to do "routine maintenance" since you'll start losing your changes randomly. Make sure that the vendor has done a good backup of the site before you start. If you have a team sitting with you, you can usually run screaming down the hallway and find someone to undo your mistake. If you are by yourself, the scenario will likely look like this:

• You make a change. Shit breaks. Your heart stops and you start hitting the backspace button crying "no... no... no..." under your non-existent breath.
• You call your tech vendor. The ONE PERSON who has the passwords to your site is sick/on vacation/at lunch/with another client or otherwise unavailable for some indefinite length of time.
• You request that he or she contact you as soon as possible and slam down the phone.
• You stare at the monitor for a few more minutes. The adrenaline spike starts to come down and you decide that since you broke it, you should be able to fix it.
• You try a few things and nothing happens.
• You try a few more things and bad things happen.
• You get a phone call from your tech vendor. Your person with the passwords urgently requests that you STOP TRYING THINGS.
• You sit at your desk, hitting Refresh every 15 seconds to see if the site is fixed while chewing your thumb down to a bloody stump.

Yeah. Been there. Done that. If you have a good site backup, you might be able to save your thumb.

4. Don't try to do too much

Two weeks sounds like a lot. It's not. If you are going to accomplish anything, you'll need to be organized and everyone will need to work together like a well-engineered watch. Even with all of this, you'll be working your butt off trying to get one or two solid site-wide improvements done.

Don't try doing this more than twice a year. This takes a lot of planning and you'll wind up feeling like you are on a treadmill... so will your staff. It affects the quality of both these special efforts and your day-to-day work.

Don't try to load up too many changes concurrently. Don't have the techs upgrade the servers at the same time you are redoing your templates or trying to purge every instance of the phrase "click here". Seriously. So much can go wrong that it's not funny. You are going to be doing this every six months. Just schedule your little nuggets out.

5. Measure and assess what worked and what didn't

This sounds like a no-brainer... and it is, but you'd be surprised how often "no brainers" get forgotten or put aside until there is more time. Engineer in measurement (or testing) to everything that you do, no matter how small. Schedule time ahead of these routine efforts to assess the changes from last time for what worked and what didn't and align the new changes to what you learned.

Document your assessment results and thinking... even if you are sure no one will ever read it. Just like the communications thing, this sort of documentation keeps you honest and focused.

There are still lots of things that can go wrong. It's really tough to keep this up as the daily noise keeps getting louder and louder. You have to force yourself to go through it sometimes, but you'll wind up with a much better web site and a lot of hard-won best practices to go with it.

Usability, Where for art thou, usability?

Ah, sweet usability research/design/architecture/whatever... it's like an unrequited love. It's always just a bit out of reach and, being there, remains unsullied by the day-to-day messiness of living together.

Usability testing is something that web people know we should do more often... well... every time but somehow never get around to it. Even if there is an opportunity to do a little testing (or to just apply insights learned from reading about some testing on someone else's site), we rarely get to act on it because we haven't the opportunity at that particular time to make significant site-wide changes. The problem might be a lack of money to apply a change that would make a site more usable, but it's most likely time. Your to-do list never seems to shrink and so you tack your golden nugget of an idea up on the bulletin board on top of the ten other great ideas that you'll likely never get around to.

It's an amazing stupid reason to not improve a web site. You know that and I know that... but it can't be helped. Real life keeps getting in the way. The days pass and you watch your golden nuggets get more dated and irrelevant.

What could you and your site have accomplished if only you could get your head above the daily noise and try out some new theories?

Here's one idea.

The next time you get the chance -- when you are sitting down for a yearly strategic planning session or the next time your site is getting complete overhauled with a new platform or design -- make a suggestion. Why not just plan for a twice-a-year review of the site. Pick two or three items from you and your team's list of golden nuggets. Any more than that and you won't actually finish anything. Plan for a couple of weeks (around the winter and summer holidays) of

• assessing test results from any formal or informal testing,
• reviewing your site stats, and
• quickly implementing some site-wide changes.

Keep it web team focused because you'll be indulging in some seriously geeky stuff. Try to keep any stakeholders who aren't directly connected to your changes out of the meeting. Make it a party. Bring in M&Ms. You'll need them. This will be rapid development at its best.

By actually planning for small, strategic changes more often, you might be able to push off the inevitable, soul-sucking redesign/replatforms that tend to come very 12-24 months. If you are smart about measuring your efforts, then you can also make smarter choices about design and technology when it really is time to redesign and replatform the site.

Tomorrow, Part 2: What could go wrong?