Designs That Change Lives: UX Boot Camp and Kiva

“The UX Boot Camp is a transformational experience, disguised as a training.”

- Lead UX Boot CampTeacher, Stefan Klocek

In each UX Boot Camp, participants dive headfirst into design. They are challenged by a real-world problem and in just four days produce clever design solutions tailored to their clients needs.

At the UX Boot Camp with Kiva, the designers’ mission was to envision web concepts that helped Kiva lenders decide which loans are best for them and facilitate the loan selection process. Currently, lenders can feel overwhelmed or discouraged by the number of borrowers and different types of loans. So Kiva was looking for ways to empower lenders and help them make decisions with their money.

Read More

Applying Lean UX

We recently wrapped up a project for a startup in the digital photography space, and aside from being great design partners, one of the fun things about them was their excitement to utilize some of the Lean UX strategies and techniques that former Cooperista Josh Seiden wrote about in his bookLean UX with Jeff Gothelf. We certainly learned a lot from going through the process with this client (learning as you go is, after all, a Lean UX principle). We had some best practices confirmed, and found some new ones and nuances too. Here are just a few that we came across in going through a real-life Lean UX project.

Know your user.

In all the sprinting towards a testable product, remember: you’re designing for real people. Those real people are often not like you. Design is about empathizing with people and their problems, then coming up with solutions to solve them. In theory this is a no-brainer, but in practice this is hard. It means being disciplined about designing for your users’ real challenges, not the ones you assume they have — or even worse, the ones you really, really want them to have because it would be perfect for your business model.

With our photo product partner, we collectively identified several potential user types–sharers, documenters, savers, organizers, and a few more. But designing a super-tool that’s all things to all people wasn’t what we were after. So we chose a specific user with specific attributes, and designed the best product for them. Part of our hypothesis involved seeing if the design worked for that group, and if it did, then we’d start designing improvements for the initial user or for additional user needs.

Read More

Lean UX: An Interview with Jeff Gothelf and Josh Seiden

From time to time, we revive our in-house book club to catch up on new themes, practices, or ideas out there in the design world. This month, we’re reading Lean UX: Applying Lean Principles to Improve User Experience, written by Jeff Gothelf and ex-Cooperista Josh Seiden. Inspired by Eric Ries’s The Lean StartupLean UX takes aim at waterfall design and development processes and outlines a set of ways that UX designers can more deeply and helpfully engage in product development. The intent is to foster more open, collaborative, and iterative processes, and to break through the organizational red tape that can stifle creativity. The end goals: More trust, more clarity, more fun, and better products delivered quickly by a highly-functioning team. Managing Director Doug LeMoine caught up with Jeff and Josh to discuss the ways in which lean practices can superpower our (and your) UX work.

Doug: UX, as it is commonly practiced, is all about establishing a coherent vision for a product or service. Oftentimes, in striving for coherence, designers can slam the brakes on development, since no one wants to waste effort in developing something that’s not part of that coherent vision. What is to be done with this state of affairs? How does Lean UX help here?

Josh: I do think establishing a vision up front is important. But I think that we often mistake how much work we need to do to establish and articulate that vision. If you’re working in deep collaboration with a cross-functional team, you can establish, test, and validate a vision very quickly. So, instead of “slamming the brakes on developers,” we advocating including them and other team members in the visioning activities early in the project.

Read More

Cooper helps TaskRabbit design new iPhone app for help with chores

TaskRabbit’s service connects people who want help with simple tasks—anything from walking the dog, standing in line at the DMV, or moving furniture—with “Rabbits,” a network of background-checked and pre-approved individuals who have the skills and time available to complete tasks.

TaskRabbit
With a design ideal for mobile task posting, the app provides a simple, seamless process for securing extra help.

Cooper designers collaborated closely with developers at Pivotal and the TaskRabbit team to design a user experience specifically optimized for busy, on-the-go people, offering timely help for folks with unfinished errands or other tasks. With just a spin of the wheel and a few taps, the app enables a task to be posted on the TaskRabbit service network in a matter of seconds with minimal, if any, typing.

TaskRabbit
Credits: Faith Bolliger, Jim Dibble, Glen Davis, Tim McCoy and Nick Myers.

TaskRabbit, has more than 1,500 runners in San Francisco, Boston, Los Angeles, and Orange County fulfilling up to 3,000 tasks per month and they just opened the service in New York City.

Congratulations to the TaskRabbit team, as the new app release has been featured on Mashable, TechCrunch, and Forbes and has received great reviews.

Download TaskRabbit at the App Store and start getting stuff done! Read More

Lean UX at Startup Lessons Learned

This week I had the pleasure of speaking about UX at Eric Ries’ Startup Lessons Learned Conference. The event is at the center of the Lean Startup community and was attended by 400 entrepreneurs, developers, product managers, investors, and designers, with a simulcast audience of equal size.

