Creating a Geofencing Product: A User Behavior Centered Design
Bluedot Co-Founder on Creating A Geofencing Product (Part 2)
A key to our success is letting user behavior drive the technology and then design around that framework. It’s essential to think through the problem, be user-design focused, and make it all efficient. Personally, I love the elegance of this solution of centering on user behavior. However, it was a very difficult thing to achieve.
Talking about trying to connect human behavior with the activation of chipsets in phones inspired by bats sounds like an easy thing to achieve. That’s probably because it’s based on core principles that are sound and make sense. You see it working in biology, why not in technology as well? Well, honestly it was not easy to come up with.
Figuring Out How To Access Smartphones
It was difficult to pull off. In the beginning, we wanted to utilize the accelerometer of the smartphone. This would let us understand the movement and behavior of a customer. Then use that data to influence how often we need to get the location of a user.
However, we encountered other issues when working with Apple iOS and Android. As it turns out, operating systems kill any application that is both recognizing the activity of the customer and modulating the frequency of location updates. So we couldn’t use components of the operating system that are supposed to do exactly that. We then decided to build our own way to measure accelerometer profiles to understand what is significant movement. Eventually, we figured out how to get through the operating system and get to the chipsets that we need.
Next, we spent a year and a half of R&D around that core concept. Also, keep in mind that this did not involve having an actual product, this was purely R&D. There wasn’t a UI behind it. A year and a half in, we developed a unique solution, which did involve in a very rudimentary UI. And it let us set a very accurate geofence. It was 20 times more accurate than other geofencing tools.
Overcoming Field Testing Results
So then we got in a car to test it out. As we drove, our solution missed 60% of all geofences. Mystified, we sat there scratching our heads. We’re getting very accurate location updates, but we were still missing these geofences. Our solution was to build logging and debugging tools to understand how these location updates are coming in.
How do you make it reactive and accurate at extremely extenuating circumstances, such as high travel speeds? That was another part of our IP that we had to go and solve. So we then had to build a UI of a prototype for customers to properly use. So you know, it’s great that it works in a smartphone app that we’ve built. However, how do you make it consumable by customers?
So then we built an SDK, which let us get into the customer’s phones. You need to have a presence on the customer’s phone, which is done through app permissions that grant access to your location sensors. In the end, our engineered MVP had incredible accuracy, like 17-15 feet. So it took about 2 and a half years to get to where we are now.
Click Here For Part 3