Posted on
by
Makin’ Bac’n: From Idea to Web Startup in 21 days
Scott Kveton & Jason Glaspey
This was my favorite talk of the WebVisions 2009 conference. Fun, interesting, applicable.
Top three highlights
  • Using a combination of open source and free tools (detailed below), they were to go from domain name to full website in 2 weeks, including fully functional store and checkout process.
  • Their operations costs for all web/phone infrastructure are $84/month
  • They’re having lots of fun, and people of all kinds are contributing just for the fun of it, like the Playboy bunny who took photos of herself wearing an “I love bacon” T-shirt.
Full Notes
  • Started blog called bacondesk
  • My first online order of bacon from BaconFreak.com
    • “Bacon is like meat candy” ™
    • He had an affiliate program
    • It was clear they were getting about 1,000 orders a week. At about $100 an order, it was clear this was a business
  • Decided to have a Bacon Meetup
    • Listed on Upcoming.com
  • At Christmas, everybody gave me bacon gifts
  • 3 guys…
    • We’re going to make money from day 1
    • We’re going to launch in a month
    • We’re going to have fun
  • Confirmed plans between the week of Christmas and new year’s.
  • Wanted to launch by Master Bacon, on January 21st.
    • Forced themselves into a 3 week process
    • Bacn.com (the “o” is really, really expensive)
  • Recipes drive organic traffic and sales
  • Bacon is a shelf stable product when cured. Then shipping isn’t a problem.
  • Where are we going to get our bacon, and what’s it going to be?
  • Decided on 3 suppliers… the suppliers were saying “we’ve got people who have moved out of our distribution area, and now they want bacon”
  • Have instructional cards on how to cook and store bacon
  • Fulfillment isn’t that tough
  • U.S. Postal service gives you free boxes. Just go to their website, and they’ll send you hundreds of boxes to your house.
  • Website
    • Used a basic content management system, plugged into Google checkout. Do 3-4 hours of work each evening, plus Saturdays.
    • Hired local guy to do design.
    • Didn’t get design until 2 days before the launch
    • Fully functional website in 5 days
  • Twirl.cc: is a url shortener. Leveraged the code to do bacn.me to create a bacon url shortener. Can impose a big bacon picture across the website. Picked up mashables story, lots of promotion.
  • Blog lets them take bacon related content (have you seen the bacon 747?) and put it on the site really quickly, drives more and more organic traffic.
  • Used twitter to solicit people for photo shoot
    • Made bacon tshirts, gave shirts plus PBR away to people whose photos they could use
  • Budget: To get to launch…buy domain name, plus everything else, was $15,000. the biggest chunk was the domain name. Bacn.com was about $5,000. Bacon.com was $750,000.
  • Used all open source for everything…
    • Djenko
    • WordPress
    • IntenseDebate…great commenting system for WordPress
    • UserVoice: really easy to get feedback. Don’t need to login.
      • Found out really quick: bacon lovers are really big dudes. Offer 4x and 5x sizes.
  • Total operating cost is about $80/month: fax, hosting bill, etc.
  • Cool group bacon photo was actually a photoshopped picture…all people wearing bacon shirts lined up on wall. Pictures were taken individually, then photoshopped together.
  • T-shirts are their biggest product. They licensed the design of existing bacon t-shirts from individuals / small other businesses.
  • They don’t do any Google adwords revenue, instead they do all affiliate revenue with sites that are bacon focused. They offer 10%, but it is only on purchases, not clicks or views.
  • The vast majority of users don’t like to be referred to another website for payment. So Google Checkout is a major deterent. Having to sign up for a Google account is a major turnoff. But didn’t spend time up front to delay launch. Could launch quickly using Google checkout.
  • Having their own product…
    • Bacn sausage
    • Bacn hamburger
    • They are the only online distributor for these products
  • Q: Did you need to get legal support?
    • A: The company runs as an LLC. The company never opens or handles the bacon. They don’t need to worry about handling the bacon. There aren’t a lot of legal ramifications, other than those that are the usual ones.
  • Q: How do you manage inventory?
    • A: Turnaround from suppliers is just a couple of days. So only hold a little inventory. USPS has priority mail…can ship bacon anywhere in U.S. for 2 days for just $9.80.
  • Q: How did you find out that people didn’t like Google checkout?
    • A: From UserVoice. Someone mentioned it, so then offered it as a choice people could pick “Would like other options for checkout”, surprised by number of votes for it.
    • Use crazy egg to make heatmaps of site
  • Comprehensive list of equipment
    • Craigslist for equipment
    • Friends for models
    • IntenseDebates for comments
    • WordPress for blog
    • GoogleCheckout
    • Endicia for postage: prints label and postage all together. Works with custom label design.
    • UserVoice for feedback.
    • Mimeo for video
    • Django content management
      • Even does packing slips and manages inventory
    • Mycorporation.com to incorporate. Used LLC, but would do it again as a C corp.
  • Use google adword keyword service to assess market size per month
  • Use videos to do education: how to make bacon with a grill bacon. Has a splash page, but it isn’t primarily an advertisement.

