design and lean startup methodology

10 Oct 2010 - 2:41am
3 years ago
7 replies
4096 reads
jra
2010

hi all,

has anyone out there worked as a designer on a team that follows a lean startup methodology? any thoughts on how design process can mesh into it? (can it?) i'm just starting to work with such a team, and i'm trying to get my bearings, have been reading through a bunch of lean startup stuff. any thoughts from other designers, on the topic (rants, raves, anything really) would be welcome. 

thanks!

j.

 

Comments

10 Oct 2010 - 10:05am
Adrian Howard
2005

Hi there,

On 10 Oct 2010, at 09:17, jra wrote: [snip] > has anyone out there worked as a designer on a team that follows a lean startup methodology? any thoughts on how design process can mesh into it? (can it?) i'm just starting to work with such a team, and i'm trying to get my bearings, have been reading through a bunch of lean startup stuff. any thoughts from other designers, on the topic (rants, raves, anything really) would be welcome. [snip]

I'd love to hear other peoples thoughts too :-)

I've not done a lean startup project yet - but ask again in six months since I'm planning to try a ux / lean startup / customer development / agile combo out on a little internal bit of product development that I'm doing :-)

In the mean time you might find Jeff Gothelf's "Lean IA" presentation from Euro IA of interest.

http://www.slideshare.net/jgothelf/lean-ia-getting-out-of-the-deliverables-business

Cheers,

Adrian

http://quietstars.com adrianh@quietstars.com twitter.com/adrianh
t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh

>

10 Oct 2010 - 5:51pm
Laura Klein
2009

Hi J,

I've ton a done of work with lean startups. I love it, but it does take some getting used to. Design absolutely works in a lean startup, and Eric Ries (the founder of lean startup) is a huge proponent of ux design. 

An important thing to remember is that the team is very likely to have a "getting it done is better than getting it perfect" mentality, which will force you to design quickly and then iterate on your designs once they're live. This can be fantastic, since it really focuses your design efforts on identifying the very most important parts of the design. It can also be terrifying if you've only worked in a waterfall environment. 