I joined the “Design + Lean Startup = Lean UX” panel with Josh Seiden, Jeff Gothelf, and Zach Larson, hosted by Janice Fraser. We discussed the value of design in defining products and services, and shared techniques for incorporating design into startup culture and organizations.

The startup community is hungry for good UX, and entrepreneurs, investors, and developers alike are recognizing the value and experience designers can contribute to a successful product team. Here’s some highlights of the overwhelmingly positive response:

@navneetaron
#leanux is awesome. silicon valley companies both large and small can benefit from it. my learning from #sllconf

@dshdle
Super motivated & inspired! started morning watching “Design + Lean startup = #LeanUX” talk

@ericries
You could hear a pin drop in here while @clevergirl explaining “test / invest” or “prove / improve” cycles.

@ClintonWu
Customer dev and UX are the same thing. Epiphany.

@rickperreault
@manjeetdadyala Loving the leanUX panel. Eye opening session. #sllconf #leanux +1 Very important to bridge design & dev

And perhaps my favorite, here’s a reminder we designers are not the only ones saying “duh, if you’d listen to what I have to say, things could be so much better!”

@geoffclapp
Designers and consultancies are starting to understand&embrace #leanstartup. Not only cost of deployment&development has changed

For your viewing pleasure, here’s the Justin.tv archive of the panel (my talk on Product Stewardship starts around 21:30.)


Watch live video from Startup Lessons Learned on Justin.tv

You can find the deck on slideshare here:

http://goo.gl/o5nVB

I encourage you to watch all the segments from the conference. A few in particular stood out for me:

Brad Smith of Intuit discussed how his Fortune 1000 company runs on startup principles: no teams larger than two pizzas can feed; hire good people and provide an environment for them to succeed; and foster a strong sense of responsibility throughout the team.

Mitch Kapor talked about his transition from old-school entrepreneur to lean startup advocate and how his overnight success at Lotus lead him to believe it was easy: “I gave bad advice for 25 years.”

James Birchler of IMVU detailed lessons his team learned about the limits of A/B testing and the value of developing good hypotheses to validate through testing and feedback.

Finally, please take five minutes to watch Eric Ries’ closing remarks – he does a great job summing up the spirit of the day and highlights the value of design to the Lean Startup movement.


Watch live video from Startup Lessons Learned on Justin.tv

Related Reading

Read More

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).

learn_build_measure.png

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.

Faster

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.

cycle1.png

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

cycle2.png

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.

pair_cycle.png

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:

Learn

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

Read More

LeanUX workshop recap

In partnership with Janice Fraser of LUXr, Cooper hosted a two-day workshop to share our emerging thoughts around lean user experience and agile product stewardship with a group of designers, developers, and product strategists from Cooper, Adaptive Path, Hot Studio, 500 Startups, and several other organizations.

luxi day 1.jpg

We spent the first day exploring the intersecting arcs of lean startup, customer development, user centered design, and lean and agile development. Each of these approaches to making software look at the puzzle from a unique perspective: lean startup and customer development come from the world of business and entrepreneurship; lean and agile development practices strive to build healthy collaborative teams and coerce order and purpose from the sometimes chaotic world of programming; user centered design emphasizes understanding and empathy for people served by the software we create. Lean UX and product stewardship seeks to weave together best practices from all of these approaches.

Material from first day of the workshop is available on Slideshare.net at

http://goo.gl/aJwdm

luxi day 2.jpg

The next day, the group put their new thinking to work helping Change.org envision and clarify a new initiative. It was fascinating to see founders of early stage startups and consultants to Fortune 500 companies find common ground in their approaches. Some were learning to recognize the particular value of narrative to provide context around features, others identifying places where their existing processes could be more lightweight or robust. When we were done, the fine folks of Change.org had three promising approaches and everyone understood a little bit more about how to move our practice forward.

I’ll have much more to say about the ideas and practices behind lean UX and agile product stewardship and I’m excited about sharing our experiences and learning from yours. Read More

Integrating solve and do

The industrial age divided our world into white-collar and blue-collar workers. Those with white collars went to college, worked in an office, solved problems, and made decisions. Those with blue collars went to high school or trade school, worked in a factory, performed work, and followed orders. “Solve” was separated from “do”.

But in our contemporary world of knowledge workers, very little of it can be teased into separate “solve versus do”. Today, doing is an integral part of solving, and solving is an integral part of doing. We are all “no-collar” workers: smart, well-educated, solving problems, and performing work.

The successes by state-of-the-art practitioners in both agile development methods and UX have given rise to a desire for more effective collaboration. Once a programmer has seen what well-applied agile methods can accomplish, she soon begins to yearn for a better user-facing strategy. Likewise, once a designer has seen what good interaction design methods can accomplish, he soon desires to work with a strong development team open to collaboration.

