Fun UX Example: Starbucks.com

[This site uses cookies, but not the kind you eat]

Today I clicked on a link to a Starbucks.com page, and a popup opened up, for the now ubiquitous cookie/privacy notification. Only this time, the words used were not the dry jargon filled trope we are now so used to seeing everywhere. Instead, the popup made it lighter by saying that this is about cookies, just not the ones you eat.
[This site uses cookies, but not the kind you eat]

Cute, isn’t it? It’s also noteworthy that they describe how they use these cookies in simple terms.

But wait, there’s more!

Why does the fun take on actual cookies work here? Because it’s Starbucks. And they know it.

Which is why, right after you dismiss the popup, up comes another one. Are you annoyed by two consecutive popups? I wasn’t. Because the next popup is this one:

[How about a real cookie?]

Colour me impressed!

This is awesome UX! You have to put up a notification because of regulations, you see an opportunity to connect it with a popular product of yours, and in a cheeky yet cute move, you create an opportunity to induce a sale!

I was so pleased with this experience that I opened the page in another browser just so that I could see the popups again (and take screenshots for this post in the meantime).

Lessons learnt:
Always look for opportunities to make UX of your product fun for the user. And quite often there might be an opportunity in the decisions that you don’t have much control on – you need to be able to spot it and make it work for you.

Bad UX: Fixing What Isn’t Broken or Over-Designing

One of the key things UX designers and product managers focus on is how to reduce friction for their users while using their products. If there is any UX pattern in our product which causes confusion in the minds of the user, they have to double guess how to use it, or they have to put more thought than necessary into using it, we have failed.

One such product that bothers me a lot is the tap or faucet. (Don Norman wrote about it in his book The Design of Everyday Things)

You use a tap in a very simple way – you turn a knob that sits on top of the device anticlockwise to start the water flow, clockwise to stop it, the water flows out of a spout in the vicinity of the knob, and the flow of water is governed by how much you have turned the knob.
Like this one: shallow-focus-photography-of-gold-faucets-1021872

This is simple, universal, does the job every time as expected, and there really isn’t any reason to make any changes in the fundamental structure of this device. And if I encountered a tap like this everywhere I went throughout my life, I am not going to complain.

Yet, we see the following variations of the tap at various places, where the variations are not just in scale, shape, texture, material, but in how the tap is used:

We are left confused as to which component to turn to use the tap, or which way to turn it, or whether we are turning it in the right axis even, or whether we have to push on the “knob” instead of turning it! Why have tap designers gone to these lengths to confuse us while using such a simple device? Mind you, I am not even talking about faucets where both hot and cold water comes and there are complex knobs to ensure you get the right temperature by mixing both, or sensor-driven taps, where you don’t need to touch the tap to activate it (they come with their own challenges – where exactly do I place my hand so it works? The tap next to mine seems to be working – why isn’t mine working?).

In Software Design