Posted on
by

Tac Anderson recently wrote that one of the keys to increasing blog readership is to post 3 times a day or more. So how does one find the time for this level of participation? Tac has a few good tips on reducing the time involved. But thinking about it made me remember a a blog entry I wrote in 2007 in respond to the question of “How does a dad with three preschool age kids and a full-time job find the time to post?” I think these ideas apply not only to blogging, but also to any form of social media participation, whether it is Twitter, discussion forums, or anything else. The trick is is that social media shouldn’t be another extra hour or two on your day, but it should in some way replace or complement activities you are already doing.

After a friend recently posted about trying to find the time to blog, I got to thinking: How do I find the time to blog?

After some thinking, I came up with a few principles. In some ways, I’m the worst person to give advice, because my frequency of posting is terrible compared to any decent blogger. On the other hand, I’m the father of 3 children under the age of 4 (doing attachment parenting no less) and I work full time, so if I can find the time to post, then anyone can.

First, make sure that you know why you’re blogging. If you don’t know, the issue may not be a lack of time, but a lack of clarity or motivation. Rebecca Blood’s articles and references on blogging and book, The Weblog Handbook, are useful if you are just finding your voice. Once you know why you’re blogging, the following tips may help you find the time to actually get those blog posts going.

  1. Repurpose: If you are an information worker of any kind or a student, you’re probably already doing research, generating reports, analyzing information. If you can find a way to take your initial work and repurpose it for use in two places, then you can generate content for your blog with only a little additional work. Be aware that depending on your employment contract, work policy, and employment laws, there could be all sorts of issues about who owns your work, the confidentiality of your work, and a slew of other issues. On the other hand, judging from recent Wired magazine articles, many companies are now opening up and encouraging transparency in all its forms, including blogging. Research this ahead of time so that you’re doing the correct legal and ethical thing.
  2. Substitute: You probably already bookmark websites, send emails about interesting articles or thoughts to friends and you may even write the occasional letter or holiday newsletter to family and friends. All of these are material that could be published on your blog. When you publish your bookmarks on your blog, not only do you benefit, but so do your readers. Blog instead of bookmarking, blog instead of emailing, blog instead of writing a letter, blog instead of publishing.
  3. Get creative: Take the creativity advice of Gifford Pinchot III, and always keep index cards or a quarto on you. The time when you have a creative idea to post is most likely not when you are in front of a computer. So grab that handy pen and paper, outline your post, and it’ll be quick and easy to post when you next sit in front of a computer.
  4. Scratch an itch: My own blog originated from my desire to keep track of books that I had read. As I borrowed more books to read (instead of buying), I found it difficult to keep track of books and authors I liked. That make it difficult to decide what books to read next. I could have simply kept a lot on my computer, but how much more fun to share it with everyone. Now using my blog helps me do something I already wanted to do, and that’s true even if no one ever reads it. The epilogue to MIT’s open source book has an interesting discussion of the open source principle applied to writing:
    “While every writer will tell you they write for themselves, this is more a statement of principle than an actual description of process—a piece of writing, whether a textbook or a novel, needs an audience to succeed. A programmer who claims to writes code for him or herself, on the other hand, is often telling the literal truth: “This tool is for me to use. Additional users are nice, but not necessary.”

    If you can manage to write and simultaneously create value for yourself through your writing, then you have a double motivation to write.

  5. Eliminate barriers: If posting on your blog requires you to jump over a dozen hurdles, you won’t do it. Eliminate barriers, and you’ll find that even five minutes can be enough to start an interesting post. Use simple blog software with a WYSIWYG editor so you aren’t spending time messing with HTML. Keep a browser window open to your blog editor at all times, so it is always easy to get to. Start a post, even if you won’t have time to finish it now, and keep the edit window open. You’ll come back to it later when you do have time.
  6. Have modest expectations: I’m sure I could have made this a “top ten” list, but seven items came easily, and still fulfilled the purpose of the post.
  7. Set a goal: E set the goal of posting at least once a week, and while she may have missed one week somewhere in there, for the last two months, her blog has had plenty of fresh, interesting articles. Way to go!