Many advanced thinkers have already tried a first order solution: agile programmers have requested input from designers, and UX designers have attempted to squeeze their work into the timeboxed cycles of agilistas. The results have been promising, tantalizing, but somehow not quite there yet. It has become clear that while both UX and agile are effective methods, a combined “agile-UX” method will be something different from—something beyond—a simple addition of the two.

This past weekend, in a creatively messy office space in Tribeca, two dozen such advanced thinkers got together for the third installment of a working group dedicated to addressing this worthy challenge.

The group, which calls itself the “Agile UX Retreat”, consists of about 50 people, who borrow time away from work to participate. The group actively seeks and invites promising newcomers, but there is a core of twenty or so who attend every meeting.

At last week’s third meeting, the group shifted into a higher gear and made remarkable progress. They weren’t so much “post-agile” or “post-UX”, as they were “post-doctrine” and “post-hostility”. The thinking, speaking, and exchange of ideas, vision, and practice was not only of a remarkable quality, but it consistently transcended its component pieces. Beyond talk of design or agile, beyond talk of design and agile, the talk was of what the organization can be—and must be—when everyone in it is committed to the principles of user-centered, collaborative, iterative teamwork.

Much of the gruntwork of figuring out how this new organization works is being done by the “lean startup” folks, spearheaded by the likes of Eric Ries and Steve Blank. Lean startup has really only been practiced in tiny little startup companies, where, when you talk to the “product owner”, you really are talking to the product owner. While this is only a microcosm of the larger corporate reality, it is a valuable test-tube in which experiments can be conducted. In other words, we can learn a hell of a lot about how to run a big company by seeing how this stuff works in little companies.

But the core ideas of lean startup aren’t so much new as they are simply the beliefs of agile and UX, brought together effectively in a business context. Half of the lean startup’s principles are bedrock to agilists, while the other half are foundational to user experience professionals.

Not just the designers and not just the programmers, but everyone has to center their work on satisfying the customers. You need to have sublime confidence that the only way to deliver a successful product or service is by first delivering some version that is wrong, or at least, not quite right. That is, success on the first try is not within the capabilities of humans. Iteration and incrementing are integral parts of a post-industrial approach to product development.

At the union of “solve” and “do” we find the definition of the twenty-first-century business. Even though we are still at the beginning of this journey, it’s clear that we are finally on the right track.

Related reading

Read More

Things I learned at Agile Up To Here

(This was originally published on Playwell, Alan’s personal blog.)

Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Things I learned:

  1. After 25 years, it’s time to lose the Windows computer and get a Mac.
  2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.
  3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.
  4. It is time to build software.
  5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.
  6. When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.
  7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.
  8. Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).
  9. Even this jaded old fart can still get excited about changing the world.
  10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.
  11. People want a leader with a vision.
  12. Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.
  13. The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.
  14. For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.
  15. Story-mapping is a major component of the bridge between interaction design and agile development.
  16. Story-tracking software isn’t quite there yet.

Read More

Common ground

The biggest problem in software today is that programmers and designers simply don’t work well together. They certainly want to, but each craft sees the problem from their own point of view and, with the best intentions, each tries imposing their methods on the other group. But even agile developer’s sharpest tools aren’t going to work well for designers, and likewise, even the designer’s sharpest tools aren’t going to help programmers.

The solution will be to find some common ground where each craft is open to the best contributions of the other, without either side being forced to sacrifice their inherent strengths.

I believe that the solution, like most big things, will be relatively simple in concept, yet getting there from here won’t be easy.

Today, most of the pathologies of both designers and programmers can be traced to their mutual lack of experience working together. Most programmers will tell you their biggest problem is coping with rapidly changing requirements. Most designers will tell you their biggest problem is unresponsive programmers.

In the modern, agile world, programmers defend themselves against changing requirements by showing customers the program as often as possible, and by being able to make rapid changes to suit the customers expressed needs.

Interaction designers defend themselves against uncooperative programmers by doing ever more detailed design and documenting it with greater accuracy, detail, and precision.

But modern, agile programmers can work so flexibly that they don’t need all of that detailed and precisely written design. If designers could just blend into the development team, they could communicate their design directly without the overhead of documentation. They could provide a kind of just-in-time design service to the programmers.

On the other hand, interaction designers can master the driving principles of even the most complex domain so that programmers don’t need to make all of those changes. With a comparatively brief and inexpensive field study, designers can vanquish the changing requirements problem almost completely.

Ironically, the common ground for agile developers and interaction designers is one where the major problem faced by each craft separately is largely solved by the simple presence of the other craft, working collaboratively at a peer level.

That’s really good news for cost-conscious business people (now that’s redundant). Having designers and developers collaborate is very economical. Most of the cost of interaction design is incurred in the documentation and communication of that design. Similarly, most of the cost of software development is incurred in traversing blind alleys trying to elicit useful guidance from the stakeholders. Effective collaboration simultaneously discards the need for the two most expensive parts of product development, while driving quality—and user desirability—through the roof. Read More

1 2 3