What are some of such scenarios in software & app design where the interface has been over-engineered to the detriment of user experience?

  1. Synthetic scroll: This was a pattern in vogue on blogs and magazine sites a couple of years back. If you used your mouse wheel or trackpad to scroll the page, the scroll speed would be higher than usual. Why? Either because the designer had found a nifty Javascript trick to make it happen, or … I cannot think of any other reason, least of all a user-centric one.
    Scrolling is something the device & browser handle and they handle it very well, and unless your experience involves things like scrollspy and page section navigation, there is no real reason to tamper with this behaviour.
  2. The sticky mastheads on sites, which would disappear when scrolling down, but would pop up again when you scrolled up a bit. Why do we need this interaction at all? Is the screen space so limited that the content isn’t visible when the masthead is perpetually visible? It is a little bit annoying to scroll up to re-read something you had just seen, only to have it hidden behind the masthead, so that you need to scroll just a little bit more.
  3. Form validations that go ‘above & beyond’:
    1. Some form fields take only specific types of inputs, e.g. numbers. But some designers go beyond just filtering unacceptable characters – there are forms where if you press anything other than the 11 keys (10 numbers and the period), the data you have already entered in the field is simply deleted, and you have to re-enter your data!
    2. There are forms where when the page load completes, a script goes through all the input fields to reset them. How is this a problem? Say the page takes some time to load, and the user has already started to input some data, once the page load ‘completes’ (in today’s times of progressive web apps, this could be an arbitrary point in time), the script just removes your inputs.
    3. Fancy input fields which are broken into multiple input fields one character wide. The most common example is the OTP field in many e-commerce apps. Why is this done? To visually denote how long an input is expected. As you input the OTP, the focus keeps moving to the next field, and thus the experience is completed, except when the backspace isn’t coded for. When you press backspace, the previous field should be emptied and put in focus, but at times the developer forgets to code that and it becomes an issue. Going one step forward, when the user manually goes to the respective field to delete the input, the code checks the existing data length, decides that the input is complete, and thus pushes the focus to the next field, without letting the user delete the wrong data.
      1. The special case of this issue that has bothered me for years can be seen on the IPv4 configuration screen on Windows. An IP address consists of 4 one-to-three digit numbers separated by periods. While other systems let you enter it all in one textbox, and you have to type the periods as well (leaving us in total control), Windows’ designers decided to make it fancier – there are four textboxes and the periods are ornamental pieces between them. It’s nifty, except that if you are typing any number less than 100, you fill only two places in a 3-digit field, and you cannot move to the next field except by clicking it using your mouse or trackpad. The tab key takes you to the next group of fields. Pressing a backspace on an empty field doesn’t take you to the previous field either. I’ve seen this behaviour and been annoyed with it for years now, but nothing seems to have changed here over multiple versions.
        windowsip

As you can see in the examples above, designers at times go overboard in over-designing interactions where it’s not needed, breaking away from the expected pattern, thus leaving the user confused or worse still, frustrated. These mistakes are almost always avoidable, simply by falling back on the most used and easily available pattern. This goes for taps as well 🙂

What are some of the examples of over-designing, in software or other products, that you have come across?

Bookmarklet: Add Keyword Search to the Listings on IIMJobs.com

Job hunters from the IIMs and other such colleges often go to this cool site called IIMJobs.com, started by an alumnus of my alma mater. It’s quite a live board, but there is one thing that I sorely miss there – filtering the job listings by keyword. You can select your experience range, your preferred location, and search. You get to see all jobs in your preferred city for your preferred vintage, but you may not be interested in them. And you have to sift through the listings page to find jobs suitable for you.

This got me thinking – what if there was a filter box, where I could type in my preferred phrase and it would filter the listings on the page, keeping only those that you want to see?

So, I spent a Monday morning putting together some code, and here it is – a bookmarklet which, if you save it on your browser’s toolbar and click on it when you are on the IIMJobs listing page, you will get a cool keyword search input box. This will let you filter the listings on the page by keyword – basically it will hide all the listings which do not match your search phrase.

All you have to do is drag the button below to your browser’s toolbar.

<a style="padding: 18px 32px; font-size: 16px; margin-bottom: 40px; background-color: #444; color: #fff;" title="Drag me to your bookmarks/favourites" href='javascript:(function(){$("#searchform").find(".greybtn").closest("div").before("

