Sun.com Customer Experience and Stuff: Notes from the Sun.com customer experience team.

Usually, you can't design a web experience that serves everybody all at once.  Well, unless you're Google and the entire population of the planet is doing pretty much a single set of things on your site. But if you're not Google, or even if you are, you probably need to define "segments" of users and customers so you understand who you're designing for.

Big marketing companies divvy up customers into dozens of different household segments, with cut nicknames like "Spouses & Houses," "Trucks & Trailers," "Soccer & S.U.Vs.," "Savvy Singles" etc  But these segments may not make sense for your web site or even your business. For instance, several colleagues who run various retail and business-to-business web sites tell me they've have noticed there are different segments of customer behavior even if everyone on their sites is a "buyer": Some customers buy from lists they keep, some others have jobs that involve a lot of reordering of the same stuff, still others who come and browse for specials for what's new, etc.

A lot of times, the personalities and job descriptions of the users affect what they need to do on a site, what missions they are on when visiting you on online. That's a different kind of segmentation than you might traditionally use for direct marketing.  If you're lucky, you may even have an idea about what these segments of users are and which of your segments are most strategically important or which generate the most revenue or profits for you (especially true in retail where buying cycles are have fewer touchpoints.)

For web design, it often makes sense to define segments of site users according to either their job role or the specific activity they do on your site. These two things are often connected, and it's no surprise a typical purchasing manager performs similar tasks on your web site to other purchasing managers... while other categories, say, journalists, are on different missions and use the sites much differently.

One of the first things you can do is tap into the knowledge you already have of types of visitors to your sites, to come up with rough audiences and "user segments." Then test your knowledge with some formal or informal field work. At Sun a couple of years ago, we started with audiences we already knew, which mapped to job roles (Developer, System Administrator, Purchasing Manager, IT Architect, etc).

For instance, folks who categorize themselves as "system administrators" are a loyal and knowledgeable group. We though we knew SAs pretty well, but to understand their web needs better, we went on some visits to their workplaces, had lunch with lots of SAs when they were visiting Sun for training, and also invited a couple dozen SAs to Sun just to show us the kinds of work they typically do on the web. Then we watched and listened and found a lot that surprised us. We captured this basic knowledge in a "profile sheet" that describes a canonical SA and that person's typical work and what they need from the web. We've used these sheets (and supporting scenarios) over and over whenever we look at tinkering with the SA areas of our web. And we update them pretty regularly.

More informally, when we wanted to understand how to improve the press area of the site (see pic), we started by trying to understand journalists jobs. Since we didn't have time or money for a fancy ethnographic study, I simply went down to JavaOne and interviewed twenty or so reporters and producers that were there covering news, and then supplemented this with some usability studies and interviews about the web site with journalists. At the end, though observation and interviews, we had a pretty good idea of the needs of all journalists (they're all on deadlines and they need to find your info fast), and also began to get an idea of subsegments and their special needs (TV field producers do a lot of the legwork and will use the web site before going out on a story; general media reporters need the basics available to them so they can explain complex tech topics in short headlines; etc.)

Why bother with any of this? The reason is that if you can understand the tasks and frustrations of your key audiences and subsegments, you can design a much better experience for them and they will become better customers more quickly.

This all relates to my posting from earlier this week about the redesign of some of our product pages for the Opteron-based servers and workstations. We did similar basic work to discover the information folks need when they're buying or researching products, and you see a lot of it incorporated into those new product page designs.

As we've progressed, we've gotten smarter about our segments and realized that subsegments within the same group often may need much different things. For instance, newbie SAs have much different information needs and expectations that seasoned fellows who've been on the job 10 or 15 years. New customers tend to have different sets of questions about products compared with existing customers who know your product lines.

While you may not actually go to the trouble of creating profiles and personas*, it's important to know your site customers well enough to design for the key segments and subsegments of your visitors. Do you know who yours are?

Cheers.

* The profiles mentioned here are different from true 'personas" (which we also use and which I'll post about some other time), but the idea is the same: Put a human face on a set of site needs and document it on paper so everyone on the design or marketing team is reading from the same book, so to speak.