Archive for February, 2018

A Few More UX Hacks

Friday, February 16th, 2018

In continuation of my previous post entitled A Few UX Hacks, here are a few more UX hacks.


Problem: While they’re not cluttered, some webpages display their content across the entire width of the screen. Reading these webpages can strain the eyes.


Mercury Reader again!

Apart from stripping off distracting elements off a webpage, the aforementioned Chrome Extension renders the core content in a narrow window. This eliminates eye strain.

To check it out, take Nick Szabo’s white paper on Smart Contracts. When the man who is hailed to be the “quiet master of cryptocurrency” and rumored to be creator of Bitcoin published his epic work in 1996, responsive design was not a thing and there was perhaps no way to control the zoom width of text on a webpage. As a result, the white paper is very difficult to read at its original location in its full screen form. I managed to go through it only after I used Mercury Reader. Have a look at the BEFORE and AFTER views below and you’ll get what I mean (Exhibit 6).

Exhibit 6

While Mercury Reader removed the eye strain of reading the white paper, it couldn’t prevent it from boggling the mind, but that’s another problem!


Problem: You swipe right to go to the next page on a Nook Color. But, sometimes, you might get stuck on the same page or even be taken back a page or two after executing this action.

I think this is because a typical Nook Color is never switched off. From personal experience and anecdotal evidence, most people keep the world’s second largest selling eBook Reader – next only to Amazon Kindle – on even when they’re not using it. As a result, I suspect the Adobe Reader Mobile software used to open eBooks on the Nook Color freezes up from time to time, which I attribute as the root cause of this problem.


No, no, I won’t tell you to switch off your Nook Color – after all, its tagline is “Read Forever”!

Let’s say you’re on page 11 and want to go to page 12 when you face this problem. I suggest the following steps to make progress:

Exhibit 7

  1. Short tap the power button on the upper LHS of the device. The screen will go dark. Wait for a few seconds and then short tap this button again. The screen will light up. Once you swipe out the lockscreen and swipe right on your current page, you should be able to reach the next page. If this doesn’t work
  2. Tap the page, tap the GO to PAGE button on the bottom RHS of the page (Exhibit 7), enter the page number of the next page (i.e. 12), and tap the GO button. This should take you to the next page. If this too doesn’t work
  3. Repeat #2 but enter the page number of the next to next page (i.e. 13). This will take you one page ahead of your desired page. Simply swipe left to reach the previous page, which is where you wanted to go.

In the 100+ eBooks I must have read on my Nook Color, this problem has never gone unsolved beyond the third step.

#ProTip: If you Nook Color’s charger blows, you can find a simple solution in my blog post entitled Panic Not If Your Nook Color Charger Blows.

I hope you find these hacks useful.

If you have any UX hacks of your own, please share them in the comments. Thanks in advance.

PayTM Shows How #FeatureOrBug Can Drain Trust

Friday, February 9th, 2018

As we saw in Feature Or Bug – Facebook & Tideplus, #FeatureOrBug refers to a feature that masquerades as a bug.

To recap:

As brands increasingly adopt personalization in their communications, what you see is not what I see.

Then there are other types of differences like:

  1. What you see on desktop is not what you see on mobile
  2. What you see yesterday is not what you see today
  3. Inconsistencies in what you see wherever and whenever.

At first blush, it might seem that the discrepancy is caused by a bug in brand websites, apps or messages. But, if we dig deep, we might get the nagging feeling that the brand has deliberately caused the difference i.e. the discrepancy is actually a feature.

In that post and in the follow-on one entitled Feature Or Bug – Housing, LinkedIn, Starbucks, Et Al, I covered many favorable and neutral examples of #FeatureOrBug from Facebook, LinkedIn, Starbucks, and a few more brands.

In this post, I’ll discuss an unfavorable case of #FeatureOrBug.

Frequent users of PayTM will be aware that there are three ways of making a payment with India’s leading e-wallet:

  • Method 1: Pay with credit card and other funding sources on file. This method requires two-factor authentication according to the Indian regulator’s mandate. But, by letting you store a card on file, PayTM obviates the need to enter credit card details for each and every transaction. Therefore, the 2FA involved in this step entails less friction and lower risk of failed payments compared to the way most other brands dumbly implement 2FA “as per RBI mandate”
  • Method 2: Pay with wallet balance. To use this method, you need to top up your PayTM wallet with funds from your credit / debit card, bank account (or other PayTM users). This step does not require 2FA – or even 1FA.

  • Method 3: In case you initiate a payment via Method 2 without having enough balance in your wallet to cover your bill, PayTM automatically invokes Method 1, lets you cover the shortfall in-flight from your funding sources on file, and complete your payment in a single pass.

