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

#AndroidDev Interview Series – Jack Underwood

Interview-No-2It’s been a while since the first interview with Ryan Harter, and today let’s continue the series with Jack Underwood.

Jack is a young indie developer that never say no to challenges – how do I know it? I previously worked with Jack for a couple of projects like Now Playing, Reverse Dictionary, and Today Calendar and Widget (pre-Material Design era), and we are really liking that push-and-pull interaction between us during the development.

Without further ado, let’s start with the interview!

Continue reading

UI Animation in Photoshop – Tutorial #2

Blog-Pic

In the first UI Animation in Photoshop tutorial, I have shown the way to do simple animations in Photoshop like moving, scaling and style changing – if you are new to this and haven’t check that out yet, I recommend you to look into Tutorial #1 before this.

In this second tutorial, I will share my experiences in applying easing into the animation made with Photoshop. Special thanks to Jovie Brett Bardoles for sharing his manual way of applying easing in his animations, which inspire me to explore and dig into the Timeline feature in Photoshop.

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

#AndroidDev Interview Series – Ryan Harter

Interview No 1

Why #AndroidDev Interview Series?

I think it’s no secret that my aim being a GDE is to help to close the gap between designer and developer in order to make awesome products, and as a designer, I always enjoy talking to Android Developer to get insights from them, especially indie developers since most of the time, they pretty much have to wear many different hats themselves in making their app a success in the Play Store.

Thus the idea making a series of interview with awesome Android Developers (especially indie developers) to peek inside their world, and their thoughts on design and designers (which is the insights that I truly appreciate), because I believe I will be able to learn something new from everyone of them with their unique experiences in Android development.

So for the first interview of the series, I proudly present Ryan Harter. I haven’t met Ryan until the recent GDE Summit (yes, he is an Android GDE!), and I definitely love talking to him and appreciate his passion towards Android development. Below is the quick and short email interview with him:

Continue reading