More, better, faster: UX design for startups

Startups don’t have capital to burn or luxurious schedules for big-design-up-front. But unless your idea is by-and-for-engineers, design isn’t something you want to skip on your way to market. For a startup, design may mean the difference between simply shipping, and taking the market by storm. But with tight budgets, and aggressive timelines, how to include design and get the best value for the investment?

Eric Ries proposes a cyclical model for development in a startup: Build > Measure > Learn (repeat). Lots of smart people think he’s onto something. While Ries coined this model to explain how developers work in a lean way, the same model can be applied to design, only our “build” uses different tools, and the work products are at a different fidelity, but it’s still build. Our hypothesis is made manifest and testable.

In a recent Lean UX workshop hosted by the fantastic Janice Fraser (Luxr) and Cooper’s own Tim McCoy and Suzy Thompson (also of Cooper) suggested that the cycle was right, but that it begins in the wrong place. She suggested Learn > Build > Measure (repeat).


I buy it. After years of starting projects off with research (as little as a couple of hours in some cases) I’ve seen the power of starting off informed. Framing the problem before you start solving it is not only wise, but major opportunities for innovation often arise before anyone proposes a design solution.

So we have a cycle of Learn > Build > Measure (repeat). For a startup we can’t afford weeks of research, with the developers on the bench waiting for the voice of the user with thoughtful diagrams and artful persona back-stories. We need full-speed-ahead; design can’t afford to be the slow kid or the bottleneck.



How fast can we run the cycle? I’d suggest that design can run at a sustained pace of 3 days for a complete cycle. I don’t think you could do useful design faster. We often take 5 days for a cycle where we have time and budget, but 3 days is about the fastest you’d productively move. It bears noting that it takes a remarkably agile client to keep up with a 3 day cycle. Early stage startups with focused stakeholders and unlimited access to users for testing are the most likely to keep up with this pace. Larger enterprises benefit from a slower 5 day cycle.



Once we get the upfront work of personas and high-level scenarios done, cycles take on a regular pattern.


What do we get? Speed and low waste. We iterate quickly, with a 3 day cycle time we get moving quickly, we get rapid insights up front, ideas almost immediately up on the board, and pixel proofs within 24 hours. Sure they’re rough, but we don’t need high fidelity to test if the direction works, if users and stakeholders are getting what they need. All we need is something that gets the idea across. We’ll refine as we get deeper. And because we’re not letting design get too far out before getting it in front of users we’re keeping waste to a minimum. Our ideas will be tested early and often. We can throw out what isn’t working after a low amount of investment and focus our time on what is.

At this point the major win for startups is speed; design is incorporated without slowing things down. We also reap huge benefits from operating with such a low waste level. Days and dollars are spent building and refining the solutions that are most promising. But speed has a downside, we have little time to solve more complex problems. This may result in grabbing for obvious or standard patterns where a more thoughtful innovative approach might ultimately yield a better product. Also, design is an iterative process, the rapid cycles may seem like iteration, but the speed leaves little opportunity to revisit or reject and rework something. The first solution may easily end up the final solution. This may be acceptable for some projects, but when a startup is striving to innovate, it’s not enough to be first, you really need to deliver better.


More, better

There’s a way to supercharge this process in a way that produces predictably better solutions, and more of them. Add a second interaction designer. Pair design transforms the equation, from pure speed, into rapid insight that one designer with twice the time couldn’t produce. It’s not a case of twice as much in the same amount of time, speed isn’t increased, we’ve already maximized that. What we’re maximizing now is the quality. Two designers working together, paired in the right way delivers more, and better design.



The way we do pair design it’s not just any two designers locked in a room, struggling to wrestle the marker away from one another to prove how much better their idea is. We pair two interaction designers to maximize on the energy in polarity. We divide and conquer. One takes takes on the assertive role, the other the reflective. One takes on the drawings and interface, the other the patterns and words. One dives into details, the other keeps the big picture. One presents, the other captures. Through pairing and focusing on polarized responsibilities, we increase the value of the thinking and the product.

Let’s start with the first cycle:



While interviewing users and stakeholders we’ve got two observers, two sets of ears, two perspectives on what was learned. Our understanding is richer, fuller and more complex than any single practitioner could bring.



Build (personas/scenarios/early sketches)

One of our pair takes on the role of generating ideas, proposing solutions, getting something onto the board. The other is a dedicated thought partner. They hold back, poke holes, prompt, help evolve the ideas while they’re still forming. It’s a period of intense, rapid iteration. Roles can and do swap. We go wide, exploring much more quickly than a single designer could. Bad ideas are killed earlier. We develop clarity more quickly. We’re more confident of our decisions and more articulate about our reasons because they already went through the crucible of our partner.



Build (pixels and patterns)

