Last month we introduced a whole new version of our product, both on the software and hardware side. Since the rollout, we've been receiving a lot of valuable feedback and the customer adoption has been great so far. But there was something about the feedback we've been receiving that caught my attention: a lot of people asked us why we've taken certain decisions, and that has fascinated me.
I've always thought that people only used feedback channels to report if something was going wrong. But we've been surprised by the amount of people that was checking in only to congratulate us or just to ask about particular product decisions we've made.
Because of it, I've decided to write about the thought process we went trough during the development of the product. Unfortunately I can't walk you through the reasoning behind each feature we've implemented in the v2.0 of iomando in this single post. Instead I'll focus on the three that we've sweat the most and (casually) the ones that we've been asked more often.
- SMS login
- Passcode lock
- Location services
Since the first day we've been struggling with logins and accounts. Think of what the user is trying to accomplish when she downloads the app. iomando is not a place where she expects to spend a lot of time, we are not a social network, we provide a solution to a given problem. We aim to solve a concrete situation for our users by being a better alternative for keys and remotes. So in addition to the bulk we are saving, we also aim to be fast and direct.
Passwords are a pain, we haven't discovered that. Therefore, we don't want our users to remember yet another password. We also don't want data about our users. Our business model doesn't work with targeted ads or reselling valuable data (like the time you arrive home) to a 3rd party. We've been always really cleat and straightforward about it.
We wanted to design for a better way to login to the service that must had three characteristics:
- Frictionless with the user data.
- The login parameter should be easily sortable by the administrator (so he knows who is letting in).
- Extremely secure.
We needed to look for a parameter that was durable, public, unique to the person and easily verifiable. After running over some ideas we decided that the phone number was the only one that was checking the four requisites. Email was public and easily verifiable, but was not unique nor durable. I can think of people with more than 3 emails and also people who changes jobs like every year and gets a new address each time.
On the other hand, the phone number is a parameter that is associated with you for a long time (I have the same since I was 14) and an administrator is more likely to add someone by the phone number rather than one of the multiple emails.
But still, we had to check the friction and security. When you are presented with these two concepts you think of them as a tradeoff, you can't have it both ways. We thought like that at the beginning. In an ideal world the user logged once and she didn't even need a password. But then, how you reassured that she was authenticating in every single login in the future? It was tough.
Enter the verification code. When we thought of security we always thought of something that only the user knew, and therefore, it was secure. That made it difficult, because sometimes the user forgets, and it is a pain. But eventually, we came up with an amazing realization that turned our previous assumptions around: it wasn't necessary to think of the "secure element" as something the user knew, it could also be something the user had.
Once you acknowledge that, you realize that a unique, public and verifiable "element" that the user had all the time was the phone number.
It made sense. If we could verify the phone number (which we did sending and SMS code) we could assure that the user was telling us the truth, and therefore, we could tie together user and phone number. There was no need for the user to create an account or remember any password, just login the first time and it's done.
As I've mentioned earlier in the article, security is a deep concern at iomando. We deal with access control and we truly understand the responsibility that goes along with that. One of the features we've introduced with v2.0 was the ability (disabled by default) for the user to set a four digit password that was prompted every time the user attempted to press the open button.
Despite we acknowledge that this feature was tangentially conflicted with one of our key values (that is speed in the execution), we also realized that security was a far more critical concern, and we had to address it the sooner the better. Therefore we've implemented four digit code aimed to help in two situations.
- In case the phone went missing (stolen, lost...) the four digit code added an additional layer of security when the lock screen was by-passed (we also expect some layer of security in the lock screen).
- Unintended touches: since iomando may or may not be distance constrained (see below), an unintended touch could be potentially disastrous. With passcode lock, every time the button is pushed the code is prompted, so when your kids are inevitably driven by the temptation to push the big green button, your access remains safe.
This is one of the new features we are more proud of. Since we've revamped the whole app and we've built it from the ground up to be fully native, we could take advantage of the full geolocation services available in both Android and iOS.
We've implemented geolocation as a geofence around the access point. This means we draw a circle around an access with a certain radius (that is the distance in which you are allowed in) and every time you are positioned inside the circle you can open, if you are out of the circle, you can't.
From the parking list, the administrator is able to determine a global distance for the space, and if necessary, override and fine tune this setting per user. This can be used as a security feature, but we also encourage to set a prudent distance (say 5km) in order to prevent unintended touches without the burden of having to set a passcode lock each time.
 Ok, maybe they don't explicitly ask for the particular product decision that led to implement a feature, but at least they are concerned with "why" we've done it, which I found fascinating.
 If a phone has been stolen, the permissions for that device could be remotely revoked instantly by the administrator from the administration panel. In that case, we encourage our users to report it as soon as possible, so the device can be immediately disabled.