January 8th, 2009
7 ways designing in public can improve your business
In response to yesterday’s post, Garrett Dimon, creator of the bug and issue tracker Sifter, shot me an email explaining his reasons for designing in public. Garrett built Sifter basically in the public eye, from the initial ideas all the way through production. (here is an example: Smart Return in Sifter)
This is exactly the type of thing I was asking for more of in my post yesterday, and I feel like an idiot for not including Garrett’s work initially, since I’ve been a long-time fan of his work. Anyway, Garrett recommends this process of transparency for everyone, and listed out 7 reasons for thinking so. I’ve formatted his email into a blog post below (with his permission). Thanks, Garrett!
—— Garrett’s email follows ——
Just wanted to drop you a line about your latest post to provide a bit more evidence about the effectiveness of sharing design decisions. I’ve been doing essentially the same thing for Sifter, my little bug and issue tracking app, since August of last year, and the results have been phenomenal.
In fact, I redesigned my personal blog specifically to support different sizes of embedded images in anticipation of sharing my design process and lessons learned. Sifter really started as just a way to have something fun to blog about, but It’s achieved several things for me, many of which you mention.
- Originally, it was just for fun and maybe something I’d develop open-source, but the feedback from everyone was so overwhelming and encouraging that I quit my job and pursued it full-time. If I hadn’t shared those ideas, I also don’t think my two partners would have encouraged and backed me in the process of building the business. It really gave them something tangible to believe in, and, as a result, encourage me to follow through with.
- Marketing was a very convenient side effect. It probably generated about 90% of the interest in Sifter. Without that, the launch wouldn’t have gone as well as it did. Unfortunately, there’s always the potential for being labeled vaporware, but as long as you ultimately deliver something, that doesn’t really matter. It’s definitely not justification for not sharing. By sharing, whether it gets built or not, other people are able to benefit regardless of the final outcome.
- Sharing and communicating ideas is hard. You have to really justify your position, and it forces you to make your ideas better because you discover the holes in your logic as you’re writing. That additional thought really helped push me to invest time in all of the ideas.
- Feedback. Sharing ideas like this provides a great test bed. Obviously the positive feedback encouraged me to have a go at building it, but the negative feedback helped as well. Like I said before, putting your ideas out there really opens you up, and all of the feedback played a part in what eventually became Sifter.
- Transparency. Sifter is very opinionated, and whenever I get suggestions for features that we philosophically don’t agree with, it helps to be able to show people why we disagree. Oftentimes, they change their mind and see things our way. Other times, they respectfully disagree and try a different product, but either way it helps to make it clear where we stand for us and for our customers.
- A really nice side effect was that those design posts helped generate all of the leads for my freelancing work that paid the bills while I was working on Sifter. Without realizing it, it was providing a very clear insight into my thought process, ideas, and passion for design. Potential clients would see that and generally contact me about doing work for them without even having to go up against other designers.
- I list this one last not because it’s the least important, but because it didn’t directly benefit us other than just making me feel good.
That is the teaching and sharing value. I’ve had countless people email me thanking me that the posts helped them see design and interface design in a different light. Others have told me that it provided the material they needed to convince their boss of their idea. As long as it helps promote design, I’m all for it.
I’m sure there are more benefits, but those are the ones that stick out in my mind. It’s become such an important part of Sifter that I plan on continuing to do it. Every time we build a new feature, I want to discuss the design process and ideas just as openly prior to actually building them. Instead of saying “here’s what we did and why” we’ll be saying, “here’s our plan, how would you improve it before we build it”. It’s worked well for us so far, and I see no reason to change it.
I think the biggest problem is that people are afraid of their ideas being stolen. Then, the second biggest reason is criticism. People on the web can be ruthless, and it’s scary to open yourself up and reveal every thought and opinion that led you to a decision.
However, I’ve found that both of those are irrelevant at best. For the most part, I encouraged people to feel free to use the ideas as much as possible in their own work as long as they didn’t copy the whole app. There were a couple of cases of people taking a little too much inspiration, but they weren’t anything big enough to derail Sifter. Besides, by that point, it was clear where they derived their inspiration from, and it was almost reassuring. I think I would have been more concerned if nobody cared about the ideas.
Anyhow, I just wanted to let you know that 37signals wasn’t alone, and that I can corroborate all of your ideas about the benefits. I’d personally love to see more people doing this as I know it’s become an integral part of our culture. If I hadn’t shared those ideas, it’s likely that Sifter wouldn’t exist today. So, going forward, I feel like Sifter owes everyone the same level of transparency ad infinitum.
——–
Find out more:

