Tie Consumer Profiles To Business Rules, Events, And Objects - Page 6
January 4, 2002
If you work in an object-oriented environment, you may want to
adopt a similar approach as a way to make sense out of the raw
impressions you have collected from actual interviews. If your
organization already has developed electronic profiles of each
visitor, you can work with the team to use the profiles to
recognize individuals or groups who trigger these events. These
events, to which the system reacts by following certain business
rules, can invoke particular objects—of that you may
include in your text. For example:
- The profile shows this person is a network engineer,
who has a dozen of your high-end routers installed, visits the
site every few days, joins the troubleshooting discussion list,
and has expressed interest in beta-testing new products.
- Business rule: If the company has more than $500,000
worth of our products installed, and if the person is an
engineer, and if the person has volunteered to do beta-testing,
then we should alert this person by e-mail and in a special
notice on his personal Router Page.
- Event: The person arrives, and the system checks the
profile, then checks whether there are any beta-testing products
available for this type of customer, decides there is one, and
calls for the content management software to display an object
called Notice on this person's personal Router Page.
- Object: Along with the other objects that go to make
up the personal Router Page, the software displays the Notice
object, which shows a photo of the new box, and invites the
visitor to ask for beta testing, using the dropdown form.
The kind of objects that you care about are extremely simple from
a programmer's point of view. They are chunks of text, with
associated art, sound, video—a single unit of meaning with
all the necessary components. Unlike a programming object, an
informative object has a limited function, that responds to a
question or need of a consumer by providing some kind of
information (no calculating the interest on a bank loan, or
figuring out the extended price). The main activity informative
objects perform is to display themselves when instructed.
To figure out when and where to display an informative object
(and for whom), you develop little scenarios called use
cases. You sketch out little scenes in which one or more
actors get involved in tasks, leading up to an event that is
handled by one or more objects. For programmers, these tasks,
events, and objects can be quite complex. For writers, the
picture is crude. Someone comes to the site with a goal in mind,
starts acting to attain that goal, and sets o¤ various alarms,
signals, and activity in the software, which is comparing the
person's profile with the relevant business rules, and wondering
if any of these actions merits calling a new object. You probably
don't care about the subtleties of event handling, triggers, or
object methods. You just want to know who comes to the site and
does something that deserves special content wrapped up in an
informative object.
After you have developed a few dozen use cases, you can start
shuffling them:
- Which ones are the most important to the consumers?
- Which ones really involve offering substantially different
content?
- Which ones cause the most problems, raise the most questions,
and require the most support?
For instance, you might find that most shopping carts are
abandoned at the page when consumers discover the true shipping
costs. One solution might be simply to move shipping costs to the
product pages so that people can make an accurate estimate of the
complete cost of the item before wading into the purchase
process. This approach might seem a little up front, even daring,
but by telling people this information ahead of time, you avoid
the moment of disappointment when they discover the real costs
after laboriously typing in their name and address, credit card
number, expiration date, and so on. In effect having looked at
the use case that had dramatic problems, you would move that
informative object—the shipping options and their
costs—to a more relevant page.
A use case offers the following information:
- A story, with screenshots and imagined conversation,
and internal dialog.
- A description of a complete and meaningful experience
from the consumer's point of view.
- A focus on the goals of the user, rather than the mechanics
of the software.
- A way of figuring out how to improve your site, not just
record the current process.
Use cases live comfortably in an environment of content
management software built on top of a database full of objects
that get assembled on a moment's notice to form pages for a
particular visitor. Unfortunately, unimaginative use cases often
end up describing current practice, suggesting no need for new
content. And even when the team focuses on problem areas, the
theme is usability, with the subtext of action and transaction,
but that often makes the team think about what is doable rather
than what consumers really want. In the world of objects, people
can easily become stick figures.
Making Sense Out of What You Learn about Your Audiences - Page 5
Hot Text: Web Writing that Works
Lumping People Together Into Small Groups - Page 7
|
