Creating Passionate Users: How to get users to RTFM

« Why marketing should make the user manuals! | Main | Friday bytes »

How to get users to RTFM

Understandvsmemorize_1
The "F" in RTFM is the biggest clue that most of us blame the user for not reading the manual. But if "reducing guilt is the killer app", companies should take more responsibility for whether readers use their manuals. And since we can't force our users to do anything, if we want them to RTFM, we need to make a better FM.

[This post is a follow-on to two earlier posts, Are your Users Stuck in P Mode (worth reading for the very useful comments from others) and my previous Why Marketing Should Make the Manuals]

Qualifiers: this post is about products for which someone might have--or develop--a passion for whatever the product lets them DO. So, we aren't talking about, say, watches or portable radios--although these simple products still need good manuals. Also, these tips are for those who are NOT professional tech writers. Too many times, being asked to create the manual is almost a form of punishment because the company doesn't appreciate the importance of the manual, let alone the skill (and time!) required to craft a good one.

Note: This is one long-ass post, with most of the words living in the vast cognitive wasteland known as the middle. If you look at the graphic and skim only the headings, you'll get most of what's in here. The rest is just support details.

In no particular order, a few tips on making a better FM:

Make Reading the Manual Unnecessary

In theory, "If your product is good enough, they shouldn't need a manual." In practice, that's a meaningless sentence without context. If your car radio does need a manual (oh, how I hate that mine does), blame the designers. But if your pro video editing software doesn't, then it's probably not a "pro" app. A complex product that needs a manual does not necessarily mean there's a design flaw.

If you are lucky enough to be in a position to influence a product's design, then of course you'll try to reduce the need for a manual. All the standard usability, information architecture, and user experience advice applies here (e.g. make the product intuitive, make the right things easy and the wrong things hard (to do), rely on what Don Norman refers to as "knowledge in the world" rather than "knowledge in the head", whenever possible (more on that in a minute), follow sound user interface guidelines (burn Steve Krug's ideas into your DNA), etc.)

And if are a product developer, please, PLEASE kick the crap out of anyone on the team who utters the phrase all tech writers fear and hate , "We'll fix that in documentation" -- a phrase that actually means, "We f'd up, but the tech writers will make up for our mistakes by putting a bunch of extra stuff in the manual to deal with it."

But... I wrote this post because most of us don't have the luxury of modifying (let alone designing from scratch) the products we want to help people use, so the rest of this assumes that you're pretty much stuck with what you've got.

Separate Reference from Learning

A good manual for a complex product should usually include at least FIVE distinct sections: Reference Guide, Tutorial, Learning/Understanding, Cookbook/Recipe, and Start Here. The single biggest problem with most ~~bad~~ less than stellar manuals is that they're usually only reference. But even with the best index on the planet, a reference guide suffers from one huge mother-of-an-assumption: that the user knows exactly what to look up!

A reference guide, no matter how technically correct and concise and clear and all those other referencey goodness attributes, does virtually NOTHING to get me out of "P" mode if I don't even know what (or even that) I should be looking up.

If I have a specific thing I know I need to do, AND I know what it's called in the product, then I'm fine with the reference guide. But reference guides fail:

* If I have only a vague idea of what the "thing" is called that I want to look up.
OR
* If I don't even know the thing exists
OR
* If I want to get better not at the tool, but at the thing the tool lets me do.
(This is my problem with the Nikon D200 manual (which is actually a really good reference guide)--it helps me use the camera controls, but it's teaching me only about the camera--the thing I care least about. What I really want is to take better photos, and if the manual helped me figure out which features of the camera mapped to which cool photography things I might want to do, I'd come up the curve more quickly--which means a better chance of becoming passionate, yada, yada, yada).

1) The Reference Guide
Despite the problems with having only a reference guide, it's still one of the most important parts of the manual and deserves the best you can give it including a great index, a user-friendly, relevant organization scheme (make it easy for me to look things up regardless of whether I know what they're called, etc.), and clear, concise information with visuals whenever possible. Since reference is where most manuals concentrate, and far more people are skilled at doing it, I'm not going to say anything else about it here.

