How to Start

“Just start.” How many times have you been given that advice? Not sure what to do about a design problem? Just start. Trying to come up with a new blog post? Just start. Want to learn something new? Just start. Every time you approach an obstacle and are unsure how to proceed, inevitably someone will offer this mantra with a wink and a knowing smile.

The problem is that this advice is total bullshit and the people who offer it aren’t being helpful at all. Telling someone to “just start” is as useless as telling them to bang their head against a brick wall and hope it eventually falls over. They’re more apt to crack their skull than to make any progress whatsoever. People hand out “just start” because it’s easy to say and sounds as if they know a thing or two. I mean, it works for Nike to sell millions of shoes, right? Why wouldn’t it work for your UX problem?

To be fair, “just start” is also something we were each fairly good at once. As children, we’re much more likely to dive into something headfirst without stopping to consider every possible angle. When I was four or five, I lived in a neighborhood populated by teenagers. At the time, I did everything I could do emulate and befriend this group of older (and, obviously, cooler) boys. So when they started skateboarding in our cul de sac, I new exactly what I had to do. I charged into the house and up the stairs. My mom asked me what I was doing, to which I responded, “I’m getting my skateboard.” Amused, she informed me that would be difficult, considering I didn’t own a skateboard. “I do so,” I replied and scrambled the up the rest of the stairs to my room.

A few minutes later, I came back downstairs with my “skateboard” in hand:


Of course, this didn’t work out for me. Plastic wheels don’t do so well on concrete. Not to mention the yellow string wasn’t doing me any favors. But, to my credit, I saw what I needed and I “just started.”

The problem is that starting without thinking or without considering the context will almost always lead to riding a plastic xylophone up and down the block instead of a skateboard. Just starting may help you fill the literal requirements of the task, but it will rarely, if ever, help you achieve anything meaningful or lasting. We need to know what to start, when to start it and how to overcome the obstacles along the way. In thinking about the way I’ve designed products in the past, I’ve identified a few key moments in the product cycle that I’ve felt blocked on. Moments that someone might give you that dreaded piece of advice, instead of something actionable and useful. Here they are in chronological order, with some thoughts on how to move forward:

Start getting mad.

Twiddling your thumbs because you aren’t sure what to work on next? Get mad. If you’re not mad already, go find something that makes you mad (or at least mildly irritated). Think about what bothers you most about what you’re working on. What’s broken? What’s missing? What have you been neglecting that drives you crazy when you think about it. Go work on that. Right now. I was talking to my friend Marc once and he told me,

I don’t plan well. When I go to bed at night, I lie there and think about what to do the next day. Whatever I’m most unhappy with, I focus on that.

Okay, you’ve found the thing to be mad about? Good. Next up:

Start thinking

This one initially sounds as much like bullshit as “just start,” but let me clarify. Start thinking about and defining the problems you need to solve. At most tech companies, this usually takes the form of writing out user stories. “As a user, I want to ________ because ________.” You can actually apply this to any set of nouns/verbs/reasons to suit your needs. Insert engineers, CEOs, managers, etc. into this. Get different perspectives on the same problem.

After knowing what the problem is, most people jump right into coming up with solutions. While doing so can certainly lead to creative and successful solutions, what I’ve learned in the past year is that it’s much harder to get buy-in for those solutions. Why? Because we all think differently about what makes a solution “successful.” A designer sometimes defines success much differently than a PM or VP or even another designer.

The goal at the outset should be to come up with and agree upon tenets that would indicate a successful solution. Does a good solution provide fewer user actions? Or does it require more for the sake of clarity? Is simplicity a factor or should you opt for a breadth of choices? You’d be surprised how often in the past I’ve assumed we all think the same way about something, only to find out we couldn’t disagree more. This sort of exercise lets everyone share a common language and starting point before discussing any of the solutions you come up with. It also allows you to measure the success of what you’ve designed against priorities you laid out before you even began.

Start trying things

Finally, coming up with solutions! As many as you can, as fast as you can. At this point you want to be working in the lowest fidelity capable of expressing your ideas. Important to note, low fidelity does not mean crappy. It simply means finding the perfect combination of quick and useful. For designers, this may involve sketching, moodboards, word maps, etc. For others, it may be as simple as typing up an outline in Evernote.

The danger in any of these steps (and especially this one), is that it’s easy to start going in circles. It’s especially tempting to just continue to generate new ideas and ways of attacking a problem without actually committing to one and moving forward. One remedy I’ve found particularly useful is timeboxing. Set up a pre-determined amount of time for idea generation. Maybe it’s an hour, a day or even a week to get down a bunch of different ideas on paper and validate which are worthy of further exploration. No matter what time period you choose, once it’s over, stop and move on. Pick a couple of the most promising directions and press into the next phase. You may circle back if those ideas don’t work out and you need new ones, but at least you won’t be paralyzed.

Start iterating

On my first trip to London, I was blown away by how well-designed the city is. Not only from an aesthetic standpoint (though it is a beautiful city), but down to the small practical things. Namely, the crosswalks are painted to inform pedestrians which way to look before crossing. It seems silly, but it saved my life more than once in the couple of weeks I was there. And they didn’t have to tear up the roads, install bigger signs or even put stop signs for cars at each crossing to solve the problem. They simply spray painted the walking directions on the ground. It’s this kind of small-cost, big-gain iteration that you should focus on.

There’s a bit of a mad scientist vibe to the act of iterating on the web that some people have a hard time coming to terms with at first. Taking a decently-performing page and turning all the knobs and dials is pretty intimidating if you’ve never done it before. The best advice I can give you is to find a good variant-testing solution and go for it. At Zoosk, I think at one point we had about twenty variations of the sign-up screen going at once. Some of the variations weren’t that different from each other, while others were massive departures. At one point, we even had multiple subscription models, with completely different feature-sets, running simultaneously. We crashed and burned on a few, but those lessons drove us toward the solutions that were most popular with our users.

The real moral here is not to be afraid of failure. Try new things and see what happens. It’s the only way to learn what works.

Hopefully this helps

I’ve spent a lot of time over the last year examining and maturing my design process. The steps above are what I refer back to whenever I find myself spinning my own wheels on a project. They’ve gotten me out of a jam numerous times and I’m hoping that, by sharing them here, they’ll help someone else too. Instead of trying to live up to the old “just start” adage, try this one:

Don’t stop.


Now read this

Why Designers Really Should Learn to Code

There’s been a lot of discussion over the years about whether or not designers should be obligated to learn how to implement what they design. This obviously causes a bit of angst amongst the design community because, of course, not... Continue →