Saving the world

Be sure to check out our application, join some causes, spread the word and help save the world: causes.com.

We're Hiring!

Check out some of the listings in our jobs section.

Grab our feed

Stay up to date with the Causes engineering team by subscribing to our feed.

Feedback Loops

"Just give people a feedback loop and they will relentlessly optimize."

I heard this quote from a designer at RailsConf 2008, in response to this story about an experiment on feedback and energy consumption.

A number of high-energy-consumption homes were chosen, and in each one the experimenters installed a meter connected to a large colored light. The light glowed brighter when the home was using more energy, and more dimly when the home was using less energy.

With no other interference at all, those high-consumption homes all quickly reduced their energy consumption to a more typical profile.

The mere presence of feedback resulted in significant gains, even without any information about how to improve energy efficiency or external incentive to do so.

What makes this process more successful? There are a couple of core principles:

  1. Minimize delay. The shorter the delay between action and result, the easier it is to learn from it.
  2. Small increments. The smaller the change required to see a difference, the easier it is to experiment, and the less likely it is to create thrashing and frustration.

We have found several times in the past that when a feature is not doing as well as we think it should, it can be improved by refining the feedback loops around it.

As an example, in our MySpace product, we added immediate feedback about successful recruitments on a user’s homepage so they didn’t have to re-enter the application to see how their invitations were doing. This dramatically increased the number of repeat visits to the inviter page.

Systematically performing analysis on the feedback loops of all of our features is not something we do yet. My instinct is that we could use more of it, but it remains to be seen for us where the time/energy tradeoffs lie between doing so and spending that time on more testing or developing new features.

Leave a Reply