2) The Tutorial
By "tutorial", we mean walking the user through a concrete example of using the product to do a specific task. A lot of manuals skip this in favor of giving abstract instructions for how to do something, but not all brains can learn that way. For many people, a step-by-step tutorial is the only thing that helps them "get it." So, even though some users will never need or read the tutorial sections, they can mean the difference between a new user who actually uses the product and one who never gets past opening the box.

A few tips on good tutorials:

* Choose examples that best reflect what most new users will want to do.

* Keep the cognitive overhead as low as possible by NOT using an example that requires domain-specific knowledge. For example, a tutorial on a desktop publishing program would be better using a pizza shop as the scenario rather than, say, a tax attorney. The learner should be able to focus 100% of their brain cells on doing the tutorial and not a single neuron wasted in figuring out why that particular business would need to do that particular thing...

* Include a LOT of them. Some of us learn by "triangulation".

* Watch for cliffs! The deal-killer in a tutorial is when a crucial piece--however small--is left out either inadvertently or because the author assumed this part of the step was so frickin' obvious. Of course, the level of granularity you choose for a "part" depends on who your audience is. Most software apps today should not have to explain how a mouse works, for example; a lot of pre-existing user knowledge is rightly encapsulated in the "Select FOO from the BAR menu..." But, rarely do people complain that the manual contained too many step-by-step details. For most of us, the pain starts when we suddenly turn the page and say, "Uh... what did I just miss? How the hell did they get THERE? My dialog box looks nothing like that..."

(If you want to know more about making good tutorials, a great place to look is at the Visual QuickStart Guides like the ones Tom and Dori write.)

3) Learning/Understanding
The more they understand, the less they have to memorize. The only way to reduce the time and pain of the learning curve is to increase learning. Too many manuals mistake reference information and memorization for learning, but we've all experienced the frustration of looking something up, doing it, and then forgetting everything the next time we need to do it again. The only way to really make it "stick" is by helping them 'get it' on a deeper level, where the mental model (thought bubble) in their head matches the one you were trying to communicate... the mental model that lets them extrapolate and infer and be creative about things that weren't in the tutorial.

While a tutorial is a concrete step-by-step use-case, without a deeper understanding of how and why things work the way they do, the user/learner can have trouble adapting what they did in the tutorial to their own unique use-cases. We've all seen users who end up bending and shoehorning their own work into something that more closely matches what the tutorial did, simply because that's the only way they know how to do it!

By including a learning and understanding section in the manual, you have the best chance to help users get out of "P mode and--most importantly--want to. This is where you take them from surface users who must call tech support at the first instant anything goes wrong to users who become engaged with the product and enjoy co-discovering all the ways in which the product will help them kick ass.

It is this part of the manual where the advertising, marketing, and entertainment folks have something to teach us. It is up to us to get the user/learner motivated to not just Open The Manual, but to want to actually... learn new things. Learning new things usually sucks at first, because it means we have to pass through the phase of frustration, confusion, stupidity, anger, etc. Most humans avoid learning anything that comes with a manual, and will try to do as little as possible to get the bare minimum level of competency.

This won't do if we're actively trying to create and inspire passionate users. We have to make this part of the manual especially enticing, compelling, seductive, entertaining, informative, useful... all without (as many of you warned) making it appear like a shallow sales pitch.

This is also where it really needs to be memorable. It's amazing how much written documentation is meant to be remembered, but anything BUT memorable. Memory is tied to chemistry, and the brain pays attention and records to long-term memory that which the brain finds important. What your conscious mind wants has nothing to do with it--this is about your legacy brain recognizing that this new thing is useful for long-term survival. And let's face it--most of the content in user manuals are far, far, far, from something the brain thinks is important enough to store.

So, we have to trick the brain into thinking that [insert widget A into widget B and configure server C...] is just as important (or life-threatening) as the tiger licking his lips outside your cave. And who better to help us make things stand out than advertisers and marketers? Entertainers and graphic designers? Really Good Storytellers? There are a ton of things that can get past the brain's crap filter, but we have to care enough to create a manual that's brain-friendly, not just user-friendly. And the brain is sooooo much pickier about what it attends to and records.

Knowledge in the Head vs. Knowledge in the World
When we're talking about memory, we have to define what should be remembered, and what should exist Out There. Clearly, the more we can rely on external clues the better, and there's no reason we should have to memorize the reference steps for doing something we'll never do again, but we have to memorize some things. The trick is to figure out what. What will make their experience much better if they just know it?

