"Iterate lots!" and Design

Thu Apr 11 13:05:40 2013

Last night I was discussing UX design with a friend and he mentioned, as I blathered on, that he was very familiar with my design philosophy: "Iterate lots!". Which is interesting because I view it as a business philosophy, tied with a development methodology.

It basically goes like this: I don't think humans are good at knowing what they need, just what they want on a surface level. So when developing a new product it's probably best to get something in front of your customer as fast as possible - get them paper mockups, drawings, and alpha products with horrible quality. And get then feed back, concerns, and fix things. And do it again and again till you have something that people want and you can sell.

When producing websites/software as a startup it's probably worth it to launch, (and if you can get away with it) even charge for your beta. The product will only get built if you survive, and money is both a sign of traction and a longer runway. And bigger betas are more feedback, and thus produce better iteration's, and better products.

All of these are pretty normal beliefs, certainly not controversial, in startup circle's but they don't seem to percolate out much. This is pretty standard take on the Minimum viable product idea.

But - I've always thought that UI/UX Design should be more contemplative roles. A product's detailed functionality is likely to be very much unknowable without talking with a customer. But it's target market, and core purpose are what mainly informs a look and feel, and those are known. And the current feature set, informs the UX. Which should allow for more breathing room.

But of course that feature set is going to be swivelling around just as wildly for the UX designer as it is for the Dev. And if you are having a hard time finding product/market fit, you might have to pivot the whole brand about - perhaps a lot. And this all probably feels like mayhem for a UX designer who is used to setting the direction of UX - not responding to a constantly changing product. The role becomes not at all contemplative, and much more reactive. And "Iterate lots!" turns out to be a design philosophy as well.

And that has some pretty big ramifications on how I treat UX for my projects and how I structure roles, and work product for those who do it. I'll probably rely more on Responsive Deliverables for starters.