dancingmango

Who’s deadline is it anyway?

I’ve been rather tardy of late with blog posts; too much else is going on, not least the writing a book Agile Experience Design with Lindsay Ratcliffe to be published in November. Lindsay writes a great article for our publisher on how the design process is no longer fit for purpose, being stuck in the old advertising/ print world with outdated concepts that are irrelevant for the digital world.  Not least is the concept of the deadline, working towards this mythical date for the final reveal.

I’ve recently seen several projects where deadlines have caused all sorts of issues.  Here’s a theme.  The business owner picks a date in the future for the new product to be launched with great fanfare.  An agency are engaged by the business to develop the creative concepts.  This creative stuff has to happen offsite, and certainly nowhere near IT (who are seen as party-poopers, unable to be visionary, rather doomsayers with their constraints).  Aligning the creative and IT is a challenge, but there’s a deadline for the agency to deliver the creative and this fit’s into the IT plan.  What happens next is that the creative slips.  The concepts are not quite right; the business asks for them to refined.  Their deadline passes.  IT raises it as a risk on the plan, but the delivery date for launch remains fixed.  Finally the creative is complete and signed off by the business who are delighted by the innovative concepts.  IT aren’t.  They got an unrealistic product vision to be delivered in an unrealistic timeframe with no control over the launch date that has been announced to the market.  As the date approaches and difficult conversations are had, who gets the blame?  Not the creative team who produced the hoped-for award winning design.  They are long gone.  It is IT who get the blame, once again failing to deliver on time or on budget.

None of this would happen if designers and developers collaborated.  If ownership of both the process and the product was shared.  How can we facilitate that sharing?   That’s coming in the book.  That I ought to get back to writing. To meet the deadline.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Act like a startup

I recently presented at the AOP Forum on secrets of product success.  Twenty minutes to get through sixty two slides was fun; part of me tells me I need to slow down, be more considered and reduce the messages I want to get across.  Another part of me just says meh!

I ended the presentation with the below takeaway slide that is worth replaying here.  I believe that product owners need to start thinking more like entrepreneurs and their seedling product ideas more like start ups.

Think big: Start with a big picture, a vision, where you want to get to. This should be unconstrained thinking, divergent thinking before converging on the specifics.

Start small: Easier said than done, but this is the getting to a minimum viable product.

Fail fast: Get stuff to market quickly, test with your consumers and be ready to fail. If you fail early you fail cheaply. Realise that you have customers, users who are already passionate advocates of your brand. Take them on the journey of development with you. You not assume that everything you need to take to your customers must be polished and perfect. Don’t underestimate the positivity than can be accrued by engaging users in the development process

Grow success: Do not see the end of the project as the end of road. Getting to a first release is only the first step. Successful product owners will be engaged in a virtuous cycle of continuous design and continuous delivery. They can come up with an idea, a new feature and get it in to production in hours, or days rather than months.

Letting go is the hardest thing

Tim Brown from IDEO gave the audience at his TED Talk a simple exercise. He asked the audience to draw a picture of the person sat next to them. He gave them a minute to do so. He then asked them to show their pictures. “Sorry” was the stock reaction as the sketches were revealed. They had an inhibition on showing their work. When it comes to creativity, as we move beyond childhood we take on board inhibitions and feel more uncomfortable sharing our creative efforts unless we perceive them to be ready or any good. Getting a visual designer to share her work in progress is a challenge. We fear what others will think if our “deliverable” is not ready, is not finished or polished. We fear setting expectations, we fear disappointing, we kill our creativity with fear.

So we are uncomfortable at letting others into our personal creative process. Now take this to the organisation, to the enterprise and creative genocide is abound. Like the Head of Digital who had 130 different stakeholders to socialise the Organisation’s new website designs with. Enter the HiPPO. The Highest Paid Person’s Point Of view. And with a few of those on board you get design by committee and design mediocrity. Or the client who refuses to engage with customers or end users in the early stages of the design process in fear of what they might think. A fear of setting expectations, a fear that their competitors might see what they are up to. Killing their creativity with fear.

Letting go is the hardest thing. But it can also pay great rewards.