“),$(“ד).appendTo(“.keywordParent”),$(“.keywordSearch”).keyup(function(e){var%20o=$(“.keywordSearch”).val().toLowerCase();$(“.jobRow”).each(function(e){-1Add Filter @IIMJobs

Do let me know in the comments below if you like it, or if you have any feedback on how to make it better.

Can We Make Newspaper Articles Shareable & Trackable

While reading an article in today’s ET Brand Equity, I felt like I had to share it with my friends, maybe put it up on LinkedIn with a comment of my own. The thing is, I was reading it on the paper, not the app or the website. And being the lazy person that I am, I would not usually go looking for this article on either of those two, just for sharing it.

But I did want to share this article with my friends, and I looked for ways to do so.
Can We Make Newspaper Articles Shareable & Trackable

Apart from the author’s email address, I could not find anything to go by.

This puts the physical paper and its reader at a disadvantage compared to the app/site & their reader.

The Obvious Way

One obvious way out is to take a picture of the said article, and WhatsApp it to the relevant people. Or tweet it, or share it on Facebook or LinkedIn.

I would have to overcome the hassles of getting a clear picture, each word being clearly captured, the lighting being right, the paper not flying away due to the fan yada yada. At the same time, there is an obvious opportunity that the newspaper company is missing here – in this method they would not know who all has read this piece of content, or even how many people it has reached.

In this day and age of tracking user attention and retargetting, don’t you think that’s a big piece all physical newspapers and magazines are missing out on?

Go Digital

So, I have a proposal for paper publications, who also have a website and/or an app where the same content is published.

Why not simply print the QR code to the link of the content at the beginning or end of the piece?

I got off my lazy behind, and found out what the online home for this particular article is: https://brandequity.economictimes.indiatimes.com/news/business-of-brands/huls-secret-recipe-of-success/71401983

A simple QR code leading to this article looks like this:
QR to ET article

But this would take some space to print, wouldn’t it?

This is where a URL shortener service like bit.ly comes in handy. Not only can the URL be shortened to something like 20-25 characters, they provide tracking data as well. This is how a bit.ly version of the same link looks:
QR to bit.ly to ET article

And a crude representation of how it could look on the same article:
Can We Make Newspaper Articles Shareable & Trackable
It doesn’t take up a lot of space, and it is scannable – try it out!

I am sure the designers at these papers would find a way to make it look way more attractive than this.

With this small addition to every piece of content in a paper, I am sure sharing and adoption of the online versions would also take off. Meanwhile, knowing that I can share content I would definitely be more open to reading the physical paper, since reading something like Brand Equity is not only driven by updating my knowledge about the industry, but also about finding shareable content for this blog and my LinkedIn feed.

Short Commentary: PineLabs POS UI

I was in Nature’s Basket the other day. When I took out my credit card to pay the bill, I noticed the fancy all-touch-screen POS the cashier pushed towards me. It’s a device with a cradle charger, and frankly looks quite fancy, though I do not have any qualms with the usual all-black push button POS machines we see everywhere else.

Nevertheless, it caught my attention. It looks somewhat like this:
Probable interface when actually using the POS

Except, when my card was inserted and I had to enter the PIN to authenticate, it looked somewhat like this:
Probable interface when actually using the POS

Do you see the difference? Yes the digits are switched around. Possibly some team convinced everyone that it is a high security feature and would reduce fraud/misuse of cards. Here’s my take on why this design decision has gone wrong.

What are we trying to solve here?
  • Negative use case: Someone is carrying a stolen card and has somehow figured out the PIN, though a skimmer, social engineering, maybe overheard the owner somewhere, or looked over their shoulder. Such users remember the PIN’s digits, commit them to memory, and would maybe revise it in their head while the card is being swiped. Does this interface gimmick prevent them from using the keypad? I doubt it. They are anyway going to be looking for the digits on the screen, and pausing after every keypress. There is hardly any change in behaviour for such people.
  • Positive use case: The actual owner of the card. Most of us do not repeat the 4-digit PIN in our heads before punching it. After the initial 5-10 times, we just repeat the keystrokes on the POS. It’s muscle memory for most of us. Because of this design change, we have to punch in the keys like anyone from the negative use case bracket would – punch-pause-punch-pause, and in between try to remember if 2 came before 8 or after and if there really was a 7 in the middle, because the keys aren’t where our brains expect them to be. All this design change does is make the legitimate users look like they have just cracked the PIN to a card they found on the street.
  • Now let’s talk about the other positive use cases: The elderly, disabled, kids carrying the card. Those who do not depend on muscle memory to punch in PINs. These people might anyway be remember one digit at a time, so should it be okay to switch the digits around? These people are not going to touch type, why are we making it difficult for them to look for digits? Nothing is where you expect it to be.

What is the point really of such an interface change, when it a) prevents legitimate users from using the system effectively, and b) does nothing to prevent misuse/fraud, when I’m sure that fraud prevention would have been cited as the reason number one to implement this.