Our pair differentiates further. One jumps into putting the ideas into pixels, the other into articulating the patterns that underlie the design decisions. Each works from the earlier design work, but refines it in very different ways. As we push our design though increasingly detailed scenarios it evolves. The two different approaches helps us triangulate on places where the design fails, and helps to identify fresh new opportunities. Two brains churning on the material coming from different directions, forces us to see more objectively, we can’t remain blind to the ideas we love that should be thrown out. The paired design team acts as an editorial cross-check on the thinking of the other. A single designer would be forced to choose between pixels or patterns, or struggle to articulate both poorly.



Measure (stakeholder/user feedback)

Pair designers divide up the work, focusing on a single aspect, presenting or capturing. One walks users through the flow, the other observes and captures notes. It doesn’t matter who’s doing what but each role is dedicated and focused. One designer would struggle to demo the design and really notice how users’ actions diverged from their verbal feedback, often critical distinctions which when noticed strongly inform future design decisions. With a pair of designers we capture the feedback accurately. We also have two perspectives on each test. We are less prone to fall into our own bias because we’ve got someone to check us.



More, better, faster is an investment

By pairing designers, we gain tremendous advantages. You’re running a startup and it’s easy to buy the process of a speedy cycle. It’s simple math and it maximizes cash, with quick early results. At first the idea of pair design may seem like a hard thing to sell to your board or investors. “Twice the designers, huh? Can’t we just get one and do more cycles?” Sure, people do it every day. But one designer doesn’t make more, better. Even a rock-star designer can’t generate enough polarity to come close to the “more, better” brought by two damn good designers who know how to work together as a pair. You buy a pair, you get more design; not twice the volume, but twice the quality. This isn’t that fine-china sense of quality, but the kind of quality defined by pure raw goodness. It’s the quality of solutions that people fall in love with. It’s the ephemeral but very real sense when you first make contact with the product that someone really truly understands you. Not all problems need or deserve this level of attention. There’s many times when one designer may perfectly address the need.But when your startup wants to design more, better, faster, go all the way, invest in it. Expect faster, and demand more, better. Your investors will want it too.



Related Reading


