Showing posts with label Solution. Show all posts
Showing posts with label Solution. Show all posts

Friday, 20 August 2010

Something for the Weekend - Anti-Theft Lunch Bag

A light hearted (though not very attractive!) one this week.

If you've ever had your sandwich stolen from the fridge at work you'll be familiar with the long standing issue of lunch pilfering! Anti-theft lunch bags are a new product to help combat that. By simulating mould on the bag, it deters would be thieves, and keeps your food safe!

Of course there are flaws - for instance, someone might throw your 'mouldy' sandwich out or you might actually be put off eating it yourself! However, the level of simplicity and creativity are impressive - a useful reminder that the best solutions are often the simplest and least expected.

PS. Sorry if you're having your lunch whilst reading!

Sources & Credits
FreshBump

Saturday, 14 August 2010

Something for the Weekend - It's hardly nasal surgery!

I read an interesting story early this week that really brings to life the value of prototyping.

In 2001 designers at IDEO were tasked with working with teams of surgeons to create new improved tools for nasal surgery. During the design session one of the surgeons was trying to explain how the ideal mechanism would be a trigger grip only he struggled to put in to words what he meant. One of the designers picked up a marker pen and a 35m film canister and taped them together. They then picked up a plastic peg and fastened that to the front creating a basic version of what the surgeon was attempting to describe. This might sound like Blue Peter but it saved a huge amount of follow up meetings, through the ability to physically demonstrate what was actually needed.

I love the story as I see similar comparisons day to day in our roles. Where written requirements fail to adequately express the need; quite simply fail to bring it to life or allow for different interpretations. I am, without doubt, an advocate of using diagrams and screen mock ups to validate and elicit requirements so I thought I'd share some thoughts on the topic.

Tips for Prototyping
  • We're using BalsamIQ - It’s a great tool - do check it out at Click Here
  • Recognise that that creating mock-ups won't slow things down, it generates results faster and gets people on the same page.
  • Be clear as to why you're mocking up screens - it's not for the purpose of a final design but to elicit comment and validate written requirements and assumptions.
  • Keep it rough - to have something too polished suggests it’s a final design, enough to get to the answers as quickly as possible is all that is needed - Lo-Fi is the way to go. (just think of nasal surgery!)
Sources & Credits
IDEO

Saturday, 17 July 2010

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

Tuesday, 1 June 2010

Something for the Weekend… Solution Addicts

    Recently I've noticed an increasing amount of people coming to my desk with predefined solutions, whist to a large degree this is admirable, on further probing there's often a lack of definition about the problem is that needs to be addressed or perhaps more specifically the root cause of that problem.


    It's logical that people do this… traditional business teaches that we shouldn't dwell on the problems but instead be taking action to resolve/improve them, and after a while it becomes a habit, and ultimately an addiction. - We start to think about answers faster, faster and stop taking the step back to really look at what we're trying to achieve. A really clear symptom of this is when new information (inevitably) emerges or challenges arise and U-turns are required on solutions as a result (or worse). Framing problems and root-causes up front help with this enormously… if your solution is addressing the root-causes of a problem, new information can only help to build and evolve a better solution.

    It's our role as analysts to do this, so how do we go about it? The first is step helping people to admit they have problem (i.e. not that they have solution). I've attached an 8 min video to a presentation by lady called Mary Poppendieck - she's a prominent voice in Lean based software development techniques and in this video she does a fantastic recap of pareto charts & fishbone diagrams and the importance of testing your analysis by completing what she terms "Many Rapid Experiments" http://www.youtube.com/watch?v=MhxyO6jUubQ.

    These techniques will no doubt be familiar but digging them out of your toolbox and dusting them off is always a valuable thing to do.

    If you've got any questions on the techniques Mary talks through do let me know.

    Enjoy and have a great weekend-

Thursday, 27 May 2010

Something for the Weekend - Emotional Connections (iPod)

As promised, I wanted to follow up on the last SFTW with some validation as to why creating an 'emotional connection' in what we deliver is equally as important as creating a functional one… an argument that the iPod can make without too much justification from me!

The iPod is often held aloft as a great design example… It's practical, intuitive, functional but also has the ability to engage with people in a way that's very hard to put your finger on… good physical design, creativity, brand, tactility, universal / consistent navigation, simplicity? - what is that x-factor? I don't know the answer but I know it's important!

Creating an emotional connection is not at all frivolous, it has huge commercial advantages. Apple have sold 260,000,000 iPod units worldwide and hold around a 70% market share of the global portable media player market (I want to say 'iPod market' which is a sign in itself!). Just imagine getting a tube or plane and not seeing the ubiquitous white headphones! To remain streets ahead of your competitors despite a higher unit cost is impressive.

In our world it's equally important to remember the importance of these connections… we need 'our customers' to feel a sense of satisfaction when using a system or process not just acceptance. I'm not sure there's a fixed recipe for creating this (or I'm sure I'd be a lot richer!) but I think a strong starting point is the recognition that 'functional' is not enough... Understand every detail, understand your customer and pursue perfection.