December 09, 2011

Unlearning Perfection

A few weeks ago I had a quick email exchange with someone asking “if I were to give advice to designers attending Startup Weekend, what would it be?” This has Blog Post written all over it.

I’m guessing I was asked not just because I’m a Designer Who Codes, but also because I’ve also done a bunch of Startup Weekends and hackdays and have generally fared pretty well. (I say this as explanation and run-up and not to brag, by which I mean I just bragged, and deal with it.)

Good hackday performance in my case is mostly due to my ability to sniff out people who are smarter, more talented, and harder-working than myself, to grab them, and to NEVER LET GO. That, and maybe also a little bit because the unique time constraints and pressure of these one-or-two-day timelines has helped to figure out how to approach design with an eye towards ROI, learning where design can really add to the perceived value of a quick prototype and how it can help sell the broad vision of a product.

1. Don’t Futz

The TL;DR of this whole thing boils down to forgetting about your pride and leaving behind the idea that your work needs to be perfect. Client work taught me to be perfect; Startup Weekend and all the rest of the hackdays I’ve done helped me realize that a lot of my detail-oriented tics and obsessions don’t serve the goal of my team winning a weekend-long hackathon as much as they do my own pride. Yes, details are often what make the difference between user delight and user disappointment. But you won’t even have any users to delight if you don’t ship something, and you only have like 24-or-so working hours to ship something.

At Startup Weekend, for example, you have five minutes to present the sum total of everything your team’s done, from problem statement to execution to revenue model and beyond. So before taking a half-hour to polish the shadow on that app icon, ask yourself whether the return on investment to the team, the presentation and the product as a whole justifies the time you’re about to spend. No one’s going to notice if you skip it this weekend. Promise.

2. Do The Logo Last

Museo Slab + Glyphish + iStock + about half an hour = Swaydar

Or at the very least, don’t spend the first 12 hours on it. Seriously, I bet you can do something pretty decent in 20 minutes. Just pick a nice typeface and customize a stock icon or two and you’re good to go. If it makes you feel better, promise yourself that you’ll come back to it in a few weeks once you’ve won and quit your jobs and raised $250k from Ashton Kutcher. I am pretty sure that no one’s won a hackday on the back of a super-sweet logo (though I would love to be proved wrong on that), but there are plenty of people and teams who’ve won despite really shitty ones.

3. Code Over Photoshop

If you design websites, or mobile applications, or if you use “UX” or “UI” to describe what you do, and you don’t know the basics of HTML and CSS, you should really really really consider learning. Understanding the opportunities and limitations of the medium that you work in is a lot easier when you’re implementing what you create, and it’s really rewarding and empowering to at least prototype your designs on your own without depending on anyone else.

Skipping Photoshop when you’re working on your weekend prototype saves so much time and eliminates frustration that comes with designing things that don’t get built because what you design is ready to go immediately. And when you have a good understanding of implementation you’ll better be able to…

4. Steal Remix Shamelessly 

Use open-source projects and existing resources as much as you can. The swell of pride you might get from those lovely hand-crafted tab bar icons will quickly fade when you realize that those sweet-ass icons were the only thing you worked on and that your presentation totally sucks and everyone is mad at you.

To me, being a design hacker is innovating on the whole by using creative solutions to pull the individual parts of a product, an app, a site, a presentation—whatever it is—together under real-life and real-time constraints. Repurpose assets, use a framework and mine Github for open-source components that help you do more faster.

5. Design Impossible Things

Faked!

Despite what it might look like, Heineken didn’t sign a sponsorship letter of intent nor did Audi agree that they’d put our two-day-old technology in their cars. Both projects won their respective Startup Weekends anyway, though.

Again, Startup Weekend (and a lot of other hackdays) come down to a five-minute presentation. I believe that the highest return on design investment is in demonstrating long-term vision, substituting for complex functionality and making abstract revenue generators seem concrete. There’s only so many features you can prototype in a weekend, but there’s no limit to what you can show in a well-constructed slide or two.

Work with the team to identify complex features that are better demonstrated with mockups than working code and to figure out how design can drive home revenue models and big product vision. Every other presentation is gonna have someone talking about how they’ll make money with targeted brand integrations and just-in-time hyperlocal offers or whatever. Actually showing what your revenue generators and vision looks like, even if it’s with some dream version of a product that shares only a name in common with the prototype you’re presenting and exists only in Photoshop Land, can have an incredible effect on selling your team’s hard work to the audience and making the team’s ideas more real.

Got other ideas about how to design for Startup Weekend or other hackathons? Please share them in the comments. Especially if you’re a designer who’s participated in one of these events—I’d love to hear about your experience!