TIm Allan
With regards to pair designers...I really liked this sentence: "You buy a pair, you get more design; not twice the volume, but twice the quality." Such a great sentiment, and something I whole-heartedly agree with, but in practice, I have found its sometimes difficult to form effective partnerships or match people so that they form an effective partnership, so that the can be executed to level required. Its a bit like speed dating, something that may appear right on the surface is less attractive, when in the nitty gritty of a project and the pressure comes on.
Can you cite examples of startups that have succeeded with this model? I mean, it sounds like you guys have an interesting and meaningful design process - and its a reasonable hypothesis that your techniques might help a startup move faster. However, this advice would seem to be an option only to a small sliver of startups funded series A level capital from the get-go or perhaps a startup with 2 designers on the founding team - both very much the exception to what it means to be an early stage startup today. A case study would be a nice followup.
Stefan Klocek
@Jonathan: This process has been emergent for us, something which has organically grown as we've wrestled to find news ways to engage with our clients (especially startups). We just rolled off an engagement which was structured the way I describe above. Our NDA prevents me from sharing many of the details, but here's a little on it. We were approached by a previous client who left his last company to found another one. He didn't have lots of cash, but we played with the length of the engagement to make it work. Everyone was super focused for a few weeks of tight cycles, we didn't go more than two days without checking in, sometimes less. The project felt incredibly ambitious, but everyone saw the benefits of pair design, fast cycles in the maturity of the design solutions. Within a week we saw the ideas in code and within the month real users will be using it. The client was delighted by the process, and engaged us for an additional week to work through supporting interfaces for other personas. He used the first round of designs to sell his board on investing in the followup work.
Not read the article yet but will do so. I tend to read comments first, why I don't know. As to your reply Stefan - this is something myself and my team of coder and developers have been doing for more than 5 years consistently - and to very high standards: 'Everyone was super focused for a few weeks of tight cycles, we didn't go more than two days without checking in, sometimes less. The project felt incredibly ambitious, but everyone saw the benefits of pair design, fast cycles in the maturity of the design solutions. Within a week we saw the ideas in code and within the month real users will be using it.' And why we're all stupidly busy!!!!
Craig Sullivan
Great to see this articulated. I've done this a few times recently in a slightly different way but it worked very nicely. We had an A/B test of a new funnel and whilst flushing out the bugs, we used two tools. Firstly, Clicktale to observe and note any oddities, bugs, rendering issues or barriers that people ran into. Secondly, Google Analytics instrumented on both funnels (so we could segment the data) and Optimost to run the A/B test (and also provide more analytics and stats). Net result of this is we could quickly pick out the high priority issues from a UX standpoint that (drum roll) make real money! It wasn't about gaming the system or cherry picking - we genuinely want the thing working sweetly but this way we focus on conversion related UX issues (I feel strongly about this point - if you are a charity or a business, you owe it to visitors to help them do nice things for you). Bugs and browser compatibility issues we fixed. Bad rendering issues too. Anything that would affect conversion heavily. We also looked at issues, created hypotheses and then made them live. Clicktale gave a pretty good window as it recorded the whole funnel interaction (clicks, mouse, keyboard). During each iteration, we used Clicktale to verify, 10 minutes after putting a fix or tweak live, what was happening. You could see, nodding away, as you watched the recordings, exactly where the work was resolving things or having impact. Basically rinse and repeat this over a week and your new funnel process is working much better! I like the idea of using feedback tools, short snappy testing and trying stuff out - in very fast cycles but with supremely solid and segmentable analytics data. The segmentation is important and will differ depending on the site - there is insight in knowing how different parts of your traffic react. Having data and video from clicktale, the combination is pretty powerful.
The rapid model above works well. Requires all parties to agree that not having everything fleshed out is ok. Interestingly, 2 years back, I was pulled into a project for a major mobile device manufacturer and we did just this. Went from zero to development ready within the week. You get to a point where you have just enough to start prototyping very quickly. There's definitely a middle ground between the model put forward by Eric Ries and what I would categorize as a more traditional design approach. But people forget that creative process is generally very lean as is - with designs born out of sketching (rapid ideation). Delay is born out of insecurity around the validity of ideas/designs. Which is why you often see projects take so long and amount to $Xm in budget requirement. In my experience, the best work is done when for whatever reason, the deadline is short and urgent. With a focus on developing a simple yet effective UX model. I've had a great deal of success applying this process to projects that would otherwise afford lengthier timeframes. @barrie_robinson
I find this article interesting, not because of the content, but because you seem to have ignored everything in it when you designed your own website. Your site is really hard to navigate and you cannot tell what is going on it the UI. You can scroll around wherever you want, which makes the user totally ignore the very small and subdued navigation at the top of the site. Because there is so much to look at, the user has no idea WHAT to look at. There is no hierarchy of information. Everything is running together. On top of that it loads slow because there is so much to load. Lastly, your logo becomes an annoyance as it hovers over the top of other content as you scroll around. I think you should conduct some A/B test experiences on your site and post the results. Very poor design.
Tom Chiverton
Yes :-) I was going to add 'that is all' but want'ed to throw some key words for further research in too like goal directed development and intent driven design.
Marty Nelson
Bravo for the emphasis on UX. Somewhere along the way, agile got into a 'good-enough' mentality for UX that has landed most projects in mediocrity-ville. I wanted to get your .02 on a practice I have recently started using that involves initially skipping over the functional aspects of features and instead starting on the part which shows/proves the outcomes to the various stakeholders/users. So, for example, instead of getting mired down in details of transactional data entry, we instead start by designing what the various users would want the see from the system assuming the functional process has already occurred. IMO, this where most of the product 'bang' and innovation occurs. Also, if you know what everybody wants to get out of the system, it provides a scoping mechanism to define the ultimate outcome for the functional behavior.
Stefan Klocek
@Tim Allan: I agree. It can be hard to form effective partnerships. We are really lucky at Cooper because as a company we've made a commitment to pair design. This has forced us to develop ways to get consistently good results from our pairs, and to mitigate some of the issues that come with creative partnerships. I'm working on a more indepth article on how we do pair design from a tactical perspective, look for it in the next month or so.
Stefan Klocek
@Craig - Love the idea of using feedback tools to identify the areas where UX can make the biggest impact, designing to fix the issues and immediately putting it back out there to see how things change. So long as you maintain the right balance and don't fall down the slippery slope of analytics driven design, where numbers dictate the UX decisions. It's really valuable to get clear validation early and frequently, especially once you've moved past the blue sky questions and into proposing design solutions.
Stefan Klocek
@Marty If I understand you correctly you are proposing to focus on user/business goals instead of simply diving in and proposing functional design solutions. This sounds a lot like what we call goal-oriented design and we at Cooper deeply embrace this approach. We prefer to focus on users, on the goals they are striving to achieve and design whatever supports their success. As you point out this is often where the biggest innovation and leaps in inspiration happen. By suspending (for a moment) our disbelief in how something could happen to describe instead the ideal way it should happen we can reach such compelling solutions that it helps sell the required investment in figuring out how.
Very nice!
I knew what I did wrong, but I would never imagine how well you explained in here.
Doug LeMoine
This is really good shit.
I am a grad student, studying User Centered Design. Somebody in the comments said that when teams are insecure, they progress at much slower pace. I am working on a project for developing a mobile app and can relate to this insecurity & slow pace. -What do you suggest to folks like me who are novices? -How to instill confidence in the (novice)team members (making them believe that we are on the right track)?
Fantastic article. As has been said, an upgrade of agile thinking is very welcome. I wish I could find a way to apply the pair designer methodology to my current workplace, but I am the sole designer. However, the Learn>Build>Measure cycle will find itself burned into my body clock =D
Stefan Klocek
A number of commenters asked about practical advice on working as a pair. We published a new post today where I've described how our most successful partnerships collaborate.
A detailed article. Thank you for intoducing a new way for a start up..

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment