Web design

Some one forgot to ask the critical question…

Some one forgot to ask the critical question,

What is the likely traffic that will hit our site during the offer and will our system be able to handle it?

Dr. Pepper said that they’d give a free Soda to all Americans if Guns’n’Roses released their new album this year. They did and the drinks company held up their promise, setting up a website offering a free coupon for 24 hours (if you signed up). They turned a throw away comment to their advantage and this could have been great PR. Only they didn’t predict the volumes that would hit the site, it couldn’t handle the traffic and went down for most of the day. Cue panic extension of the offer, unhappy customers, unhappy Axel Rose, PR disaster and lawyers on the prowl. If only they’d remembered to think about NFRs.

Are you experienced?

“For you who have had the experience, no explanation is necessary. For you who have not, none is possible.”

I’m going to attribute that saying to Ram Dass, a Harvard professor who via psychedelic experiences ended up a spiritual teacher in the Eastern Tradition.

The problem with too much software/web design is that it is produced by people who have just not had the experience, or do not see the experience as relevant to their organisation or domain. They just don’t “get it”.

(“For you who have an apple product, no explanation is necessary, for you who have not, none is possible?” Cue “it’s an enterprise application we’re buiding, not a ****ing iPhone”).

If we want to build memorable and compelling products, we need to focus upon the experience. To dwell on the feature list or functional requirements is to build mediocrity. Nothing wrong with mediocrity if you don’t want to delight your customers or increase the performance of your workforce. Without considering experience you will miss innovation and added value.

So how to focus upon experience? Get your team to undertake different tasks to get under the skin of what customers go through.

Telco product?
Spend time in a retail outlet and watch different customers buy phones
Go into all the phone shops on the high street and ask the rep “hello, I want a mobile phone”. Suspend all your knowledge about phones and tariffs. How do they sell?
Leave your blackberry at home for a day (how dies it feel? How does it change what you do?)
Download instruction manuals from different phones from manufacturers websites

Travel product?
Go into a travel agents and ask for a holiday “somewhere hot and cheap in February”

Credit card product?
Ask to borrow money from someone you don’t know (how does it feel?)
Apply for a credit card at another bank
Collect all the Credit Card / loan direct mail and emails that you and you get sent over a week, photo / scan all the credit card advertisements you see in a week
Go into a car sales room and look to buy a car on credit

Supermarket product?
Get behind the till for a day (In the UK, at least a few years ago, all senior executives in both Tesco and Sainsburys spent time in the stores over the Christmas period)
Ask a shop assistant to help you find an obscure product that is not in stock
Go into a store with a shopping list and a single bank note, (no credit cards)
Go to the pharmacy when it is busy and ask to buy the morning after pill

Extend your team
Bring in representatives from completely unrelated parts of the business to participate in brainstorming sessions. Building a “youth” social networking website? Get someone from legal or corporate finance to join in. (Get’s you thinking along the lines of extreme characters – here and here [pdf]). Working on a complex exotic financial instruments? Get a few PAs to join in. You may learn something (that your product is too complicated and even you can’t explain what it really is).

I’m sure you can come up with better exercises. The object is that with this collection of experiences and related emotions new ideas can be brought to the table. They can offer insights from another, different perspective, providing more chance of business innovation being realised. More importantly, if you have an emotional attachment to the product you are building through real experience, you are more likely to build a better product that will fullfil the needs of and goals of the target audience in the way they want. The day your enterprise application team all have iPhones will be the day you start building better enterprise applications. For them, no explanation will be necessary. They’ll just “get it”.

Front of wallet

Credit card companies talk about “front of wallet”. With customers having a number of cards at their disposal, how does a credit card issuer ensure that their card is the customer’s card of choice; the card they will pull out first because it is at the front of the customer’s wallet?

How do you make sure that your website is “front of wallet”? One solution is to become the wallet. In Web 1.0 many organisations tried this, branding themselves as “portals” trying to be a one stop shop to do everything. The reality was that people liked to “jam jar” their experiences. They didn’t trust one one provider who did one thing well to sell them unrelated products; that just didn’t fit in their mental jam jar. They buy insurance from an insurance site, cars from a car site. So if they wanted to buy a car they would go to Autotrader. It was not a banks place to offer car sales in their portal offering. (The value proposition to the bank of course looked good on PowerPoint, sell people cars on the banks portal web and there was a ripe market for cross selling finance and insurance at the same time).