On 27th October people coming out of arrivals at Heathrow airport were greeted by singers and dancers and general merriment. As an ad campaign for T-Mobile by Saatchi & Saatchi it was inspired, creative but not without risk. All the members of the public filmed had to sign a release form, agreeing to their being used in the ad. What if they didn’t? But they did. Whilst meticulously planned, the success of the ad is in the general public. T-Mobile got over any fear they may have had of the unknown and let go of the product to let the crowd create. It’s an uplifting piece, and successful too; their youTube page has had over 5.5 million views. And to the bottom line? The ad saw a 12% rise in sales the week after airing.

The tyranny of nice

My first English lesson with Mrs Sullivan aged nine. She was one of those teachers you remember. An awesome teacher.

“Nice” she told the class, “nice is a word you will not use”.

The word “nice” was forbidden in her classes. And woe betide anyone who described their weekend as nice, or their birthday present as nice (probably an Action Man or Scalextrix or if you were really lucky a Raleigh Chopper or Grifter).

It is a lesson I learned and kept close to my heart today:  Nice is mediocre, saccharine, inoffensive, meaningless, ordinary, without passion, expression or meaning. “Nice” is a faceless word. “Nice” is something that the left brain aspires to and the right brain shuns. Nice is an anathema to the artist, to the designer. Nice doesn’t provoke, it doesn’t inspire. Nice is instantly forgettable.

“Have a nice day”.

Shit NO! (this deserves swearing – see the passion that Mrs Sullivan infected in me; what a teacher!) That’s “have an ordinary day”. It’s not a differentiated day. I don’t want to just have a nice day. I want to have an awesome day, a magical day, a memorable day!!

And the same with experiences and products.

Disneyland isn’t nice; it’s memorable and magical (despite the fact that you spend most of your day there queuing). Do you think that Steve Jobs would be happy if someone called the iPhone ‘nice’?

Nice is for Microsoft. It is for engineers to aspire to. Nice is not art, nice is not design, elegance, simplicity or beauty. Nice is dull mediocrity.

And yet nice is something that corporate software doesn’t even begins to strive for. There’s no place for nice in software methodology. Think Scrum; nice is rarely even a nice to have (it’s gold plating). Tell me Scrum Masters, in your zeal to deliver “business value”, ship the “minimal viable product”, I bet you’d be happy with what you deliver being considered nice.  F@@k that. Your projects fester in a world of mediocrity,  in a quagmire of backlog; picking off stuff to do, focussed on features and functions rather than customers goals and a desire to delight.

Bring it on Mrs Sullivan. Nice has no place in the English Language. Bring it on, Agile + Experience Design. Nice has no place in software development.

Can you banish nice from your lexicon; go beyond nice and seek delight?

I don’t want to have a nice day, I want to have a memorable day.

I don’t want to have a nice product, I want to have an awesome product.

I don’t want to have a nice experience. I want to have a memorable experience.

…And if I’ve designed an experience and the only word you can use to describe it is ‘nice’ then I consider myself a failure.

Me-too brochureware banking

Take a look at this template.  Header and navigation at the top, large hero to the left, with three product panels beneath.   Log-in to account is on the right with information on security and help beneath.  If you want to be an information architect for a bank, it would appear this is all you need.  This is your cookie cutter to success.

Don’t believe me?  Start with Lloyds TSB.

Yep, that seems to fit.  how about Halifax.  Almost the same grid being used there.

Can’t be coincidence can it?  Let’s look at HSBC… There’s the hero again. And the three content boxes. And internet banking on the right.

This is getting a bit repetitive.  What about Santander?

There’s a pattern going on here. Looks like they are all at it! Does any other industry segment from such ‘me-too’ism? If it was the right model to be using it wouldn’t be so bad, but their consistency is around consistency of what they do. No-one is really thinking about the customer and what they want. Barclays gets close, but there’s little in the way of understanding customer needs and goals. Little to support customer journeys. It’s all about the Bank, with Products and Services. And Access your accounts on-line! (And ‘We’re so complicated we need help on our home page’). And if everyone else does it obviously we are doing The Right Thing. Does this matter? Isn’t there a better way to design a bank’s brochureware pages?  I’m looking for examples.  I fear I’ll be looking for a while.

Usability and the $1 trillion mistake

Is this a case of fat fingers, a usability flaw or poor design that enabled a Citigroup trader to have placed an order to sell $16 billion, instead of $16 million? P&G shares plunged by 23% because of this individual erroneous trade. What followed was the algorithms kicked in and automated trading saw the Dow loose a tenth of its value in less than half an hour. (And Accenture dropped to 4 cents down from $42!)