Update (4/12/2007): Here are several other resources about finding or making the time to blog:

Posted on
by

Research from Stanford School of Business Professor Itamar Simonson and coauthor Chezy Ofir at Hebrew University in Jerusalem, points out that telling customers they will be surveyed, or asking them about their expectations ahead of time creates significantly more negative feedback. A quote from the article:

The researchers found that people who expect to evaluate are decidedly more negative. They also discovered that merely asking people to state their expectations before they receive a service made people morenegative—even though their predispositions may have been quite positive. For example, people who are asked if they think they will like a movie before seeing it will be statistically more negative than people who were never asked that question.
Simonson and Ofir studied the responses of customers who had called for service at a major computer hardware and software company. The researchers divided the customers into four groups. Participants in the first group were told a technician would service their problems and that they would subsequently be asked about the service, such as whether the tech was on time, whether the employee was polite, and whether he or she solved the problem. A second group was not told there would be an evaluation, but the customers were asked to state their expectations, such as how long they thought it would take for a tech to arrive. A third group was told both: to state their expectations and to expect a survey. Members of a control group knew nothing but were later polled.
The result: People who expected to evaluate were significantly more negative than members of the control group. The same was true of the group asked to state their expectations ahead of time. Interestingly, the group that was the most dissatisfied was the one that was asked their expectations and also warned about a survey.

This has serious implications for customer satisfaction surveys, but also for product research groups. Showing product prototypes to customers in a research setting is a context in which participants will frequently both be asked about their expectations and expect a survey. The effect can be research that “finds” problems that aren’t really problems:

The researchers warn that while marketers must stay on top of customer desires and complaints, they must also be aware of the effects the mere expectation of filling out a survey can have on how customers view their experience. “It may not be realistic,” says Simonson. “They may be chronically more negative, pointing out problems that are not problems to the average consumer,” he says. “You want people who are representative of the marketplace.”

This suggests that if you have any opportunity for analysis that doesn’t rely on surveys, but instead relies on behavior, the results are likely to be more accurate. Social media buzz, word of mouth, and collective intelligence applications based on behavior may all be more accurate than survey responses.

Posted on
by

I attended the May 2009 CHIFOO presentation today on the subject of what happens when design meets Agile development processes. Here are my rough notes from the meeting.