The best advice I can give you is to develop a very close, friendly relationship with the engineers. In my experience with lean startups, everything works very fast. If you have a great relationship with the engineers, you can find out exactly the sorts of design direction will be the most helpful for them (hint: it's probably not a giant, formal design spec!), which will save you a lot of time and heartbreak. It's also great because, at some point, they're going to come to you and say that part of what you designed will take forever to implement, and you can work with them directly on coming up with other alternatives. They'll also take it better when you put your foot down about something because you know it's a better user experience. 

They're also probably going to a/b test absolutely everything, so be prepared to have your designs scientifically tested to see if they're actually improving key customer metrics! That can be a little nerve-wracking, but it's great fun when you're right the vast majority of the time (which you should be, because you're a good designer!). 

Oh, and when all else fails, and the engineers are being difficult and not believing that a particular part of the product needs redesigning, make them sit in on a user test session and watch people try to use their product. Nothing convinces them faster than watching users break down crying. 

I'm a huge fan of design in lean startups, so if you'd like to talk in person or by email, feel free to contact me. laura at usersknow.com. I've also got lots of stuff about this on my blog at http://usersknow.blogspot.com. Also, I wasn't able to go, but apparently the recent Warm Gun conference was a great lean ux design resource, and I believe there are videos of it online. 

Good luck!

11 Oct 2010 - 4:54pm
Etan Lightstone
2009

As sort of a guiding principle, I really liked a lot of the ideas mentioned in "Getting Real" by 37 Signals. 

Keeping designs simple and fast and avoiding lengthy up-front design specs are pretty much key. It is also important to keep your design iterations one step ahead of the development iterations. The screens you are focusing on this week should be part of a future development iteration (not the current one). 

If the product UI already has a theme / layout / style defined, try just keeping your designs as sketches and go straight to front-end development. Pick the simplest easiest tool for creating wireframes if you decide to go that route (powerpoint for example), everyone has it.

Testing with users is really important, and depending on how agile you are, you may have customers at your disposal to test new features or UIs on regularly. Make sure this is worked into the schedule such that you can have time to ACT on the findings. Perhaps just test paper prototypes.

I also really like the idea of epicenter design for the early stages of the product. When implementing a product, focus on the most important (or most risky) piece first (If you are facebook, avoiding the authentication system and focusing on the "wall" and messaging system for example). Design can have a similar approach.

 

That's off the top of my head :)

 

--Etan

11 Oct 2010 - 11:30pm
diana aspillera
2008

I have to agree with Laura, thanks to a close working relationship with our engineers and developers, I've been able to prioritize useful UI, but its also a benefit to me in my craft in learning to write better specs. It's like the equivalent of something I read about product designer, Tom Dixon. He feels strongly about designers being intimate with the production process and understanding the materials that they are working with. Clearly we can't have as tactile an experience with code (or can we?), so collaborating with the engineers is the next best thing to understanding how your vision becomes reality.

Another thing, that I know 37 Signals talks about often, is starting with the basics and not being too ambitions with your set of features. When in the design process, it's very easy to think about all the great features, but once you get in contact with engineers, you have to start sorting between "nice to have" features and required features. I find that presenting features in phases, from basic feature to fully blown feature, is helpful when in the early stages of your project. It helps everyone understand where things are headed, especially the developers. This isn't always perfect, though, because as things evolve, your ideas of where features need to go also evolve! I've discovered that some of my phased specs changed direction or not all the features were really all that necessary.

I hope that you're in an environment that fosters communication between the different practices - it really makes it a difference!

 

 

11 Oct 2010 - 11:31pm
diana aspillera
2008

I agree with Laura! Thanks to a close working relationship with our engineers and developers, I've been able to prioritize useful UI, but its also a benefit to me in my craft in learning to write better specs. It's like the equivalent of something I read about product designer, Tom Dixon. He feels strongly about designers being intimate with the production process and understanding the materials that they are working with. Clearly we can't have as tactile an experience with code (or can we?), so collaborating with the engineers is the next best thing to understanding how your vision becomes reality.

Another thing, that I know 37 Signals talks about often, is starting with the basics and not being too ambitions with your set of features. When in the design process, it's very easy to think about all the great features, but once you get in contact with engineers, you have to start sorting between "nice to have" features and required features. I find that presenting features in phases, from basic feature to fully blown feature, is helpful when in the early stages of your project. It helps everyone understand where things are headed, especially the developers. This isn't always perfect, though, because as things evolve, your ideas of where features need to go also evolve! I've discovered that some of my phased specs changed direction or not all the features were really all that necessary.

I hope that you're in an environment that fosters communication between the different practices - it really makes it a difference!

 

 

12 Oct 2010 - 10:47am
Christopher Rider
2009

I'm going to stray a little from the original topic, but:   

From an overall product strategy view, the start simple approach has a lot to recommend it. However, as he product evolves, a UI paradigm that supported that simple product may begin to buckle under the weight of more and more features.   

This poses several problems. The obvious ones: You will need to continually evaluate the designs to determine whether they are still working. And of course, once you identify a problem and design a solution, you may have to tear out a big chunk of UI code to make room for something else   

Less obviously: rolling out a whole new UI has an enormous impact on your existing userbase. Look at Facebook, for example. They have been very aggressive in redesigning, and every time they roll out a new UI, thousands of people join the"w33 h@tEz 7h: n3w F@sb00kz" group.   

Jared Spool's slides on the history of Amazon.com show an interesting contrast to Facebook's approach. The site today is drastically different from what it was at the beginning. But they have managed to roll out new features in a way that avoids mass revolt.   

(I suppose it helps that the site has always been butt-ugly, but still...)   

As usual, the optimal path is probably somewhere in the middle of these two extremes.   

I have run into this problem in my own work a couple times - it is a very challenging problem and there is generally no easy solution. Moreover it often coincides with other organizational growing pains.   

If your product is a commercial website or SaaS, you can do a lot of live A/B testing to evaluate different approaches. If you are making something with a more defined deployment process, like off-the-shelf software or something with a hardware component, then the challenge is multiplied.   

Good luck!

13 Oct 2010 - 3:24am
jra
2010

hi all -- if this post makes it through -- i want to say THANKS for the enormously useful feedback. i have, three times now, written out detailed responses that haven't gotten posted. quite frustrating. but anyway, suffice it to say, all your comments have been very insightful given my situation. hopefully, if this goes through and/or my feedback gets a response, i'll be able to post a more substantial response soon. thanks again,

aditi

Syndicate content Get the feed