Before we go blaming human error, questions should be asked why that error occurred. How can someone make such a simple mistake so easily? Was it a case of entering two many 0s? (Don’t stop to look or think, answer the question as soon as you’ve read it – how many zeros are there in this number? 160000000. Same thing again, how many zeros are in this number 12,000,000. That’s a bit easier isn’t it. Only an ‘N’ separates the B from the M on a qwerty keyboard, in a hurry, easily mistaken?)

I’d start by looking at human factors and experience design, and question why (assumption here) the IT team who implemented the system didn’t have before a UX designer on the team to think about the human factors. Could this be the most costly example of poor design?

Article: Big drop, was it all a mistake?

Where would your customers stick yours?

Opposite me on the train sits a man woking on his Lenevo lap top.  The Lenevo logo is small, on the top right handside of the lid.  Taking pride of place, in the middle of his lap top lid is a large Apple icon.  I’ve seen this before, people with Dells sticking the Apple sticker on the back or by the mousepad.  Genius thinking by Apple, to include their logo sticker in product boxes, getting customers to promote their brand on competitors products.  Enabling people to make a statement; I’d rather have an Apple, but work gave me this lousy windows machine.

If you gave your customers your brand logo, where would they stick it?

Follow fast

I’ll pick on a random industry. Let’s say you are an airline. Part of your digital strategy includes a refresh to your website (maybe you were inspired by this presentation I did a while ago on digital for airlines!). You’ve built a business case and secured funding for the project.  First things first, you get a design agency in and set them to work.

Some sort of competitor analysis is performed that proabably includes features and functions that “we like”, (for example ‘the tactile sliders in kayak.com. We like!  And an iPhone-like coverflow, got to have one of those…)

The information architect takes these ideas away and starts building wireframes and the creative team produce designs that bring these wires to life.  The team come up with lots of new, innovative ideas.  This is after all a ‘refresh’, and ‘innovation’ was probably one of the words in the brief.  The creative is fresh and ‘of the moment’, the IA has developed some new interaction models that are unique and compelling.  The business is sold on a new, innovative way of interacting with their customers, something that no one else does and will blow all their competitors away.

I’ve been bouncing ideas around with Luke Barrett (and because he doesn’t blog, I’ll write them down for him) around this approach; specifically the value of innovation against ‘follow fast’.

Luke reminded me of a project we worked on together many years ago. Before we started designing webpages we did usability testing. We did usability testing of the competitors, and of sites that were getting a lot of press as ‘innovative’.  This was at a time that boo.com had just started and the client were talking about how cool an avatar would be on their site, just like boo. We put people in front of boo.com and watched them suffer. Clearly the avatar was an idea good on paper, terrible on execution.  So we killed it.  Not on our site.

We observed what worked and what didn’t on a multitude of sites with real users. Then, like magpies, we took what was good and worked. Nothing particularly innovative, (let other people do that), we took the best of what existed and delivered on that.

So back to our airline. How about a different approach where they start by usability testing their competitors. Ask participants to book tickets on competitor websites. Understand what interaction elements work, what don’t.

Those kayak sliders, cool for geeks (maybe), but how about the target audience that flies and buys online with you?  It may not be cutting edge design, but Does a drop down work better?

The coverflow may be cool on your iPhone, but how successful is it for people seeking a holiday?  A static list has worked for websites till now (and it wasn’t so long ago that horizontal scrolling was the Great Taboo), just because Apple do something that looks cool for a particular purpose on their products, doesn’t mean you have to follow by scrapping your navigation.

There are no prizies for (design) innovation (other than for some award that the design agency may covet). The only metric that counts is conversion rates and the ability of the website to deliver the business case. Leave others to do the crazy innovation stuff, let others go through the dip when they launch new features, make sure you have got the platform and expertise right and be ready to follow fast.

Who would turn off the wrong engine?

In designing user interfaces there’s a lot we can learn from systems where failure to consider human factors has resulted in terrible consequences.

On 8th January 1989 British Midland Flight 92 crashed whilst attempting an emergency landing. There had been a fire on one of the engines which led to its malfunction. The captain reacted by shutting down the engine.  Only he shut down the wrong engine. With no power, approaching East Midlands airport the captain manged to glide the Boeing 737-400 to avoid Kegworth village but crashed short of the runway.  47 people died.

The investigation into the Kegworth air disaster identified engine malfunction (the engine used in the aircraft was an upgrade of an existing engine and had not been field-tested) as causal factor, however the report concentrated upon the failure of the flight crew to respond accurately to the malfunction.  Human error was the primary cause.

