A guide to building prototypes
I’ve been trying to express some of the principles and ideas that I use in my day-to-day work in the R&D Prototyping team and this post has been sitting on my desktop for far too long. Think of it as a first draft and let me know if it’s useful or what’s missing or even what’s plain wrong about it. I’m not going to go into why you would or should prototype, and some of these things obviously apply to all kinds of projects. It is inspired by countless things including 37signals “Getting Real” (if you follow this, you’ll be fine), 43folders, Diego Rodriguez’s Innovation Principles, lots of people I’ve worked with, and more. I’m not sure any of what follows is original, and it’s not comprehensive, but this is my list and I find it useful.
- Ideas are easy, building things well is hard.
- Build things to surface problems and understand things. Until you build it you won’t truly understand the opportunities or challenges.
- Read in and around the problem area. A lot. There aren’t many new ideas and lots of things already exist. This should be obvious but it will stop you wasting time.
- Make it simple, then simpler still if you can.
- Embrace constraints, they are there to help you and make you more creative.
- Define the approximate scope of what you’re going to do, you can always change it later but you’ll have something to work to.
- Know when to stop. Make up a deadline if you don’t have one. And reduce scope if you’re not going to make it.
- Work in an agile manner, but I don’t really care if you have a methodology or not.
- Get T-shaped people, or at least have T-shaped multi-disciplinary teams.
- Work together all the time. Try to get your engineers and designers working and thinking together and exploring problems from both perspectives simultaneously. This can be hard.
- Talk a lot within your team. Make sure you know what everyone else is doing.
- Support team-members’ passions but be pragmatic.
- Sketch. On envelopes or napkins or with code. This helps communicate the problem, get a shared understanding of things and get further support for the work.
- Make it just good enough to work and look good enough to attract people. But not too polished; the lowest resolution you can get away with.
- Tell people about it. Write about it. Communication helps form your ideas and develop your prototype further.
- Don’t chase shiny things.
- Don’t get hung up on a particular technology. Build it with anything that works, you can refine it later.
- Try to make it fun but not frivolous.
- Just start, I know it’s hard, but once you’re going it will get easier. And even if your first attempt fails you’ll have learned something.
Posts
3 comments:
1 thing to add: understand that you're not wasting time - you're saving it. Lots of managers v wary of allowing prototype time as it seems too 'fun' and inconsequential. this is madness, but a significant hurdle to overcome.
That combined with a healthy dose of fear from the builders, means most places don't prototype.
Neither are valid reasons not to tho'.
It is also worthwhile thinking about what aspect of the system you are prototyping: Houde & Hill (Apple) have a nice paper on this
@suzy - I was steering away from the "why" but OK, I like the not wasting time thing.
@joe - I guess that somewhere in the scoping decisions, I'll take a look at the paper, thanks.
Post a Comment