Archive for July, 2011

Get it wrong the “fist time”

July 17, 2011

One year ago, Aza Raskin, the Creative Lead for FireFox posted a fantastic presentation on prototyping.  His main points were the following:

0: You are going to get it wrong the first time. 1: Try to finish the first artifact in a day. 2: Iterate fast. Dogfootd much. 3: You will change the problem you are trying to solve. 4: Plan to throw it away.

Aza's prototyping tips from 1 year ago.

It’s encouraging to see that he is following his own advice– eight months ago, his seven points read like this in his blog post:

  1. Your first try will be wrong. Budget and design for it.
  2. Aim to finish a usable artifact in a day. This helps you focus and scope.
  3. You are making a touchable sketch. Do not fill in all the lines.
  4. You are iterating your solution as well as your understanding of the problem.
  5. Treat your code as throw-away, but be ready to refactor.
  6. Borrow liberally.
  7. Tell a story with your prototype. It isn’t just a set of features.

This week I saw Aza give an updated version of this same presentation, and he’s continuing to iterate:

1: You are going to get it wrong the first time. 2: Try to finish the first artifact in a day. 3: Iterate fast. Dogfood much. 4: It's a sketch, dont' fill in all the lines. 5: You will change the problem you are trying to solve. 6: Plan to throw it away. 7: Steal it.

Aza's prototyping tips from one week ago.

A few people probably pointed out that he has two #5’s and that he wrote “fist time” instead of “first time”, so there are bound to be future iterations of this same presentation.

However, perhaps he shouldn’t correct it– “fist time” is an appropriate mistake because it’s advisable to make early prototypes in a rough and brutish way 🙂  That leads to the first #5 above where the creator will change the problem they are trying to solve only after testing his/her assumptions through the first prototype.  Full circle.

How this Applies to Us

As a team of four, we have our roots in rapid prototyping and short design-build iterations.  But it’s always helpful to get suggestions on how to do it better, especially from experts like Aza.  Often one person on our team pushes us to “eat our own dogfood” when the rest of us need a reminder.  Using our own deliberation software to deliberate on how to build the software helps us stay focused on the user experience.

The problem we first set out to “solve” a few years ago was to create national, citizen-centric debates where people could participate in the Presidential debates in a much deeper way.  Since then we’ve changed the problem we are trying to solve (as predicted in #5 above) to creating a platform where citizens can educate each other on current events by exploring the differences in their opinions.  As the news industry evolves there are tremendous opportunities for making this a reality using citizen-centric software.