How to run lean

For the last few months/years, I’ve been working with startups. And the latest one decided to become lean/agile. This is great for software development — you get feedback early, and often — but it’s been a huge challenge as a designer.

Research, personas, mental models, journey maps, wireframes, sketchboards, prototypes, interviews, analytics, A/B tests, OH MY. All of the sudden the whole world is running your product meetings. I really missed the quiet time with my right brain, where experience and intuition led. I missed my Adobe products. I wondered when craftsmanship would be measured or prioritized.

I’m at a happy place now, after reading a bunch of articles and a couple books and talking to some very smart people. Here’s what I learned, filtered of the business jargon (through charcoal, Kentucky limestone and Swarovski crystals). This is written for designers, and anyone who needs to take a wee pause before diving into their next great idea.

1. Research. Even before you’ve started building (hold back, makers), you can pretty well describe or sketch what you’re thinking. So, you can interview the people you’d expect to be serving, or working with, and see if they actually have the problem you’re trying to solve. Awkward conversations are your awkward-but-powerful friends. Check out remoteresear.ch for a great list of tools.

2. Prioritize. Figure out who’s going to play the most important role in your little world of users. Make personas if it helps you design for people other than yourself. Write out each one’s background, and typical day. Personas should be BASED ON ACTUAL RESEARCH, not stereotypes. HT @jodify for owning that point.

3. Brainstorm. Open up your unboxed mind to solve the key problem you’ve identified. I like to do branding and visual things here, before I’m nailed down to the technical details of wireframes. Spot the design opportunities over time, as your users notice their problem, consider their options, start their solution, and maintain their change. Imagine interactions in their physical, social, and messaging environments. (HT @frogdesign for journey maps.)

4. Prototype. List all the steps of each main action. Review and revise the flow. Then sketch, wireframe, or build it in the most lo-fi manner possible. Whatever is most comfortable for you. I like Balsamiq, people also recommend HotGloo and Invision. Your goal is to get actual content in a tangible form, fast, so you can see (NOW versus later) that no one notices your essential button or priority feature. Of course you’re designing mobile first, and know that your users aren’t “browsing” but skimming — with one eye and one thumb.

5. Evaluate. Return to your alpha users, and ask them if you’ve solved their problem. They will be polite and say yes, so test some strangers too. User Testing lets you watch users attempt to complete your list of tasks. Verify App lets you test their recall, or mood. Both will crush your ego, and make room for new flowers to grow.

In the initial “sprint zero” phase of the product, you’ll spend weeks or months on all of the above. Once you have a minimum viable product, you’ll run this cycle on each feature, every two weeks. You might stagger research/design and development, so one is a cycle ahead of the other, but Thou Must Ship Code Each Fortnight.

As you have more users, and more statistically significant data, the evaluations will get more quantitative. You’ll have to justify each feature by its estimated value on essential metrics (acquisition, activation, retention, revenue, or referral — AARRR!), so Kissmetrics and Google Analytics are good to set up early on.

Collaboration-wise, I like Sprint.ly for managing tasks, though you have to be good about grouping them into features.

Change is hard, but if you’re tough and flexible your creative project will stick around and stand on its own.