The speakers were:
Lane Halley (lane at cooper dot com)
Cooper
principal design consultant, and teacher at Cooper U
Jeff Patton (patton at acm dot org)
designing and developing using Agile
2007 award winner for Agile Alliance’s award
If you are familiar with Agile, you may want to skip to the 2nd section.
  • What is Agile?
    • Common myths: no planning, no up front design, no documentation, no handoff, self-managed teams, a fad that will go away soon, undisciplined, only works with small teams, an excuse for poor quality.
    • Software development has always been difficult.
      • There’s a long history. Standish Group’s Chaos reports still report most projects fail or finish challenged.
      • Agile’s strongest themes in response to years of failure in death march projects following waterfall-style processes.
    • Agile ideas germinated during the 1980s and 1990s.
      • 1986: Brook’s “No Silver Bullet” describes iterative and incremental development.
      • 1995: Schwaber and Sutherland document Scrum
      • 1997: Cockburn describes Crystal Methodologies.
      • 2000: Beck publishes Extreme Programming (formerly at Tecktronics)
    • These “lightweight” development processes had an image problem. à People with tough problems wanted strong processes, not lightweight processes.
    • Around this time, we start to see the design community and the agile community start to butt heads.
    • The term “agile” coined by lightweight process reps
      • Feb 2001: Agile Manifesto created, a common set of values among methodologies. Created by 17 representatives of different lightweight processes.
      • Since then, attracted other groups, such as lean development.
    • Manifesto for Agile Development
      • Link to it: http://www.agilemanifesto.org
      • Four values
        • Individuals and interactions over processes and tools
        • Working software over comprehensive documentation
        • Customer collaboration over contract negotiation
        • Responding to change over following a plan
      • “While there is value in the itoms on the right, we value the items on the left more.
      • For some, these were mom and apple pie statements.
      • See also the 12 principles in the manifesto.
    • Agile values motivate agile process
    • Agile success is measured through value alignment, not process compliance.
      • You can follow almost any process, and it can be agile, if your core values are agile.
    • What has emerged is a common process framework
    • Today Scrum dominates as the simple agile process framework of choice
    • Scrum describes only 3 simple roles:
      • The Product Owner: Describes that the product should be, and is ultimately responsible for its success
      • The Team: Everyone responsible for constructing the product
      • The Scrum Master: Makes sure the process is working, and all roles are collaborating effectively. Not responsible for making the product finish on time (that’s the product owner and the team), they just focus on making sure the process is working smoothly.
    • Scrum process framework (sometimes called the snowman diagram)
      • Product owner identified a potential product idea
      • Product owner supported by others creates the product backlog
      • In sprint planning the product owner and team plan the next sprint or iteration
      • The team works towards the iteration/sprint goals in a 1-4 week timebox
      • The team keeps progress visible with burndown charts and task boards
      • In the daily planning meeting / daily scrum, the team synchronizes daily in a short morning standup meeting
      • In a product review the product owner and team gather to review the results of the last sprint and reflect on how the product and process could improve
    • Today’s agile processes mix and match techniques from many agile methods: user stories, product backlog, planning poker, burndown chart, task board, test driven development, refactoring.
    • The scrum mantra “inspect and adapt” applies to the product and the process.
    • Agile process is tailored to the organization and team within the organization
      • Venture funded startup versus Large internal IT organization.
      • Mature consumer product companies versus venture startups.
      • Small collocated teams versus large distributed teams.
      • Everyone implements differently. Each implementation is a specific vertical implementation of process that works (or is intended to work) for the specific business environment. Since adaption is a key value, even if they started with the same process, the processes would evolve to become tailored.
  • Bringing UCD (user centered design) design techniques and Agile together
    • Some aspects of Agile cause frustration
      • Agile lacks tools to define business and customer needs and measure product success
      • An agile “product owner” may not accurately represent the user needs. It’s hard for one person to represent all the needs.
      • It’s hard to see the “big picture” when you’re building incrementally
      • Finding the right level of design documentation