Web 2.0 brings a new “portal” to the playground. A concept rather than a product. Thus we have iGoogle and netvibes and mash-ups. No company can become the wallet, they must resign themselves to being the cards inside. They can do this by offering rss feeds and widgets. Making their content and functionality promiscuous, divorcing it from their site and allowing the customer to consume it how and when they want it. Sadly the banks have yet to grasp this concept. Their technically savvy customers would love to have their balances and recent transactions displayed on a widget or as a feed. Sadly they listen to the masses and their inherent conservatism prevents them from such offerings, killing it with what-ifs and unfounded security concerns (“what if a husband and wife shared the home computer and the wife saw suspicious transactions…” yawn).

Anyway, so there’s Twitter. I’ve signed up to it and for a long time it just sat there I had a subscription, but out of sight and out of mind. It wasn’t at the front of my wallet. It wasn’t even in my wallet. Until I got round to putting it on iGoogle. Suddenly it is visible to me. I see it every time I log in. I get bothered by the inane, uninteresting tweets that most of the people I follow burble, but I also update my status on it (and it updates my facebook status as well). Twitter is now part of my on-line experience. It is now front of my wallet.

Unlike the banks who I visit periodically to check my balance and pay bills (in-out, no lingering). Now if my bank balance was a feed on iGoogle I’d have more of an interest to drill down into more detail. I could manage my money better. I could establish a better on-line relationship with my bank. If they gave a little away, I’d give them so much more. But for now, they are back of my wallet.

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.

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Web 2.0, retail banks and a Slide Share presentation

This is nothing new, but there are still people out there to whom Web 2.0 is a bit of a mystery. What exactly is it, and more to the point, should our business care about this stuff? Or, as I have heard senior executives argue, is it just another bubble, a distraction to let others waste their time, effort and money on. In an attempt to challenge this assumption, I’ve used a model with a few sceptical clients to hang some structure on. This is central to the below presentation that I’ve given to a few financial services organisations. It discusses what Web 2.0 is, and towards the end describes what it could mean for their on-line retail bank website. (Thanks to Duncan Cragg and Prashant Gandhi for some insights).

[slideshare id=377944&doc=web20public-1209431680446543-9&w=425]

I am not a target in a campaign

Marketing may be a touchy-feely occupation, but the language that marketeers use is far from it. Campaigns, strategy, tactics, targets… all out of the military handbook. That might be OK within the organisation, but it shouldn’t be exposed to your customers. An email sent by BA inviting customers to register to a special deal results in a page informing the customer; “Thank You, [name] Your pre-registration for this campaign has been successful”. Now what is that all about? They’ve spent so much time creating the campaign, how it fits into their overall strategy that they’ve overlooked the details around what really matters – fullfillment, wording and how the customer feels about BA at the end of the process. I feel a little cooler than when I clicked on the promotion.

BA pre-registration page

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.

Unleashing innovation at speed

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack – doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment – their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development – put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.

Confirmation – undo

The traditional pattern for the on-line banking “make a payment” GUI is:

  • What you are about to do (text)
  • Select “From account”
  • Select / enter “To account” (Beneficary)
  • Enter Amount
  • (Optional) enter “when” (you want payment to be made
  • Confirmation (“you are about to pay this amount from this account to that account. Are you sure?”)
  • Post process confirmation (“You have paid this amount to that account from this account”)

So here is a question. Are those confirmation screens really necessary. What if you made your payment, hit the “OK, make the payment” button and it is done. An alert appears (like when you do something with google) that says what you have just done with an “undo” call to action (“I’ve made a mistake, I don’t actually want to make that payment afterall”). The assumption there is that the user knows what they are doing – we assume a happy path with the opportunity to go back rather than placing “confirmation” barriers to completion which are probably unread anyway. There will be considerations of when the payment is actually made; does it hit the clearing systems when the user hits the pay button (not that it ever does anyway). Does the undo option disapear after a period of time (i.e. five minutes), or when the user navigates away from the page the alert appears? But let’s leave the implementation to one side.

I like the idea of undo instead of confirmation. However, I have a hunch that it will not fly when we show it to customers, because people are so ingrained with the “confirmation” dialog. I’m waiting for the response “I’m not sure I like that” from customers who use the current website, because it different, unexpected and is wholly inconsistent with what they have today. But what they have to day is based upon legacy technology and the immaturity of the platform.

So a suggestion. Let people undo. Tell them what they’ve done after they’ve done it (positive feedback), with the opportunity (in the banking environment in a time boxed period) to rectify their errors or change their minds. Do away with confirmation dialogs. Everywhere. (Do you want to save this document? – instinctively I say “no”. It is only later that I realise my mistake…) Here’s to a web that places minimal barriers to task completion.

2 of 5
12345