Tips for quick and flexible design prototyping
July 18, 2013
July 18, 2013
This article was originally published at netmagazine.com. With their site transitioning to Creative Bloq, I’m republishing here for posterity.
For the past several months at 37signals, I’ve been working on a new app called Know Your Company. At the beginning of the project, we had a lot of ideas, but we weren’t sure if they would gel into a cohesive product or not.
To find out, we built a functional prototype. During this phase, I stayed mindful of how I approach design problems. I wanted to forget my past tricks, build things better and faster, and try crazy stuff outside of our comfort zone. Here are a few tips I picked up along the way.
When you’re first starting out, the sky’s the limit, which is both exhilarating and overwhelming. Narrow down by identifying the core of your idea. What’s the one thing that’s so important, the project couldn’t exist without it? That’s what you should work on first. Start exploring and see if it even has legs. If not, regroup and start anew.
Conceiving ideas is hard and fiddling is easy, so you might lose your mojo by working on unimportant details too soon. Be disciplined, focus on capability and avoid distractions that slow down your progress.
We fell into this trap. We accumulated too much styling in an early version, and started wasting time debating it. Realizing our folly, we switched the entire UI to plain black and white to ensure we were working on the real problems.
Once you have distractions under control, play it fast and loose. Try your wildest ideas first. You can always fall back to something more conservative if they don’t work out.
We always like to experiment with weird elements — interesting shapes, animations, colors, or layouts. Forget what’s been done before and do something different. Look for real world inspiration.
Ideas build on themselves. One idea leads to another, and suddenly you have a diverse pool of things to try.
Often these evolved ideas are stronger than your first ones, so don’t be afraid to change course for a few days. You might end up with a final set of features that’s entirely different than your original vision.
Many early explorations are junk. That’s healthy. At one point we trashed thousands of lines of code. Don’t get attached to what you already built - be critical, let it prove its worth, and relentlessly cut anything that isn’t working.
When you’re working on a production app, optimization and the Don’t Repeat Yourself principle are important. But for a prototype, some duplication can be beneficial.
But maybe next week we’ll decide that messages should look or work much differently than notes. Or we might axe the messages feature altogether. Then all that optimization work was pointless.
Keep things decoupled until you’re certain they’re sticking around.
A prototype should be as real as you can make it, but don’t go nuts. If something is too hard to build, stub in examples and get things as close to real as possible. (My early measure of “too hard” was anything that took more than an hour or two to figure out.)
As an example, at first we didn’t build authentication into the prototype, we just pretended there was a logged-in user.
Working on new stuff is fun, but there’s also no obvious deadline for when you’re done. So keep hustling and cover as much ground as you can. If you hit a lull, get out of it quickly by reconvening and deciding what’s next.
I also stayed motivated by watching my daily commits. I like to see a lot of progress every day, and Github’s profile page is great inspiration for keeping the streak going.
When you’re moving fast, trying ideas, cutting features, and stubbing in examples, things can get messy in a hurry. Take occasional chances to weed the garden.
We like to keep a “Chowder” list in Basecamp for minor problems that need attention. It’s the perfect list to tackle when your creative juices are tapped out, or if you’re waiting for someone else to finish some work before you can move on.
At some point, the prototype needs to get real. This time we waited a little too long and had polished too much before calling in a programmer. This made it overwhelming for him to jump in cold. A good lesson learned – prove the concepts as fast as you can. If you’re confident the idea is strong, then get to work building with a real production crew.
So that’s what I’ve learned this time around, but the creative process remains a mysterious beast. What tips do you have for taming it?
Want to get new posts by email?
Subscribe to my newsletter: