There once was a time where the honorable thing to do if you screwed up was to resign. No more it seems. Times change and to resign is to walk away and admit defeat. Defeat is something our culture doesn’t honor; no-one likes a loser. So you ignore the critics and stay on; you know what went wrong, so you are the best person to fix what you broke. The honorable thing is no longer honorable. Failure is rewarded, and we just carry on as if nothing happened.
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.
Recently I was told of a Blue Chip company whose IT organisation, in the guise of cost cutting, has recently disbanded its QA function. From now on, testing will be conducted by the developers themselves. Since when have developers relished the role of testing? It is inevitable that this cost cutting solution will end up costing the organisation more than it saves.
At the end of last summer I was working with a bank on their on-line retail banking strategy. During a workshop with representatives from their mortgage business they made it clear that they saw the biggest sector for growth in 2008 was the buy-to-let market. I left the workshop shaking my head, were they not reading the same newspapers I was? Even then I didn’t need a crystal ball to tell them that they were putting their eggs into the wrong basket.
Clearing out old paperwork, I came across a document describing the technology strategy for a blue chip organisation that I’d worked with in the past.
There is a guiding principle that is being applied to product technology selection that says we do not follow a ‘best-of-breed’ approach, but rather select a major technology leader (IBM) and ride their product development cycle. This means we explicitly seek and accept the “80% solution” rather than trying to optimise for each and every possible requirement. [We are] emphatic on this point. What this means in practice is that, following the selection of IBM WebSphere Application Server… add-on functionality should be sought from the IBM WebSphere family of products first. Shortcomings will be made explicit in order that we can escalate with IBM, and influence their product strategy.
No rationale was given for their preference for going with a single vendor rather than a best of breed solution, but talk to developers who have used best of breed products and the above mentioned vendor product and they will almost certainly come down on the side of the “best of breed” (that is why they are best).
During the dot-com boom I worked with bank who were developing a WAP mobile banking platform. Trouble was it could only be accessed via a Nokia 7110 (the first mobile phone with a WAP browser), the experience sucked – “Worthless Application Protocol” and the market penetration was never going to reach beyond the most hard-core (and GUI-patient) of early adopters.
At the time the same bank was intent on closing as many branches as possible – branch banking was considered unprofitable; on-line was the way forward… yet several years later I was back in the same bank helping them with their in-branch customer experience.
We all must have examples of times when we have shaken our heads and asked of others do they really know what do are doing? Whose interests are their decisions in aid of? You may not be able to do anything proactive about it at the time, but the question is, what can you learn from these encounters and how can you use them to teach others in the future.
You went to the local branch of your bank and spoke to a really helpful person there. In the few minutes you were with her you established a relationship with her. You felt comfortable and confident that she would take ownership of your request. But before she could deal with your query, disaster! You left some critical information at home.
Can I email it to you later you asked her?
Silly question.
Have you ever tried emailing someone in the branch network? Chances are the frontline staff don’t have external email. What sort of business is it that doesn’t give its staff email and the ability to communicate on a personal level with its customers? the same sort of business that has centralised all its customer contact and put it behind IVR.
So you give up on email.
Can I give you a ring with the details later you asked her?
She shakes her head. She doesn’t have a number. you see the branch doesn’t give out its number to the public. Go through the 0845 central switchboard, and let someone in the call centre pass a message to the person in the branch. (With no formal process to get this to happen, good luck if your messages ever gets passed on).
In fact the only way you will probably get a message to the person you talked to this morning is if you send a fax. One step removed from the telex, two away from the telegram.
What is it with the banks that they don’t want their staff to have external email access?
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]
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?
Someone from the Barclaycard research centre rang me today doing some customer research. It is great to know they take the customer experience seriously – many of the questions were around my experience with the brand. But then they dropped this corker, not once, but twice.
To what extent do your other credit card providers offer innovative products
How important is it to you that your credit card provider offers innovative products
How on earth did those questions get through and on to the list? What is an “innovative product” when talking about credit cards or financial services? What is an “innovative product” to Joe Public? Maybe I can relate to an iPhone as such, but my credit card? Product innovation is hardly something that you or I consider when we pull a credit card out of the wallet.
“Innovative products” are something that marketeers talk about, they are not in the credit card users lexicon.
In the real world, when I get an application form I’ll flick through the pages and have a look at what is required. I can choose which fields I complete in whatever order I like. If I want to take a break half way through I can. I can complete it when I like and how I like.
So why aren’t web forms like that?
The usual format for a web form starts with some copy that describes the form (which people skim through at best). The user clicks to the next page and the form commences. There may be a step indicator showing progress through the form, but almost certainly progress through it will be linear. You have to complete each page before progressing to the next. If you are lucky you’ll be able to click to previous completed steps. But the experience is nothing like a real-world form. And when was the last time a real-world paper form “timed out” half way through, demanding the user to start over again if they left it idle for ten minutes?
The web forms we see today are a relic of their tecnological past. There is no reason why they must be linear, (and if there is logic in the form, there is no reason why the user can’t explore the different routes – you do that with a paper based form). There is no reason why the user can’t click to whatever page in the process they like (just like with the paper form). There is no reason why a page must be completed before progressing to the next. There is no reason why the form should time out and forget everything the user has entered. Fields can be saved as they are completed against an anonymous user, until the user wants to provide personal credentials.
Bottom line – the web has moved on. Instead of reflecting technical constraints of yesterday, it can adopt more real-world metaphors. But do we have the courage to start introducing new paradigms? Are users, information architects and usability experts so ingrained with broken web metaphors that they will shun a new model, (a real world model) of completing a form?
So here’s a rough example. It’s an application form for a savings account. Ignore the content, field labels etc, it is more the model that is illustrated.
1. The user can move between the sections (tabs) to see the fields that are required. There is clear feedback on each tab that it has not been completed. The “Direct Debit” section is optional hence no indicator. The ability to save the application is seperate.
—
2. The user selects “Bank details”. They’ve not filled out all the fields on the first tab “Personal details”, but it doesn’t matter. There is clear feedback that this tab is yet to be completed.
—
3. The user clicks right through to the confirmation tab. There is nothing to confirm so the page remains blank, with a prompt to fill out other sections.
—
4. When sections are completed the indicator on the tab changes to show completion. Here the user has completed step two ahead of step one.
—
5. Finally, when all sections are completed the user can review the entire form.
I’m not saying this is perfect, it’s a start. A start to re-thinking the way we design forms on the web and think about modelling them on real world behaviour instead of technical constraints of the past.
Walk around London and it’s hard to miss the Maestro “Cash Is Dead” advertising campaign. You’d never believe this in many small bricks and mortar retailers; try to purchase something with a card for say £7.99, pull out the plastic and the shop keeper shakes his head and points to the sign – “no card payments for under £10”. What sort of madness is this that retailers refuse to accept money because it is the wrong sort of money?
OK, so there are interchange fees; a card payment is probably going to incur a charge of around 2% of the transaction. For the retailer there is therefore an incentive to prefer cash. But at what cost? (Perversely for the banks they penalise against not using cash, despite the handling for cash being so much more than an electronic transaction).
Let’s say I am buying something for £7.99. Let’s say the cost price for the item is £3.50. That’s £4.49 gross profit. Obviously this doesn’t all go into the retailers pocket; the tax man takes his share in VAT and there are the operating costs. I’m no retailer, but let’s assume that a whopping 90% of the gross pocket is swallowed up in costs, leaving the retailer 45 pence net profit. Now of this, the bank is going to take 15 pence from the retailer for me using my card. Which the retailer is not happy about.
And this is the mad part; for the sake of 15p the retailer is willing to loose the sale (OK, that is 36% of his net profit – and that is a lot, but isn’t cash flow king?). He has given me a shocking customer experience, not allowing me to buy from him this time (and I’ve got a memory – not going there again). I’ll go down the road to the supermarket where they will not only accept my card – but give me cashback as well!
There is of course, an alternative. Give the customer an option of using the card, passing on the card fee. For most customers, the opportunity cost of paying slightly more but getting instant gratification is probably more acceptable than either driving several miles out to the supermarket, or having to find a local ATM.
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.