Don Norman talks about defining the difference between Knowledge in the World (external clues) vs. Knowledge in the Head (things you memorize and "know"). Although he's talking about product design, it applies to manuals and to the relationship between the product and the manual.

4) Cookbook/Recipe
A tutorial is a specific, concrete example. Reference is, well, reference. Learning and understanding is the place where you start to really "get it" on a deeper level. A Cookbook/Recipe section is where a series of steps that might otherwise live in different places in the manual are all brought together under something like a "How do I..." heading. It's kind of like a playlist; it rarely contains fundamentally new information, and simply groups a collection of otherwise separate pieces into one action/goal-based context.

For example, the Nikon D200 can do continuous high-speed shooting, but to do it right, you need to change several different settings on the camera including shooting mode, auto-focus, and metering. The problem is, all the different pieces you need are scattered in different places in the manual, and you have to figure out which you need only if you happen to stumble on each section and put the pieces together in your head. A simple, "How do I take high-speed shots?" or even something like, "How do I take action shots?" that described all the things you need to do... in one place... would be a HUGE help.

If page count is a concern, the cookbook section could simply list the different places in the manual you need to look (e.g. reference page 27, learning page 82, reference page 120, and the last half of the FOO tutorial). And although having to flip pages isn't as user-friendly, it's still way better than leaving it up to chance that the reader will put those pieces together on his own.

5) Start Here
There you are, with the freshly opened box, staring at this huge manual and wondering how long it'll take to just do the One Simple Thing you bought this thing for. A "Start Here" section, which many product manuals include, is a low-intimidation way to help the new user jump in and get something happening. Some early success.

The problem with many Start Here guides is that they are about configuration and set-up and very little else. There's a Grand Canyon between the Start Here and... the rest of the manual. Ideally, the Start Here would go beyond the initial set-up and function as a kind of mini version of the whole manual. And the Start Here makes a great sales piece for the manual itself. "Hmmmm... the Start Here guide was great, so if the rest of the manual is like that, this shouldn't be too painful. Maybe even fun..."

Of course we've all seen Start Here guides that were total bait-and-switch--they do indeed look as if they were produced by an inspired and caring design department, but then the REAL manual looks like it was done by someone who really, really doesn't like you.

One of the best product manual goals we've ever heard is the Electric Rain "User must do something cool in 30 minues" mission. What would it mean to have a goal like that? Would it change anything about the manual?

Change the "F" in RTFM to "Fun"

Not funny, just fun. Fun as in chess. Fun as in writing elegant code. Fun as in doing something you're good at... something that lets you have a high-resolution experience. What would it mean if you asked, "How can we make the manual a fun experience?" Don't jump to the "nobody wants humour in a manual" argument--you don't need "humour" to have fun.

Change the "F" in RTFM to "Flow"

If you can keep the reader/learner/user in a flow state--where the rest of the world drops away--they'll love you. Seriously. And they'll want their friends and family to love you as much as they do. The flow experience is one of the most enjoyable and enriching times in most people's lives, and we all have the chance to help give our users just a little more of this.

There's only so much we can do if the product itself is a flow killer, but the manual can go a long way toward helping the user stay in the moment doing whatever the tool is supposed to help them do. The less they have to stop and refer to the manual (because you helped them remember how the thing works so that the next right step feels natural and intuitive), the more they get to keep doing the do.

Care

About the right thing. Instead of caring what the user/learner thinks about the manual or even the product, care about what the user thinks about himself. Care about how the user feels during--and as a result of--his reading the manual and learning this thing. Care about helping the user kick ass. Care about giving the user an "I Rule!" experience, rather than the default "I Suck" experience we usually get from trying to parse a product manual.

Yes, this is a big "duh", but orientation is everything. When you ask someone to create a manual, be sure they know who and what it's for. Be sure they know that the goal is not simply To Accurately Document The Thing, but to Help The User Kick Ass. This one shift in perspective could change a user's world.

