Build for Speed
The current methodology for building applications is broken. Most teams go through the classic agile pattern: ideate, build, launch, measure, iterate, repeat. Even when executed efficiently, this process stifles innovation under the burden of engineering and product launching. Using real-world examples, Daniel will show how to test your theses more quickly and increase the overall effectiveness (and happiness!) of your whole team.
Dan has “a very weird job…” doing venture capital for Google… but they have a design team! May be the only design team in VC. They feel design is critical in the way businesses succeed, so they do hands-on design work with the companies they are funding. This gives a great 10,000 foot view of the industry.
Asked a bunch of entrepeneurs in Britain “what does design meant to you?” Brand would come up quickly; then talk about look and feel; maybe they’d talk a bit about UI and UX… but that would be about it. Then they’d ask “what keeps you up at night?” and they’d immediately relax and start talking about other things.
Now they talk to people about how design can help them with the things that are keeping them up at night. This means they are talking about their craft with everyone involved; and showing people that “design” is not magic pixie dust.
Big challenge to business right now: agile is not as quick as people think it is. You make your best guess, build it, launch it, measure results and iterate. But you are starting with a bad idea. Then you take longer than you think to build it; now it’s too expensive to abort; the measurements are inconclusive… but you can’t go back once something is in the wild. Even when it’s terrible, those ten super-passionate users will come after you with pitchforks if you take it away. Then most teams don’t really iterate.
So at Google Ventures they do five day design sprints – skip the slowest parts of the sprint.
See gv.com/sprint for much more info…
Case study – creating robots for service industry, eg. hotel check in desks that fluctuate from “mellow” to “bonkers” at two big peak times per day. So they build a delivery robot to take items to rooms at times the front desk is bonkers. They wanted to test the risks of rolling this out in a real hotel.
So they assembled a sprint team: designer, engineer, robotocist, customer service ambassador from the hotel, plus their CEO and COO were also in the room for the week.
Day one: they create a sense of urgency with time pressure. It makes people move faster.
Get the right people to test – you don’t want the homebody who never stays in a hotel; nor do you want the road warrior who never needs anything. You want someone who stays in hotels 3-4 times a year. So they put an ad on Craigslist and link that to a screener.
They had to map out a huge amount of user experience touchpoints of having a robot deliver things – from a robot whizzing past you in the lobby; to how it deals with getting in and out of lifts; to how does a robot announce themselves at the door of the room? (it rings the room phone)
Biggest opportunity *and* risk: How should the robot behave? They’re confident it is safe but should it have personality? If so what kind? Most people have not interacted with a real robot, but we kinda expect Wall-E… but we don’t have science-fiction level robots yet. They simply don’t exist yet.
Then they do some notes, then sketching, then some three-pane interactions. Everyone works on their own in this stage; it’s a quiet, focused room. Avoid narrowing ideas too quickly; don’t let the loudest voice dominate. You want the best ideas out of everyone.
Then they put up 10 options and quietly vote on them. No design by committee.
Look up “dot voting jake nap”(sp?) for ideas about how to do weighted voting.
People vote next to good, important ideas – this creates an instant heat map. Then they talk about why they voted; then do some “super voting”. Certain roles who are close to the customer or business get a bigger vote (yes including the CEO).
This brought out important things to test – should the robot have a face? Should it knock on the door? Should it make noises at all? What dialog should occur – what’s written on the screen? Then a crazy idea – make the thing dance! A simple, delightful end to the interaction.
Day 4: prototype. Wait, there’s no time left! Also a prototype has to be something you’re willing to throw away immediately, no unhelpful attachment. So in this case they made a digital prototype – just keynote to get images onto the tablet that formed the robot’s main interface. Don’t worry about colours, typeface, etc – just do enough to suspect disblief.
Then they divided their efforts – some people made fake screens; some made sound effects; some practiced manually driving the robot through the interactions.
Then on the last day they did 5 customer interviews (in the hotel, with a pile of cameras, it was a bit weird and they really had to make the interviewees feel comfortable).
People loved the robot. They loved interacting, they loved the little dance, they were all ok with the robot bringing something to them. There were lots of upsides to a robot – eg. privacy. They did want to know what to call the robot.
The risky ideas had paid off. In just a week they’d tested things people felt were too expensive or risky to try out.
Other things they’ve done… 8 hour app prototype (just done in keynote and flinto)… just do enough to make software feel like software. They work with a huge range of companies in a huge range of industries.
- Gathering the right team is critical – have the expertise AND buy-in, in the room.
- Prototype like it’s a prototype – throw it away and do the real engineering for production. Design sprints are pre measurement to gauge the chances of success before you build the real thing.
- Get quick, credible research done – get data quickly, test with real people and see what works.
Again… gv.com/sprint