(WEH: Isn’t it just common sense that if you see a gap, then you create a solution to that gap?)
    • There are best practices to overcome all these problems
    • Common ground: Interaction designers share many values with agile practioners:
      • Desire to build successful products
      • Focus on providing what people value
      • “user stories” instead of “features”.
    • Agile work styles have many benefits
      • Agile is about shared responsibility
      • Agile is about effective communication: you write things down to achieve clarity and because it will be useful, not just for the sake of writing documentation. [WEH: Using a wiki encourages this behavior.]
      • Agile helps you fail quickly
      • Agile is a more humane way to work: everything is done at a sustainable pace. Have retrospective, measure the rate at which work can happen.
    • Agile processes lead to good partnerships
      • No edicts: a user story is an invitation to a conversation, not an edict of what will happen.
      • …
    • Two different sets of expertise when Interaction Designer and Developers get together
      • Ingrid, interaction designer
        • HCI degree
        • Works on paper
      • Dave, Developer
        • CS degree
        • Ruby, Pivotal Tracker
      • Ingrid: focuses on the probable: what might we do?
      • Dave: focuses on the possible: what can be done?
      • Designer and developer need to be able to talk about both the big picture as well as the nitty details
    • If you’re a designer
      • Be a facilitator: Help people collaborate and evolve ideas in the room together. Don’t go off and develop a vision on your own. You need to bring everyone along with you.
      • Have conversations, not directives
      • Use visual communication: More time on whiteboards, sticky notes, paper. Less time on heavy weight design documents.
      • Help the team understand user needs, behaviors, and attitudes. You are the specialist in this, so you need to help other people. Again, not dictate the solution, but give them the tools to arrive at the solution themselves.
      • Question from audience: when can you challenge the developer?
        • Answer: you can challenge on what is possible. Your role is to prioritize what is really important. Where do we need to push the development boundary of what is possible, versus we can we live with it?
    • If you’re a developer
      • You are not the user. (Unless you are those guys at 37 signals and what you are building is a tool that you will use yourself.) We need to have a shared understanding that it is not us, and a shared understanding of who it is, not an idiosyncratic personal view of who the user might be.
      • Look for the common case
      • Learn design principles and patterns
      • Ask the questions “who is this for?” and “what problem does this solve?”
    • Changing role of interaction design
      • Before:
        • interaction design is a specialized role
        • interaction design done at the beginning of the process
      • With agile:
        • Interaction design integrated in agile process
        • Interaction designers participate in new ways
          • Front end UI development alongside developers
          • Work with product owner to articulate and validate the product concept
        • More frequently, seeing interaction designers as a hybrid role…
          • Interaction designers become product owners
          • Interaction designers become coders who implement the UI front end
    • The role of the interaction designer
      • Facilitate brainstorm sessions where everyone on the team can contribute ideas and jointly understand the implications of design decisions
      • Quickly iterate through different design solutions as low-fidelity sketches to help developers save time and make good decisions
      • Be the team member responsible for user experience.
  • Patterns for Success
    • Put UX in the navigator’s seat
      • UX is an important part of the product owner team
      • Become a design facilitator
    • Do just enough research and design to get started
      • Research, model, and design up front, but lightly
      • Plan for continual ongoing user contact for research and validation
      • (Prioritize the target users: “of the 12 users we eventually want to target, we’ll start with these 3”
    • Focus on the big picture
      • Identify and communicate the overall story of the interface so you can work on smaller parts while maintaining context
      • Be able to answer the questions of “Why are we in business?”, “What is this software for?” Be able to describe the context. What does this product do, and how does it do it, so that the users can accomplish what they need to accomplish? They take just enough time to see, they evolve it as they see more, and they help everyone else to see it.
      • Designers need to be able to operate with a low-fidelity big picture
    • Use good UX practices to support product development
      • Use parallel track development to stay ahead and follow behind
      • Buy design time with complex engineering stories (give the developers some tough problems to solve, so that the designers have time to work on other stuff. It’s balancing of resources, not just narrow focused on business priority.
      • Use RITE to iterate UI before development (you can iterate UI with paper prototypes, mock up tools, etc – so that what goes into development is known good UI.)
      • Prototype in low fidelity. Use paper if you can. Use code if you need to. Use the right level of fidelity. Start low, and move high only as needed.
      • Treat prototype as specification. Don’t add more documentation for the sake of documentation. Have a discussion about the prototype if needed.
    • Engage users continuously
      • Cultivate a user group for continuous feedback.
        • A pool of people I can go too, to show prototypes, get feedback. My pool is big enough that I don’t go back to the same person all the time. I should cycle through so that I am not testing with the same people, not more often than every couple of months.
      • Commit to regularly visiting, listening to, and collaborating with your users.
      • Leverage user time for multiple activities.
        • Example of bad case: you may have user research people who are different from your design people. This should be merged. Leverage the time to its fullest extent.
  • Questions and Answer session
    • What is the ideal seating arrangement?
      • Ambient communication is very important because there is less formal communication. The people who work together should sit together. Information flow is a property to be tuned. Information moves like heat through the room. Organize people in pods, or in big large tables.
    • Any successful teams that are not collocated?
      • Thoughtworks has development in Hong Kong and US. They rotate staff between locations on a regular basis. A couple of weeks each month.
      • Cross country Healthcare: Brought team of engineers from India into the US for a year. Colocated India and Florida engineers for a year, then moved the engineers back.
      • Have constant phone connections.
      • Have video cameras.
    • How do we engage with clients (we’re an agency)
      • Ideally you would want the client to participate to the extent that they can. Join you at your location.
      • Look at “innovation games”, a process to facilitate this kind of involvement.
      • Develop with the client a communication plan: how much do we communicate, what are the checkpoints?
        • But how far do you invite them in? You are making them breakfast, they don’t want to see you making sausage. (there will be some hard tradeoffs.)
        • But the more you engage, the more they want to get involved. The more they get involved, the more changes they make. In the end, they will usually be happy with something simpler and less expensive to build.

Posted on
by

Here’s a great article by Malcolm Gladwell on How David Beats Goliath. A fascinating look at how effort and unconvential strategy – questioning the rules and assumptions – can lead to incredible results.

When Vivek Ranadivé decided to coach his daughter Anjali’s basketball team, he settled on two principles. The first was that he would never raise his voice. This was National Junior Basketball—the Little League of basketball. The team was made up mostly of twelve-year-olds, and twelve-year-olds, he knew from experience, did not respond well to shouting. He would conduct business on the basketball court, he decided, the same way he conducted business at his software firm. He would speak calmly and softly, and convince the girls of the wisdom of his approach with appeals to reason and common sense.
The second principle was more important. Ranadivé was puzzled by the way Americans played basketball. He is from Mumbai. He grew up with cricket and soccer. He would never forget the first time he saw a basketball game. He thought it was mindless. Team A would score and then immediately retreat to its own end of the court. Team B would inbound the ball and dribble it into Team A’s end, where Team A was patiently waiting. Then the process would reverse itself. A basketball court was ninety-four feet long. But most of the time a team defended only about twenty-four feet of that, conceding the other seventy feet. Occasionally, teams would play a full-court press—that is, they would contest their opponent’s attempt to advance the ball up the court. But they would do it for only a few minutes at a time. It was as if there were a kind of conspiracy in the basketball world about the way the game ought to be played, and Ranadivé thought that that conspiracy had the effect of widening the gap between good teams and weak teams. Good teams, after all, had players who were tall and could dribble and shoot well; they could crisply execute their carefully prepared plays in their opponent’s end. Why, then, did weak teams play in a way that made it easy for good teams to do the very things that made them so good?

Posted on
by

Even the best social media site or wizz-bang collective intelligence Web 2.0 application has to adhere to some basic website usability principles. Here are 25 website usability points to inspect your site against. Very useful!

A few examples:

Section III. Navigation

Once people generally know who you are and what you do, they need clear paths to the content that interests them. Information architecture is a huge topic, but these points cover some of the basics.
12. Main Navigation Is Easily Identifiable
Almost every site on the web has had a main menu since the first browsers came on the market. Make your main navigation easy to find, read, and use. If you have two or more navigation areas, make it clear why they’re different.
13. Navigation Labels Are Clear & Concise
Don’t say “Communicate Online With Our Team” when “Contact Us” will do just fine. Your main navigation should be short, to the point, and easy for mere mortals to grasp.

Posted on
by

WhatWouldGoogleDoHere’s another piece to reinforce customer experimentation (doing stuff live with customers) versus customer research (doing focus groups, surveys, etc). This is from Jeff Jarvis in his book What Would Google Do?

Google vice president Marissa Mayer has said that Google is constantly trying to anticipate and interpret our desires so it can predict what we are going to do–our intent. It does that by watching our every move. When her team wonders whether a page should be this color or that, they don’t make the decision themselves, nor do they hold a focus group. They put both colors on the web in an A/B test that measures which yields better usage. “We’ll be able to scientifically and mathematically provide which one users seem to be responding to better,” Mayer told students at Stanford, demonstrating an engineer’s faith in numbers”.

Reblog this post [with Zemanta]

Posted on
by

I frequently find in my job that I’m the proponent for lots of  iteration and learning. Gifford Pinchot terms this “early learning beats better planning”. By comparison, many folks I work with emphasize getting it right the first time.

While I have nothing wrong with getting it right the first time (if you know what right is, if you have some way to test it, if it doesn’t delay you in getting something out), the problem with it as an approach is that practicioners don’t emphasize closed-loop learning and improvement the way that a “launch and learn” practioner would. So if it isn’t right the first time for whatever reason, you don’t have the processes set up and in place to monitor that, learn from it, and respond rapidly.
I came across an interesting anecdote (via Chanpory Rith, via Trent) from Art and Fear on early learning verus better planning:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Posted on
by

OK, so I had previously found a summary of Kathy Sierra’s 2007 SXSW talk, and was excited to see that she spoke about ensuring the humanness of our help documents, FAQ, and other support stuff.

But after a little more digging, I found some great stuff that she wrote earlier that includes primary research citations. (This is the kind of stuff that’s good to have when you have to defend these ideas inside a big corporation.)
In 2005 Kathy wrote Conversational writing kicks formal writing’s ass. Some highlights from that include:

A study from the Journal of Educational Psychology, issue 93 (from 2000), looked at the difference in effectiveness between formal vs. informal style in learning. In their studies, the researchers (Roxana Moreno and Richard Mayer) looked at computer-based education on botany and lightning formation and “compared versions in which the words were in formal style with versions in which the words were in conversational style.”
Their conclusion was:
“In five out of five studies, students who learned with personalized text performed better on subsequent transfer tests than students who learned with formal text. Overall, participants in the personalized group produced between 20 to 46 percent more solutions to transfer problems than the formal group.”
They mention other related, complimentary studies including:
“… people read a story differently and remember different elements when the author writes in the first person (from the “I/we” point of view) than when the author writes in the third person (he, she, it, or they). (Graesser, Bowers, Olde, and Pomeroy, 1999). Research summarized by Reeves and Nass (1996) shows that, under the right circumstances, people “treat computers like real people.”
So one of the theories on why speaking directly to the user is more effective than a more formal lecture tone is that the user’s brain thinks it’s in a conversation, and therefore has to pay more attention to hold up its end! Sure, your brain intellectually knows it isn’t having a face-to-face conversation, but at some level, your brain wakes up when its being talked with as opposed to talked at. And the word “you” can sometimes make all the difference.

And then in 2007 she wrote Your user’s brain wants a conversation. An excerpt from that post:

Which would you prefer to listen to–a dry formal lecture or a stimulating dinner party conversation?
Which would you prefer to read–a formal academic text book or an engaging novel?
When I pose this question to authors or instructors, I usually hear, “You think the obvious answer is the dinner party and the novel, but it isn’t that simple.”
Followed by, “It all depends on the context. I’d much rather hear a dry formal lecture on something I’m deeply interested in than listen to inane dinner party conversation about Ashlee’s lip-syncing blunder.”
But here’s what’s weird–your brain wants to pay more attention to the party conversation than the formal lecture regardless of your personal interest in the topic.
Because it’s a conversation.
And when your brain thinks it’s part of a conversation, it thinks it has to pay attention… to hold up its end. You’ve felt this, of course. How many times have you sat in a lecture you really needed and wanted to pay attention to, but still found it hard to stay focused? Or how about the book you can’t seem to stay awake for… finding yourself reading the same paragraph over and over because you keep tuning out–despite your best effort to stay with it?
But here’s the coolest (and for me, the most fascinating) part of all this:
When you lecture or write using conversational language, your user’s brain thinks it’s in a REAL conversation!

This is some very cool stuff! Anyone have any success stories to share in making the change to conversational language in technical support content?