Resources
For learning tips, see my Crash Course in Learning Theory and the many wonderful education/learning blogs including a few of my favorites:
elearnspace
Viki Davis: Cool Cat Teacher Blog
Jay Cross: Internet Time Blog
Cognitive Daily (not technically a learning blog, but so relevant)
Judy Breck's Golden Swamp
elearningpost
Usable Help

and most definitely Darrren "I can't believe the hubris of Kathy Sierra" Barefoot, who knows a ton about this (and a zillion other things too).

Also:
Boxes and Arrows
Solveig's Open Office blog (Solveig's also a pro tech writer)

Posted by Kathy on September 1, 2006 | Permalink

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d83451b44369e200d834611e9869e2

Listed below are links to weblogs that reference How to get users to RTFM:

» A powerful distinction from douggeiger.com
My new bag is tech-writing; as such it behoves me to do it better than most of the competition. I have learned to focus on the philosophy and then fill in the details as I go - rather than learning [Read More]

Tracked on Sep 3, 2006 12:29:02 PM

» Link, Blink, Think - 2006/09/05 from Case by Case: Insights into the World of Enterprise Modeling
Quote of the week All my life, I always wanted to be somebody. Now I see that I should have been more specific. - Jane Wagner Answer to last week's riddle You had to find the missing 3-letter "bridge" that... [Read More]

Tracked on Sep 4, 2006 11:32:11 PM

» RTFM people from Tcritic - Daily T-Shirt Blog
This is genius, I love this shirt, it is so clever. From all-tribes.com, looks like their in europe, but the shipping is pretty reasonable and they seem to have their shit together. On a related note the Communist Party Shirt I blogged about a while ... [Read More]

Tracked on Sep 6, 2006 8:23:25 AM

» Understand Not Memorize from Reflections of a BizDrivenLife
One of the things I keep patting myself in the back was the secret realization during the school days (over 20 years ago) that if I wanted to succeed big time ( or long term) I study to learn, not study to pass the test. After all, when all i... [Read More]

Tracked on Sep 11, 2006 9:27:01 PM

» An outline for a passionate user guide from Exploring Information Design and Development
From "Creating Passionate Users," Kathy Sierra follows up to her "let marketing write the manuals" post. [Read More]

Tracked on Sep 27, 2006 8:46:06 PM

Comments

I wonder how many manuals are tested rather than proof-read? You're seeking to replicate the way a long term friend would explain it to you if they had used the product for many years and you were asking them specific "how do I do this?" type questions. That's easy to expound but hard to do and I think there should be almost as much testing of the manual as of the product.

Posted by: John Dodds | Sep 1, 2006 5:09:12 PM

It wasn't the quote I was looking for, but the sentiment is the same:
‘In a sense, knowledge shrinks as wisdom grows: for details are swallowed up in principles.’Alfred North Whitehead
-------

