dancingmango

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.

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

The user journey

“Faster, slicker, easier to use.  That’s how we sold it to the business.”  It is a common theme, IT have a system that is costly to maintain, hard to extend, is on a dated platform and no longer fit for purpose.  The business are persuaded of the need for a replacement.

This is what happened at an organisation I recently visited.  But it didn’t quite go to plan.  A number of years later and they’ve got an application that is slower, uglier and harder to use.  What happened was the business intent was distilled into requirements (based upon the existing functionality).  Each requirement was captured as a control on a screen.  These were bundled up and sent to India for coding, and the developers went and built a bunch of screens.  They considered interface design but not interaction design.  They focussed upon technical processes rather than user journeys and the resultant deliverable was something that functionally ticked all the boxes (it did what the specifications said it should do) but was ultimately rejected by the people it was intended to help. The code may have been great but that meant little to the business who found the application a pig to use.  Another failed multi-million dollar IT project.

User interface design is more than just screen design, it is about the journey the user takes to accomplish their goals.  Remembering that could have saved this particular organisation a lot of money.

Where are the missing floors?

It is fairly standard practice in Hong Kong for buildings to have no thirteenth or fourteenth floors. They are considered unlucky numbers. Not sure what happened to the first, second and fifth floor here. And back-to-front button numbering that is neither in the telephone format nor the phone format. There’s a couple of lessons to learn here; when designing human-technology interactions consider cultural norms and existing design stereotypes. (Sorry, its the Human Factors conditioning in me that notices such things).

Cross cultural considerations at the Sandwich bar

In their paper Content preparation for cross-cultural e-commerce: a review and a model, Liao et al. conclude that (1) Westerners pay more attention to information about product components or contents than East Asians and (2) East Asians pay more attention to information about price… than westerners. This is in the context of eCommerce in “present[ing] appropriate information content to facilitate consumers’ decision making”.

A practical example of this in the bricks and morter world can be seen at this Sandwich bar in Hong Kong.

Clearly modeled on the western way of buying sandwiches, the counter layout supports the customer selecting the product (sandwiches and fillings on display) moving on to the cashier at the end of the counter to pay.

This isn’t the way things are done in Hong Kong where money comes first before the product. “Please place your order at the cashier”… before dwelling in front of the display cabinet. This results is congestion around the cashier counter and poor workflow and a slow and tedious customer experience.

Sandwich bar or internet offering, consider cultural differences before transferring the concept and content.

Let common sense prevail

Me: “Hello, I’d like to book a flight back to London on Thursday please”.

BA: “Certainly. BA 28. Midnight Thirty Five.”

And that was it. No friendly warning, so close to doing this again.

If I ask for a flight on Thursday, common sense suggests that the fact that the plane is scheduled to depart 35 minutes into Thursday, and I need to be at the airport at 10pm on Wednesday, then it really isn’t a Thursday flight. Not being explicit and clear with this is rude business.

The scourge of Document Driven Design

Documents, or rather words are the scourge of product design. Because words can never convey the true meaning or emotion of what is really required. All to often, software development projects are driven by the documentation – agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is. Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal. Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction. “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on. Issue #2. The desired outcomes become lost in a smog of technical jargon.

Solution: Picture Driven Design. Up front. Yeah! I’m all for up front design! A picture tells a thousand words. It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like. Start with a day in the life of… scribble out the flow, the user journey. Nothing complicated, boxes and arrows. Then scribble out what the user interface might look like. Done. That’s your up front design. That’s your documentation. That’s your scope. What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want. I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture. I’m convinced it will save much pain later on.

CAPTCHA: a barrier to entry

When a customer starts completing an application or registration form it demonstrates they are committed. It therefore makes sense to pay attention to the usability of that form. But how often is the content of the form considered? Are there content barriers in the form that prevent customers from completing it?

Marcelo Calbucci (Via Luke Wroblewski) describes a barrier that everyone assumes just has to be there so it is not tested: The CAPTCHA. When the team removed the CAPTCHA from the Sampa.com registration form they recorded a 10% increase in conversion rates. Marcelo writes “we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time” (interestingly when I looked at the page I got the CAPTCHA). A 10% increase in conversion is not insignificant, and probably more than outweighs the additional effort to implement an alternative solution.

Does enterprise IT know what Google is?

Imagine an investment bank, a trader has a requirement for a tool to screen stocks. The requirement is to select stocks based upon different parameters, so for example find companies with a market capitalisation between a selected range, and a P/E ratio, Dividend Yield and Net Profit Margin between other selected ranges. And maybe the ability to add additional parameters.

Typically the process will be for these requirements to be captured by the Business Analyst who acts as the conduit to the development team. Nowhere is the user interface explicitly referenced – it will almost certainly be articulated in the reality of the current systems; what the BA knows and understands. Despite the iterface being delivered through a browser, the developers are not web developers. Inevitably the finished product will be functionally correct, it meets the requirements, but it will be clunky: select parameters > search > results… because it reflects the requirements as the trader put them “I want to do this and this and this, press a button and get a list back“.

So what are the chances of an internally developed investment bank application looking like Google finance’s Stock Screener? And what would your trader rather have?

Consistency when things are poor

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency – for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal – do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel – a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this – the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture – the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

Search can be a beautiful thing

Is there any reason to navigate around the Apple website using traditional navigation mechanisms when you’ve got search functionality so elegently implemented?