Something for the Weekend - Henry Ford

Henry Ford was without doubt a revolutionary and left an indelible mark on the world. He changed the face of the both transportation and attributed quotations but I'd like share one in particular:

"If I’d asked my customers what they wanted, they’d have said a faster horse" - Henry Ford

That quote was taken just after the launch of the Model-T in 1908. The Model T was simple to drive, easy to repair and cheap to buy. A huge commercial success by 1920 the majority of Americans had learned to drive in a Model-T!

I've written previously on the difference between 'Listening Vs Understanding', and this acts as another great example of that, but I wanted to take a slightly different slant. What causes the need for revolution rather evolution? What makes the case for throwing it all away and starting from scratch?

There are obvious 'signals' that trigger innovation or more fundamental overhauls of something existing but when you look at true revolutionaries there seems one obvious commonality and that’s a clear sense of vision. An understanding not only of the product, the company or the customer but how the product fits in the world as a whole. In the case of Ford there are plenty of examples of this, one of his principles was about higher wages for his workers. It meant that he got the best workers but it also meant that they could afford to buy Ford products and act as advocates - something that would typically have been out of reach.

So what can we do as analysts?

• Root cause analysis - really understand the problem or opportunity and think widely about how the solution fits within that.
• Consider what might be required on the periphery to make your solution a true successes.
• Start operational designs early even if its just rough notes to help you discover the right questions to be asking - I'm a firm believer that you can't define the function until you've understand how something fits operationally and organisationally.
• Design visibly and iteratively - allowing you both to 'fail fast' and use the collective brain power of your SME's before you're too far progressed.
• Have the confidence to challenge the solution even if you designed it.

Sources

http://en.wikipedia.org/wiki/Henry_Ford

Something for the Weekend - the Fail Whale

Apologies for writing two SFTWs in a row on the topic of failure but this week I wanted to share a story of UX that I love... and hope you will too!

I'll start by explaining what the Fail Whale is... When Twitter gets overloaded and goes out of service, instead of giving a techie failure message you get the friendly picture of the 'Fail Whale' (below), a polite apology and instruction on next steps.

The interesting thing is that it seems to absorb a lot of frustrations and, in fact, the fail whale now actually now has a cult following! Check out the fan club http://failwhale.com/ where you can buy the t-shirt! Or if you're really excited why not go ahead and get the tattoo Click here

Now, I'm not saying we need pictures of whales but here are a few thoughts to tie this back into our roles as BAs:

• It shows the value of spending time on actively designing the User eXperience for when things don't quite go to plan... giving the appropriate consideration to the 'unhappy path' as well as the happy one.
• Its a rare event that error messages make people happy and we can't stop all exceptions but we can be sure to handle them as well as possible.
• When things do go wrong use a style that's meaningful and explains to the user what's going on and, perhaps most importantly, what they need to do.
• Ensure that error messages can be communicated back to IT support teams in a meaningful way when required and that there are unambiguous (e.g. unique numbering) for as many outcomes as possible.
• It's important to consider this with process failure as well as IT failure. Can we automate the feedback of something going wrong in an operational process? (LEAN visual management techniques spring to mind)

Sources and Credits
Check out the designers page http://yiyinglu.com/
http://failwhale.com/
CNN http://edition.cnn.com/
www.twitter.com

Enjoy and have a great weekend-

David

Something for the Weekend - Fail Fast

In a recent interview with Wired magazine, Lee Unkrich (director of Toy Story 3) said something that reflects an important part of any truly successful team. It's also a principle that's deeply embedded into Agile Development teams.

Here's the quote:

"It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible."

Without doubt that's contrary to popular belief... People focus on getting everything to 95% before they're prepared to share it... but don't you find that often the 95% position still has flaws? And that often it's too late to really react to them? (Therefore is that really 95%?)

A few thoughts that underpin this:

* In true 'no blame' cultures having the freedom to take calculated risks means that some will pay off and some won't. The key to unlocking innovation and creativity lie in having a 'safe' environment in order to explore ideas.
* No one person should have a monopoly on ideas. The wrong environment can suppress ideas from all but the most confident.
* The trick is to seeing the outcome of any venture as positive, if it's paid off you've increased the quality of what you're doing, if you've failed you've learned from it.

What I'm not suggesting is that it's ok to fail overall... in fact, far from it! The key word in Unkrich's quote is "fast" - The very idea of failing fast is to guarantee success! So how do we do this?

Experiment openly and visibly (through documentation, prototypes, conversations, presentations) - ensuring that all failures become minor setbacks.
* Create a culture where small failures in the delivery cycle become successes in learning, consider them R&D! It's the only positive thing to do if they happen.
* Actively encourage the sharing of ideas - everyone has them.

Sources

Interview with Lee Unkrich in Wired http://www.wired.com/magazine/2010/05/process_pixar/
Spotted via the 37Signals http://37signals.com/svn/posts/2348-its-important-that-nobody-gets-mad-at-you