Links to this Post
Comments
1. Jeremy 9:57am, Thu 8th, 2009
Its an excellent idea. I think one of the big barriers for a lot of startups is opportunity cost: the hours you spent posting design decisions could have been used to build the thing (and time is very precious for startups and bootstrappers). Perhaps the more people see the business value in such a commitment (which your post so nicely demonstrates), the more we’ll see more companies doing this kind of thing, which, I think, would really benefit the web startup community.
2. Régis 10:57am, Thu 8th, 2009
Thank you very much for sharing. Garrett’s posts on his thought process have always been invaluable.
Even when secrecy is a requirement, some people manage to communicate about peculiar details of a product that may get some useful feedback and evolve accordingly.
I just found via swissmiss a website dedicated to book cover designs and if you take a look at the footer, you’ll notice the “future enhancements to the archive” widget which I find really interesting.
3. Valgeir Valdimarsson 1:15pm, Thu 8th, 2009
Related: an interesting post from Mark Boulton Design about the ongoing and very public redesign process of Drupal.org
4. Jack Christopher 5:44pm, Thu 8th, 2009
It’s also a good exercise to ask the contrary question, what are the reasons we *shouldn’t* design in public?
Or more exactly, in what situations is it better to design in private?
I can come up with a few answers to that, but I want to design *my answer* in private; We can test a more general case of this theory right now.
5. Dave Tufts 9:44pm, Thu 8th, 2009
Agreed – designing in public is great. 18 months ago when my firm redesigned our site, we wrote about each step as it was happening. The end results was a ten-part blog series starting here.
After posting IA ideas in part 3, one of the commenters suggested a great idea that we incorporated. Like Garrett said, putting the process in the public realm made us really think through and justify each decision. But mostly, I agree with Garrett’s first point: it was just more fun.
6. Tiff Fehr 2:20am, Fri 9th, 2009
To add another aspect to the benefits of public designing, Garrett’s posts about the design and features of Sifter gave me enough detail lobby my colleagues to adopt it. Watching the product evolve let us consider how it would fit our workflow and needs in greater detail than bullet point features. The posts even let us help shape the product to fit. It was much better than worrying if the product would fit our detailed needs out of the “box”.
7. Josh 6:30am, Fri 9th, 2009
@Dave thanks for mentioning your experience doing this. I actually remember those blog posts! Can you tell us what idea the commenter had that you incorporated into the imarc web site?
8. Josh 6:31am, Fri 9th, 2009
@Tiff – awesome! That’s a great example of how designing in public not only explains what you’re doing, but helps others explain it to even more people. And I bet that many folks have a problem with “out of the box” type issues…can this product really do what *we* need it to do? Talking about the design publicly would certainly open those communication channels much more than not.
9. Dave Tufts 9:47am, Fri 9th, 2009
We were getting over-aggressive in flattening the architecture, basically moving all pages up to a single level. Dan from Raka suggested that we move our bios below the About Us page, instead of having top-level pages for About Us and Team. We did.
We also got great feedback when we posted grey box comps.
10. Josh 2:54pm, Fri 9th, 2009
@Dave: thanks for adding that…I like the grey box comps!
11. paydayadvances 9:53am, Wed 18th, 2009
Good steps. Especially first) Thanks for information.
12. acne treatment systems 3:25pm, Fri 27th, 2009
Awesome. Thanks for mentioning about this, designing in public is great. I also agree with Jeremy’s comment.