Beware of Hidden Rules

 

hidden_rules

Just a quick post to rant about an usability issue I experienced today.

In software development, there are always tons of hidden rules and logics that we made internally for better usability (or may be worse?) and minimizing potential information overload for the user, but if it’s something involved with certain level of user expectation (e.g. user reasonably expecting things should work a certain way), it is always a good idea to ensure that the hidden rules of ours are sufficiently communicated to the user through feedforward or feedback, depending on the situation.

Out of Sight, Out of Mind (and Out of Reach)

Case in point – the funny (may be not so funny) logic in Dashlane that no user can understand (or realize).

So I have been using Dashlane for a while, and I have always been protecting my passwords with PIN code. When I got my Nexus 6P, I have been impatiently waiting for an update to make full use of the fingerprint scanner for it, and of course, yesterday Dashlane updated the app with the promise that fingerprint scanner is now usable in the app.

I happily went ahead and update the app, and the first thing I do after it gets updated is to go to the Settings to set up the fingerprint scanner, and this is basically what I see:

Unknown.pngYes, I am not kidding, this is what I see in the Settings. There isn’t any option related to fingerprint scanner in the Setting. I looked around in the app like a mad man, trying to figure out if I missed anything, and I still didn’t manage to find anything about it. I was pretty sure the app is updated to the latest version, so I went ahead and rant in the Play Store review and someone from the support team asked me to send a ticket for this issue.

And it turns out that because I have the PIN code lock turned on, I am not able to see the Fingerprint option. This is bad, really bad. 

First of all, I just cannot brain the logic behind the hidden fingerprint option when PIN code lock is turned on. Even if they might cause some conflicts, but why totally hides the fingerprint option? How does the user with PIN code lock turned on know that to access the Fingerprint option, they have to turn off the PIN code lock first? I can imagine that most of their users will have PIN code lock turned on, so if the users with the new Nexus devices doesn’t explore further, they probably wouldn’t know that they can actually use the fingerprint scanner in the app.

Secondly, I just don’t see how they can cause conflicts. In iOS version, both PIN code and Fingerprint unlock can be used together, and it make so much sense (at least for me)! E.g. when it’s impossible for me to use the fingerprint scanner, I still can use PIN code to enter the app. May be there is some business logic behind, but if it’s about usability, I don’t think this is the right way to do it.

 

Unknown2

Users know nothing about your hidden rules

There is just one thing you have to remember – your users have no idea what you have done and hence they wouldn’t have know your hidden rules. Have you been trying to enter a new password during the registration for some services, and turn out the registration failed because your password doesn’t fulfil their password requirement, which is not communicated earlier to you when you first filling up the registration form? It is one classic example that the users will not have any idea about your imposed rule(s) that is invisible to them.

If any of your hidden rules involved with the core (or even secondary) experience of the software, please give it a second thought if it is required to be communicated to the user in some way, because again, the user will never know them if it’s not communicated to them in the first place. Design is always about communication between people and objects, and sufficient communication can help in providing great user experience and managing unmanageable user expectations manageably (huh?).

The Fabulous Goes Material

After 264 emails with tons of exchanges, 200+ mock screens, 30+ interaction prototypes, 9 months+, 17156 times of revisions (OK, I made this up) – we finally have The Fabulous app with Material Design pushed to the public on the early September, and we are happy that we reaches our first milestone for the redesign – an honourable feature in Google Play Store under New + Updated Apps category.

Feature in Play Store

You probably have not heard about The Fabulous – It’s a Health and Fitness app uses scientific-based approaches to help people in reaching their health goal through a carefully crafted step-by-step program. We purposefully crafted the journey based on the user goal by slowly showing them relevant information and motivates them during the process, and hopefully get them to form some healthy habits at the end of the journey.

Continue reading

Make the right FAB

Make the right FAB

Floating Action Button, or, in short, FAB, is one of the unique UI element in Material Design for primary/promoted action for a particular screen. Since it is a frequently accessed UI element in a given screen, I think it’s important to make the FAB right in every details. However, there are a number of apps doesn’t have the right FAB as specced in the Material Design Guideline, which also included some of the Google apps (I know!).

Continue reading

Android Design – Think Adaptive

Adaptive Design

Designing for Android devices can be challenging sometimes due to the availability of the Android-powered devices with different screen sizes, however, it is certainly not an issue if adaptive design is considered during the design phase of the app. Some developer/company chose to complain about this, but this likely won’t change anything because it is a deliberate direction that Android meant to go and move forward. The way forward? It’s Adaptive Android Design1.

Continue reading

An example of really bad mobile app design – Maybank2u

mbb

Disclaimer: This post is mainly about the author rant about bad mobile app design from the largest bank in Malaysia, but it is also a great example of don’ts in mobile app design.

It’s September 2014. Material Design was introduced few months ago during Google I/O 2014. The predecessor – Holo Design was introduced late 2011 together with the launch of Ice Cream Sandwich (Android 4.0), which is about 2-3 years ago, and it’s getting matured as time goes. It’s probably not wrong to expect any Android apps published in the year 2014 embraced with all the lessons that we have learnt in Holo Design and craft the best Android experiences for the user.

Except it’s not for Maybank, the largest bank in Malaysia, and one of the world’s top 100 banks.

Last week, they have officially launched their revamped mobile banking app, claiming that it has the best mobile banking experience compared to the previous version. It does seems to have a refreshed design – except it’s probably one of the worst and most unacceptable mobile design that I ever seen. And it’s 2014.

Continue reading

Crafting the Unclouded experience

Unclouded

Unclouded by Christian Göllner, an app that helps to analyse and clean your cloud storage (Dropbox and Google Drive, for now) has just recently out of beta, and I have the honor to work together with Christian on the design for this app. I was really impressed by the app quality when I first received the early build of the app – without hesitation, I told him that I wanted to work together to bring this app to the level of awesomeness. It is super amazing that the app has been featured by Android Police, TechCrunch, CNET, Lifehacker, and xda-developers, and these boosted our confidence about the design and development direction of the app.

In this post, I would love to talk about some design details that we have worked hard to fine tune in order to craft the ‘Unclouded’ experience that we have visioned.

Continue reading