From the computer to the wall

One of the principles we live by at Benjamin Interactive is to get things out of the computer and up on the wall. The problem with keeping everything in the computer or in electronic form is that nobody else than who’s working on it sees it. You can have loads of information in the wiki, in Basecamp, in email correspondences, in powerpoints, in photoshop files, in excel sheets, or on note paper – but most likely it is only you and the team members involved with the specific content, that will ever see it.

The problem with that is late feedback. Late feedback from all the other people who might have something interesting to say about what you’re working on right now. There are more of these people than you might think: your boss, the sales team, the guy who did a similar project last fall, the project manager, testers, the guys taking over later on in the project, and even random people. When the information continues to live in your computer, in turn, there’s a good chance you’ll end up spending too much time on the wrong solution.

Instead, get it up on the wall! Make it visible! If you’re working on a new design, mock it up on paper instead of spending large amounts of time perfecting it in photoshop. Mockups do not need to to be beautiful to create value: they will provide immediate feedback. If you have a new business idea, write it down in a short sentence that sums it up, and write it on big letters on a large piece of paper – or sketch it up with rich pictures. If you want to communicate progress in a project, then get the user stories up on the wall with a series of note cards and mark them with stickers once each is done.

Sketch it. Draw or write it by hand and put it up on the wall. The result is better and more honest feedback. You will be surprised how little effort is needed to create value. If you aren’t embarrassed about your first sketch, then it’s too pretty! With better and honest feedback, it will be easy to make radically different solutions faster!

It’s a about being proactive vs reactive.

This post was inspired by Anders Kragelund’s 10 tips on user driven development