PayTM lets users choose their desired method of payment through the Fast Forward option located above the Proceed to Pay Bill button. Users can leave the option unchecked to let the payment proceed via Method 1. Or they can check Fast Forward to opt for Method 2. (As noted earlier, Method 3 is system-invoked).

Since I don’t like to block my money in “yet another e-wallet”, I opt for Method 1 whenever I use PayTM to pay my utility, phone and other bills. Ergo, I never check the Fast Forward option.

(#ProTip: If you pay your utility bill directly on your utility company’s website with your credit card, you might be slapped with a Surcharge. Instead, if you use PayTM to pay the same bill with the same credit card, PayTM will eat the credit card processing cost. Not only will it not levy any surcharge, PayTM might even give you a cashback. The double benefit is a form of what’s commonly called “VC Subsidy”. In addition, you might find PayTM’s UX better.)

There’s one exception to my overwhelming preference for Method 1: Uber. When #CurrencySwitch caused a huge cash crunch a little over a year ago, I’d to go cashless for my taxi rides. At the time, the only cashless payment method supported by Uber was PayTM wallet balance and I’d to live with it. Since then, I’ve been keeping some balance in my PayTM wallet to pay for my Uber rides via Method 2.

I recently headed over to PayTM to pay a mobile phone bill. As usual, I opted for Method 1 and left the Fast Forward option unchecked. I clicked the Proceed to Pay Bill button and kept my credit card CVV and VbV password handy. However, this time, the website didn’t ask me to enter these two pieces of information. Instead, it made the payment from my wallet balance i.e. PayTM used Method 2.

In short, I opted for Method 1 but PayTM overrode my preference and used Method 2.

I asked PayTM Customer Care if this was a Feature or Bug.

PayTM CC claimed that I must have checked the Fast Forward option, that’s why PayTM took money out of my wallet. I countered its claim by producing the following screenshot.

PayTM CC then came back with a different explanation saying that, as long as there’s enough balance in the wallet for a payment, the company had initiated a new practice of pulling money out from the wallet regardless of whether the customer has checked the Fast Forward option or not. So this was a Feature, not a Bug as it appeared at first blush.

In effect, PayTM told me, “we will take the money from your wallet even if you don’t want us to touch your wallet.”

Now, that’s called pickpocketing in plain English.

PayTM justified its use of Method 2 on the grounds that it expedites the transaction. Since Method 2 does not require 2FA – or even 1FA – it does expedite the payment.

But it’s still pickpocketing, just carried out electronically.

I see no difference between PayTM and a supermarket cashier who ignores your request to pay by credit card and pulls out cash from your leather wallet under the pretext of expediting the checkout process.

And PayTM’s patronizing assurance “you can always add money to your wallet” is like the aforementioned cashier telling you, “You can withdraw money from the ATM outside the store to replenish your leather wallet with cash”.

After this incident, I started wondering, if PayTM fools around with my wallet today, what will it do with my cards on file tomorrow.

As noted in my previous post, since any #FeatureOrBug is introduced by the brand owner, it must favor the brand.

I got thinking about how this specific #FeatureOrBug benefits PayTM.

I could think of the following possibilities:

  1. PayTM acts as the Merchant of Record in Method 1 and incurs MDR cost, which is reportedly 1.5%. Since it doesn’t slap any surcharge on the payer, PayTM eats this cost. The company avoids this cost by resorting to Method 2
  2. Monies loaded on PayTM wallets didn’t earn any interest in the past. Now, they do: Wallet balances have been moved to the newly created PayTM Payments Bank and, like other banks, PayTM pays interest on them. In Method 2, PayTM exhausts wallet balances faster and thereby reduces its interest burden
  3. By skipping a trip to the credit card rails in the case of Method 2, PayTM uses less computing power and bandwidth, and hence incurs lower infrastructure cost.

All benefits of Method 2 to PayTM are related to lower costs.

Amidst pressures from its investors to reduce its mounting losses, the VC-funded PayTM is justified in taking steps to cut costs.

But not picking pockets.

I think a better approach would be for PayTM to remove the Fast Forward option and make it clear that it supported only one method of payment i.e. Method 2. I can then decide whether to “take it or leave it”.

But, to give me the choice and flagrantly violate it is a breach of trust.

As a result, I began weaning away from PayTM – I now use it only to encash the aforementioned “VC Subsidy”.

Regular readers of this blog would be familiar with my frequent rants about the friction and poor CX in banking, not to mention the nickel-and-diming resorted to by banks from time to time.

However, not once during the course of my dealing with over a dozen banks in half a dozen countries in over three decades have I doubted the integrity of a single bank. (Knock on wood!)

With PayTM, that happened with a single transaction.

Thanks to this incident, I found out that Uber India has changed its method for accepting credit card payments. While the novel workflow complies with the regulator’s 2FA mandate, it considerably reduces the friction caused by having to fiddle around with CVV / VbV / OTP at the end of a taxi ride. Soon after making this discovery, I switched the default payment mode on my Uber app to Credit Card from Paytm.

If there’s a lesson in this for PayTM and all other fintechs, it’s the old saying about how trust is hard to gain but easy to lose.

Flight Delay Insurance – Why Blockchain?

Friday, February 2nd, 2018

I covered two Blockchain flight delay insurance products in AXA Fizzy – The New Kid On The Blockchain and Atlas Etherisc – Another New Kid On The Blockchain.

In this post, I’ll address the “Why Blockchain?” question.

Here’s a quick recap of the background to this question from the first post:

…the techie in me started wondering what stopped someone from developing a similar flight delay insurance product on a traditional centralized database architecture… Is there any intrinsic shortcoming with a centralized database architecture that compels one to launch this product only on the distributed database architecture facilitated by Blockchain?

I’ll first examine what AXA Fizzy and Atlas Etherisc say on the subject and then share my thoughts.

Given below is an extract from the FAQ section of AXA Fizzy’s website:

FAQ: Why does Fizzy use Blockchain technology?

When you purchase a policy, fizzy writes the transaction terms (price, compensation, expected time of arrival, arrival time to trigger compensation…) on a blockchain called Ethereum. The interest of the blockchain is the inability to remove previously-written transactions. What’s more, the Ethereum Blockchain is public, any crypto developer can therefore check the validity of the information we store there. fizzy doesn’t ask you to trust it, rather proves it through trustful processes. Last thing, we never share your personal information on Ethereum, your data is safe with us.

FAQ: What if I don’t agree with the delay reported by fizzy?

fizzy is based on redundant data which enables us to trust its reliability. Besides, as we are a party to your insurance transaction, we made sure that the payment of your compensation is not decided by fizzy but directly by the plane data provider. You don’t have to trust our honesty! In spite of these measures, you can contact us through the contact tab in case of any problem. You can also find here information on the EU Online Dispute Resolution:

I didn’t find any justification on Atlas Etherisc’s website for its decision to use Blockchain.

Addressing the potential buyer of its insurance product, AXA Fizzy’s replies emphasize Trustlessness, which is one of the two low-hanging fruits for a Blockchain decentralized app (Robustness being the other).

As one such prospective customer, here’s what I think about AXA’s replies:

  • I need to trust fizzy to write the transaction terms on the Ethereum Blockchain. Going by my experience with Atlas Etherisc, this is a non-trivial step
  • The Ethereum Blockchain was rolled back after DAO hack. Therefore, I don’t agree with fizzy’s claim that previous transactions are immutable on the Blockchain. While it could be argued that hard forks leading to rollbacks are very rare in the Blockchain world, point is, when they do happen, they’re driven unilaterally by a very few people who resemble a secret cabal in which the average Joe / Joanne Customer has no say
  • An average air traveler is not a cryptodeveloper, so it’s not very useful to know that “any crypto developer can therefore check the validity of the information we store there”
  • I may not need to trust AXA after fizzy has written the transaction on the Blockchain but I still do need to trust its Flight Data Provider (whoever it is).

Prima facie, the claim of trustlessness lacks depth.

The shallowness of the trustlessness value proposition is reinforced when I compare these two insurance dApps with a conventional insurance product running on a centralized database architecture (herewith “cApp”):

  • Once I buy the policy, I get a policy document. I can take a printout to prove the transaction in case the Insurer tries to change it later. Besides, in my experience of buying dozens of insurance policies in four countries over three decades, not a single insurer has ever changed the terms of the policy after issuing it (not saying they won’t in future, though)
  • I don’t need to be a cryptodeveloper to understand the basic terms of the policy. Even an average air traveler can understand parameters like price, compensation, expected time of arrival, arrival time to trigger compensation (of course, even a cryptodeveloper won’t be able to understand the fineprint of an insurance policy).

I know Blockchain is evolving. But, at this juncture, it’s hard to accept that either of the two flight delay insurance dApps I’ve encountered exhibits trustlessness.

And I’m not alone. As btcethereumadmin says here:

“Even an open-source project like Bitcoin that is constantly being reviewed can have trust issues, not from the code but by the developers and reviewers of the code. So trustlessness is more of a term describing an ideal state on the blockchain where code is law with the caveat that humans write code and to err is human.”

And to forgive is not divine – at least not to IT services companies who make tons of money from SIT, UAT and other testing phases of a software project!

Technology is full of X-less movements e.g. ebilling drives paperless billing; digital payments drives cashless societies; and digital channels drives branchless banking. Most of them have failed at their X-less mission. But they’ve created an X-less outcome e.g. less paper, less cash and less branch in the case of ebilling, digital payments and digital channels respectively.

I was about to conclude that Blockchain is another such movement that will begin with trustless and end with lesstrust.

That changed when I saw the following screen on the Atlas Etherisc website.

Yes, you saw that right: Stamp duty for a Smart Contract!

Stamp duty comes into picture while registering an agreement with a government authority. When a Smart Contract attracts stamp duty, it belies the claim that Blockchain helps two parties conduct business without an intermediary. It appears that Blockchain insurance policies issued by Atlas Etherisc do have an intermediary, namely, the government of Malta.

Based on this experience, a smart contract not only calls for trust in technology but also requires the blessings of a government.

This suggests that Blockchain demands more trust than a centralized application.

I know this sounds like a sacrilege to Blockchain purists, so I’m bracing myself for a few brickbats from them in the comments!

Let’s move on to Robustness, the second raison d’être for Blockchain dApps.

To ensure high availability of its centralized app, a company

  1. Needs to hire DBAs to provision access rights to ensure integrity of content of central database (this is apart from having to buy server, operating system and database software)
  2. Set up ACTIVE:ACTIVE clustering to provide redundancy / fault tolerance
  3. Invest in secondary disaster recovery site for business continuity.

All of this costs a lot of money in manpower, cybersecurity tools and real estate.

I’m sure that every insurance company spends money on DBAs and cybersecurity tools to run its current cApps. However, I strongly doubt if many of them will be able to justify the high costs of #2 and #3 for a relatively low-ticket flight delay insurance system. I say this on the basis of my following experience:

  • A leading financial institution couldn’t find a strong enough business case for investing in ACTIVE:ACTIVE infrastructure even for a high value payment system
  • When floods once struck the English town in which a bank’s primary datacenter was located, I quizzed the CIO about his bank’s Business Continuity Plan. He quipped, “Mops and buckets”!

Contrast this with a Blockchain dApp. Transactions are cryptographically locked down and distributed across multiple nodes. As a result, a dApp is inherently shielded from data breaches and intrinsically enjoys extreme fault tolerance. More on this in “Blockchains vs Centralized Databases”, an excellent article from Gideon Greenspan of Multichain.

In a nutshell, you get a highly robust application on the Blockchain virtually free-of-cost. (Actually virtually free only of fixed cost. Variable cost in the form of Gas Price does apply for dApps. But that’s a story for another day.)

AXA Fizzy spins its choice of Blockchain as a customer benefit by emphasizing trustlessness. (I didn’t see any spiel for Blockchain on Atlas Etherisc’s website.)

I don’t buy it.

Based on my limited knowledge and experience on the subject, I think the real reason to opt for a decentralized Blockchain architecture over a centralized database architecture is Robustness, or more specifically, lower cost of achieving robustness.

That’s not a bad thing.

Lower cost is a benefit for insurance providers but higher robustness is a customer benefit.

This was driven home for the nth time when I had to link my insurance policies to my Aadhaar Number (per government mandate). All the three times I visited my insurer’s website to carry out the so-called “Aadhaar seeding”, the website was down.

It struck me that, if only the insurance company had used the Blockchain for its insurance applications, it would have delivered 24*7*365 operations at no cost and delivered superior CX compared to a traditional centralized database architecture.