The truth is a little more complicated than that.  Why does a captain with over 13,000 hours flying experience and a first officer with over 3,000 hours experience shut down the wrong engine?

A number of human factors contributed to the disaster including organisational issues (refer to this paper for discussion of the role of managerial failures in disasters) and cognitive overload.  But of equal importance (and indeed buried in the appendices of the Investigation Report appendices) is the issue of design. Around 50% of accidents and incidents in the aircraft and nuclear industries have a root cause in design (source).

Take a look at the cockpit controls (taken from the investigation report). The left image is for the earlier 300 series and the right for the 400 series aircraft on which the captain had only 23 hours experience after a one day training course.

The actual cause of the engine malfunction was a broken turbine, itself the result of metal fatigue caused by excessive vibration (source).  Had the Captain noticed the Vibration Warning display he probably would not have made the wrong decision.

The Vibration Warning display on the new 400 series was in a different place to the 300 series, but more critically it was designed to be significantly smaller “the dial on the vibration meter was no bigger than a 20 pence piece and the LED needle went around the outside of the dial as opposed to the inside of the dial as in the previous 737 series aircraft” (Source: Wikipedia).  Take a look at the arrow on the left hand image, the display dials on the 300 series use mechanical pointers. On the 400 series they were redesigned with short LEDs rotating around the numbers. These, as the investigation report noted “are much less conspicuous than mechanical pointers, acting more as scale markers, and providing less immediate directional information).

The report criticised the layout of the instrumentation and helpfully suggested an improved layout.  The layout was (and as far as I can tell, remains in 737s) split into primary instruments and secondary instruments.  The issue with this layout is that the dials are not spatially aligned with their associated power levers.  If the pilot is focussing upon the primary instrumentation, the secondary instrumentation is in peripheral view.  This layout will lead to attention based around specific instruments rather than engines.

Compare this to an alternative design that the report provides where the dials are aligned to their associated power levers.  The report recognises the design trade-offs here but concludes that to break the left-right mental association with the engine position was probably not the most optimal solution.

This paper describes the issue well:

The 737 involved in the East Midlands crash had flight deck engine information that lead to confusion under mental pressure. Placing the secondary information sets for both engines to the right of the primary set broke the implied rule set by all the other engine information, that the left engine had left hand controls and indicators (and vice versa). If one assumes that the optimum positioning of indicators is the one that requires the least mental processing then a simple symmetry about the aircraft centre line seems appropriate. The actual positions required a mental spatial transposition of one set of dials to the other side… The readability of the indicators had been reduced by the substitution of electro-mechanical readouts with electronic readouts, but which simulated the old design. Possibly the redesign to electronic readouts should have taken the opportunity to use a rather different layout, possibly with linear indicators rather than rotary ones.

OK, so lots of words, but what is the point of this to what I usaully blog about?  The issue is one of design and layout and who’s responsibility is it.  In designing user interfaces UCD is often seen as a luxury, developers believe that they can design a GUI as well as anyone, and stakeholders (especially on internal projects) will question the value that a UCD person can bring to the project.  Does a developer or an engineer by training and instinct stop to ponder the human factor and the human consequences of the GUI layout? What are the consequences of this?  As can be seen from Kegworth, seemingly minor changes to the control layout can have a signficant impact on the safety of a complex system.

Put some fun back into your business

Litter bins on the street aren’t the most interesting of objects.  The design is pretty standard, with variations on a couple of themes – cylindrical or rectangle and colour being the primary tool of differentiation.

“To throw rubbish in the bin instead of onto the floor shouldn’t really be so hard. Many people still fail to do so. Can we get more people to throw rubbish into the bin, rather than onto the ground”

One answer is to make it more fun.  Check out The FunTheory for other ways of improving mundane products by making them fun.

Now think about that mundane product of yours.  Maybe it is your on-line retail bank.  It is getting tired and it is time for a technology refresh.  You’re going through a process of capturing requirements.  How about playing an innovation game, but base it on the concept of fun.  What could you introduce to your product that would make people smile?  What would make people laugh?  OK, so after a while the bin would no longer be fun.  What makes it fun is the element of surprise.  Again, what could you drop into the product that would surprise people.  What would a ‘fun’ internet bank look like?  Focus on fun and surprise and you might uncover a nugget of inspiration that will make the final product.