Here is a short story of a good idea gone bad, and a good lesson for mobile application developers.
The Preamble
We find ideas everywhere. The best place to find a good idea is where you wouldn’t look for it. The dump, graveyard, museum, park or simply the street of your city at night (in other words – any uncommon place for you) may bring something that would keep you busy for the next year. Or show the pitfall to avoid, and sometimes this knowledge comes with the price.
The Case
At least once per week I am going home by first having a promenade by the night city and then taking a taxi. This time I decided to use a mobile application to call a taxi, even though the center of the city was crowded by cabs.
Every big city has such application now. If you live in London or Dublin, the most popular (or should I say – more aggressively promoted) is “Hailo”.
At the moment, I’ve seen at least 30 taxi cars nearby, and accordingly to the app’s interactive map, none of them had the application installed, so I had to wait couple of minutes for taxi to come. And I used that time to give the application the details of my credit card.
So, here how it was – I expressed the need for a taxi, and then entered the credit card data. Before I could say “what the hell?”, application reported, that taxi is coming. When did I say I agree to call the taxi? That was the third time I used that application, and I remember I had at least 3 questions when I was about to pay by cash. My user experience was crushed.
And here comes the lesson number one: when you have two different workflows for your customers depending from whether you control their money or not, you are loosing trust. If someone became your paid customer, he should count on the same level of treatment and safety as before – with additional features, without obstacles, but the same scenario. If your application sells books, you shouldn’t perform one-click purchase every time your customer clicks on the item. Well, you get the idea.
But as I said, I was about to do it anyway. So, in a minute or two, the taxi arrived, but the driver told me, that he got no credit card device, and therefore I should pay by cash. So I did.
A minute after I got home, I got a message, that taxi is waiting for me. A minute later I was charged the same amount I paid in the taxi by cash. But this time – from my card. The user interface of the application didn’t have any button to cancel or change anything – the application was not designed to do anything else but to call the taxi.
Big deal. The problem was not in money, but in the fact that I didn’t get the service that I paid for. And I wasn’t asked whether I agree to authorize the payment. They could easily take any charge they want without ever asking.
So, the lesson number two: even if you’ve created something that works well in good conditions, once you charge your customers simply based on the fact that they submitted the payment details, without giving them a chance to cancel the payment… You’re done.
If you’ve paid by PayPal, you’ve noticed how many times you were asked whether you really want to pay. The same is everywhere else. Failing to conform to the standards set by other players in the market will cost you the market eventually.
Better yet – ask more questions, so customers will be aware of everything that happens and pretty sure that everything happens because they wanted it.
Lesson number three: you should abstract from the real world and concentrate on feelings and emotions of your customers, as well as to not count on their analytical skills if you don’t possess them yourself. In this case, the payment was done by credit card between customer (me) and the service, but it was not the credit card payment between the service and the executor of the service (driver). Yet it was named “credit card”, which led the executor to think that I would pay him by credit card.
Do not forget about the context, and if it’s too complex to explain in one sentence, invent your own term, so it wouldn’t blend with the existing experience of your customer.
Conclusions
There are few conclusions to make of this case, depending from the context.
The conclusion for the mobile application – it was made by people with poor analytical skills and no usability experts involved. This led to the case when not all scenarios are designed and as the result – some scenarios would impact your brand. If someone would steal your database – hackers would be blamed, or your infrastructure administrator. If your application would (help) steal from your customer – all trouble will be yours.
Conclusion for the mobile platform, believe it or not, is that Google Market is really not the safe place. Not remotely as safe as Apple’s iTunes, even though the latter doesn’t check for logical “bombs”, like inability to say “no”. Applications are not checked for potentially mean behavior and so the only advice I could give – never ever supply your credit card information to any mobile application. Because the Achilles feet could be either in one of the underlying technologies or the design of particular application, and you wouldn’t know until it’s too late. Android, for one, is not mature enough to say that your data won’t be compromised. But even if it won’t be compromised, you can’t say the same about the particular application. Because it was created by relatively unknown publisher, who is not responsible for any inflicted damage.
Microsoft’s Market, on the other hand, is different. They do check your application and even the automated phase is thorough enough to filter out most of current inhabitants of Android Market. And when it comes to the manual check, my firm belief that applications like “Hailo” would get too many “WTF marks” (term coined by Microsoft employee), to be rejected. And it’s not because these apps look bad.
This means, that you, as mobile developer, should think not only about avoiding bad design in terms of GUI, but also about bad design in terms of general workflow and code.
This particular case added the decisive cent to the thrift-box of arguments to switch to Windows Phone 8, even though I’ll stay with HTC. There was a time when I would laugh at both ideas.
Another thing that we have to heavily think about is control over what do we charge customers for, and whether we charge them for service that was not delivered. For example, if your application is charging customer for the sent message, you must make sure the message was delivered. Or do not charge, which could also mean – do not provide the service if you can’t assert the fact of delivery. Reliability and accountability could benefit your application more than lack of unreliable features in next release.
And the most important conclusion is the design decision. Never leave the workflow design to developers and the creator of the idea. First airplanes didn’t fly well for a reason – the less people you have in the team, the more boundaries you have in design.