online service design and barking cats

Sunday I was at the Green Valley Book Fair, where remaindered books go for another chance to reach customers. The Long Tail applied!

For some reason this time we found ourselves lingering in the business and management section, where there were large numbers of self-help leadership and marketing books, like "Leadership Secrets of Attila the Hun" or "The Martha Rules: 10 Essentials for Achieving Success as You Start, Grow, or Manage a Business," by Martha Stewart, or "The Mars Pathfinder Approach to 'Faster-Better-Cheaper.'"

Some of the titles caught my eye because they included some simple concepts that we rarely make time to consider: "The Transparent Leader: How to Build a Great Company Through Straight Talk, Openness and Accountability." "The Courageous Messenger: How To Successfully Speak Up At Work." "It's Not the Big That Eat the Small...It's the Fast That Eat the Slow: How to Use Speed as a Competitive Tool in Business."

But one title really caught my eye: "Waiting for Your Cat to Bark? Persuading Customers When They Ignore Marketing." The title is partly rhetorical -- the book is about new modes of marketing online services in an increasingly marketing-resistant world. It's also about processes through which we can potentially identify user needs and demographics and the persona building process. The cats barking metaphor comes from expecting users to respond like Pavlov's dogs, where they're really inscrutable and self-motivated cats. I'm not sure that I'm fully on board with persona development as I've seen it implemented, but I'm not reviewing the book one way or the other (especially since I haven't read it): it's purely the title that seemed aptly descriptive of a phenomenon to me.

We launch online services and wonder why our users don't use them the way we expected. We tend to populate interfaces with jargon-y terminology and then expect our users will learn the vocabulary to use the services. We on occasion provide functionality that we would use in our work and expect our users to need exactly the same and nothing different. We have been known to complain that it's our users who are broken, not our interfaces.

We're waiting for our users to bark.

Instead, we need ask our users more about what they want and need. We may not always be able to deliver, due to resource or technology limitations. But asking improves our credibility, and provides us with insights that we didn't have before we asked. Our Library is looking at designating a "user requirements" team whose responsibility is to ask questions, hold focus groups, and interact with a re-invigorated usability team. It looks like we're learning to meow.