For the section "Make reading the manual unnecessary", I would point people at the classic text: "The design of everyday things" (http://www.amazon.com/exec/obidos/tg/detail/-/0385267746?v=glance)

-------
Section 'Change the "F" in RTFM to "Flow"'
At the risk of getting all recursive, it would seem that the thing to do when creating a tutorial or start guide would be to use the same criteria for design as we use for our main products - ie. work out what it is that the user is actually trying to achieve. In the case of a tutorial, we're not aiming at the same end-game that we are with our product, but we should be using a criterion like "at the end of this tutorial, what should the user be able to achieve?" (note: that is 'achieve', not 'do' - but then we probably all know that anyway)

------
Learning/Understanding
Is it my imagination, or are some people more comfortable with one or the other?
And if so, is it possible to design teaching material that will satisfy both groups? If so... how?

Posted by: omni | Sep 1, 2006 6:22:25 PM

This is an awesome post (as always). But you only talk about written manuals. How about screencasts? Well, for (online) software at least. A screencast is the coolest way to do a 'Start Here' section - I'm starting to wonder if the whole manual should be made up of a bunch of short screencasts.

Why write about things when you can show them - show the user, customer and especially potential users how they can use it.

But even with screencasts - making the reading of the manual (or watching screencasts!) unnecessary should have the highest priority.

Posted by: Chris Ritke | Sep 1, 2006 7:36:44 PM

Kathy, this is another great post. (I'm struggling to learn my new camera.)

Just imagine when you not only flow with the manual, or not, but can also ask questions or learn from other people's experience. FTM if I can interact with an enthusiastic fellow user.

jay

Posted by: jaycross | Sep 2, 2006 12:43:09 AM

Unfortunately, as you've said, user manuals are often terrible. I will say that I found a great user manual from the Mavis Beacon Teaches Typing Network people because it was organized by task: 1) Setup 2) Teacher Work Area, 3) Orientation for Students, etc. (They are owned by Riverdeep.)

The table of contents was great. I haven't seen a user manual that good in a long time. As for the other software packages I've installed this year including Adobe Web Bundle (all macromedia and adobe software programs), Pinnacle Movie Studio MX, and others, the manual remained unprinted on the CD because after one glance, I could see that it was going to be too much. Adobe did have 2-3 hours of video on a CD which I guess I'll get to eventually. For now, its in the box. When I have a task, I don't have 2 hours to figure out how to do one thing.

As for me, the Riverdeep people are creating a passionate user of their product because my learning curve was accelerated so rapidly by their great user manual. I have one software program I returned because their usermanual was written for a rocket scientist and I didn't want to expend the energy interpreting.

Great post! Thank you for mentioning My teacher blog. I aspire to create passionate students and you inspire me to do that.

Much of what I teach is practical, real world, and based on what I've learned from you.

Posted by: Vicki Davis | Sep 2, 2006 6:24:12 AM

Good post but you stumble on your own cleverness here about learning. You write as if the brain is recording something like an empty container. Controversially you write somewhere else about learning as construction rather than recording and storing. I would say it's much more important what's in your head already regarding the subject rather than what's being stored, as learning is a process of network creation.

What you write about learning section could be embedded into tutorials/cookbooks to make them more compelling.

Posted by: Teemu Arina | Sep 2, 2006 8:02:42 AM

Kathy

Great post.

In many ways, a manual is just a replacement for self-paced training. Or at least it shoould be. I always think it helps to look at training in terms of (K) Knowledge, (S) Skills and (E) Experience.

Obviously, a manual should be stuffed full of knowledge about the product, (let's say a digital camera to continue the theme) and what it can do. And as you point out, the knowledge needs to be organised in a context-logical way so that you can find exactly what you are looking for about the camera when you need it. Most manuals do OK here, although their context-logical organisation often leaves a lot to be desired.

It should also foster skills building by supporting experimentation with the camera. Building skills through experimentation is critical for turning knowledge into working practices. When was the last time that your camera manual had a set of "projects" for you to do to learn something new?

Most importantly, it should be useful over the life of the camera as the user gathers experience using it. We all tend to use only a small percentage of the features of the cameras we own, but when we want to do something new, e.g. to start using infra-red techniques to take photos of virus-diseased plants (a project when I was an undergrad student), the manual should be able to help us too. I suspect most manuals are rapidly forgotten after the initial excitement of learning about your new camera.

Thinking about it again, the importance of these KSA factors show clearly that marketing are simply the wrong people to develop the sort of manuals that we want to and can use over the lifetime of a camera.

But my enthusiasm for using users to guide the manual's development is as strong as it was in my previous post.

Graham Hill
Independent Management Consultant

Posted by: Graham Hill | Sep 2, 2006 12:04:06 PM

Bravo. I agree with everything you have written.

Posted by: Matthew Spiers | Sep 2, 2006 1:53:25 PM

Reference Guide, Tutorial, Learning/Understanding, Cookbook/Recipe, and Start Here.

I find that I often can find a commercial product that does those things when the manual doesn't -- which I find frustrating.

Another thing, make *real* manuals available, not just pdf files -- nothing is worse than trying to do something on screen while paging back and forth with a pdf. I read real print at over a thousand words a minute (at least complex legal briefs at that speed), pdfs and the like are much, much slower.

But a good manual can make the difference between a product I buy an upgrade to and a product I start looking for an alternative to.

e.g. I'm using iomega hardware and software for back-ups for several computers at the house. Is it the best rated? No, I own that, but couldn't figure it out. The iomega stuff was clear, easy and worked. So I've bought more, and the rest is sitting in a bin, ready to be used next time I need it for an upgrade discount or something similar.

I really hope your ideas spread.

Posted by: Stephen M (Ethesis) | Sep 3, 2006 8:53:25 PM

Thanks Kathy,

this post and the previous one just arrived in time: I’m switching to doing training material full-time in the next few weeks. And even though I’m trained as a technical writer, it never hurts to get reminded of the basics and to get a new perspective.

Posted by: Jens | Sep 3, 2006 11:45:33 PM

The concept of understanding v memorising is one that has exercised me for years, although in the slightly tangential field of learning and assessment. The current system of closed book exams loads the dice in favour of the person with the good memory as opposed to the person with the good understanding.

I have long advocated open book/media exams, because being able to remember a thing in an exam situation is no guarantee that you actually know how to make use of the information in the real world. On the other hand, being able to find and apply information - now there's a skill worth having!

I can't remember who it was who said "I keep my knowledge in my friends" but I'm with him/her. I have a very clever colleague who says his first brain is in his head, his second in Google, his third in his blog, and his fourth in the www (or something like that). By contrast, my second brain is in his head! And in the real world, I can access that brain whenever I need to, so why should I try to memorise the things I know he already knows?

Posted by: Karyn Romeis | Sep 4, 2006 1:35:30 AM

Kathy, your terrific post leaves out one element: troubleshooting. I'm speaking as a hasty, impatient user who is reluctant to read ANYTHING if I can instead start to make the thing work. A good troubleshooting section is an essential part of the manual for when the gizmo doesn't magically act the way I think it should. And no, I don't think there is any possible improvement to the rest of the manual that is going to make me read it first. Anne

Posted by: Anne | Sep 4, 2006 6:07:18 AM

This is a fantastic post with lots of excellent ideas.

One potential problem is that any user manual that actually included all five of the suggested sections would be very long. At my company, we have been adding Understanding and Recipe type information to our manuals (which were previously just reference). Feedback from users is positive about the more helpful content, but negative about the increased length. It seems many users are turned off by the length of the manual: they assume that a longer manual means a more difficult learning experience (even though your post seems to suggest that the opposite may be true).

Perhaps the better solution is to approach the five areas as types of content that can be distributed through different channels. The Understanding stuff that helps you grasp the mental model might best be achieved through short videos like those at http://www.2minuteexplainer.com/.

My other concern is with the Tutorial section. You write that, "The deal-killer in a tutorial is when a crucial piece--however small--is left out." Including highly detailed step-by-step instructions seems to go against Minimalist principles for documentation, where users should be given some direction but encouraged to explore the product itself (and provided with the information needed to recover from errors -- which is principally covered in the Understanding section, IMO).

Posted by: Jeff | Sep 5, 2006 3:22:24 PM

Great article!

I think, you are in line with the work of John Carroll and colleagues. They did much research on manuals in the eighties. The first invented "guided exploration cards" and afterwards the "minimal manual". Minimal manuals have the following attributes:
- Superfluos text is avoided (no "Welcome to the text processing software" section).
- It is task-oriented. All functions are described in the context of a real task.
- It is modular. Each module describes how to solve a task (much like a tutorial).
- It contains hints about error-recovery.

I think that work is old - but up-to-date!

* Carroll, J. M., Smith-Kerker, P. L., Ford, J. R. & Mazur-Rimetz, S. A. (1987). The minimal manual. Human-Computer Interaction, 3, 123–153.

* Lazonder, A. W. & van der Meij, H. (1993). The minimal manual: is less really more? International Journal of Man–Machine Studies, 39, 729–752.

Greetings from Germany!

Christian

Posted by: Christian Spannagel | Sep 8, 2006 12:41:44 PM

I always say that if I have to read the instructions then I am not smart enough to use the product and should not buy it.

Posted by: Teresa Boardman | Sep 10, 2006 9:07:58 AM

BEST documentation I have come across for a software package - Oracle! Pretty much hits ALL the points above. Check it out http://www.oracle.com/pls/db102/portal.portal_db?selected=3

Posted by: Glenn | Sep 12, 2006 12:05:21 PM

Slightly OT, but if you're wondering about your D200 (excellent camera, by the way), I wholeheartedly recommend that you take a half an hour or so and read Ken's user guide: http://www.kenrockwell.com/nikon/d200/users-guide/index.htm . It may just be the manual you were hoping for, or at least a simulation of part of it.

Posted by: Richard | Sep 15, 2006 4:25:23 AM

is this moderated?

Posted by: me | Nov 7, 2006 5:53:08 PM

Posted by: vawet | Aug 16, 2007 1:07:55 AM

Posted by: zvawe | Aug 16, 2007 1:08:20 AM

Posted by: ewtajp | Aug 16, 2007 1:08:42 AM

40 inch plus -
all reality pass -
all sites access -
ass parade -
ball honeys -
bangbros network -
big mouthfuls -
big tit patrol -
big tits round asses -
brandi belle -
busty adventures -
cam crush -
horny spanish flies -
i spy cameltoe -
lesbian teen hunter -
mega cock cravers -
mike in brazil -
milf next door -
monsters of cock -
mr big dicks hot chicks -
mr cameltoe -
mr chews asian beaver -
ox pass -
panties and fannies -
please bang my wife -
real orgasms -
round and brown -
team squirt -
teeny bopper club -
vip crew -

round and brown -
see her squirt -
seehersquirt -
street blowjobs -
streetblowjobs -
taylor bow -
taylorbow -
teeny bopper club -
big cock addiction -
big cock teen addiction -
the big swallow -
thebigswallow -
bikini contest porn -
blind date bangers -
college teens book bang -
dangerous dongs -
euro sex parties -
tinys black adventures -
tinysblackadventures -
tongues and toys -
tranny surprise -
trannysurprise -
tug jobs -
tugjobs -
vip crew -
vipcrew -
we live together -
welivetogether -
xxx proposal -
xxxproposal -

all star porn girls -
allstarporngirls -
big cock teen addiction -
bigcockteenaddiction -
big league facials -
bigleaguefacials -
big tit patrol -
bigtitpatrol -
casting couch teens -
castingcouchteens -
college teens book bang -
collegeteensbookbang -
giants black meat white treat -
giantsblackmeatwhitetreat -
horny spanish flies -
hornyspanishflies -
i spy camel toe -
ispycameltoe -
pimp my black teen -
pimpmyblackteen -
please bang my wife -
pleasebangmywife -
reality pass plus -
realitypassplus -
see her squirt -
seehersquirt -
teeny bopper club -
teenybopperclub -
the big swallow -
thebigswallow -
8th street latinas -
8thstreetlatinas -
all reality pass -
allrealitypass -
bare foot maniacs -
barefootmaniacs -
bikini contest porn -
bikinicontestporn -
blind date bangers -
blinddatebangers -
bus stop whores -
busstopwhores -
captain stabbin -
captainstabbin -
coeds need cash -
coedsneedcash -
mikes apartment -
mikesapartment -
milf hunter -
milfhunter -
milf next door -
milfnextdoor -
mr chews asian beaver -
mrchewsasianbeaver -
pump that ass -
pumpthatass -
tinys black adventures -
tinysblackadventures -
xxx proposal -
xxxproposal -

40 inch plus -
40inchplus -
big naturals -
bignaturals -
boys first time -
boysfirsttime -
cum fiesta -
cumfiesta -
cum girls -
cumgirls -
dangerous dongs -
dangerousdongs -
euro sex parties -
eurosexparties -
first time auditions -
firsttimeauditions -
in the vip -
inthevip -
mike in brazil -
mikeinbrazil -
round and brown -
roundandbrown -
street blowjobs -
streetblowjobs -
tranny surprise -
trannysurprise -
vip crew -
vipcrew -
we live together -
welivetogether -
all sites access -
allsitesaccess -
ass parade -
assparade -
ball honeys -
ballhoneys -
bangbros network -
bangbrosnetwork -
big ass adventure -
bigassadventure -
big mouthfuls -
bigmouthfuls -
big tits round asses -
bigtitsroundasses -
busty adventures -
bustyadventures -
cam crush -
camcrush -
milf lessons -
milflessons -
monsters of cock -
monstersofcock -
mr cameltoe -
mrcameltoe -
public invasion -
publicinvasion -
taylor bow -
taylorbow -
tug jobs -
tugjobs -

Posted by: aetw | Aug 16, 2007 1:09:04 AM

The comments to this entry are closed.

Creating Passionate Users

About

Past favorites