iBeacon Development: 5 UX and Design Challenges


It seems simple enough: put a beacon on the wall, call a few classes inside your iOS app, release it to your users and watch with joy as they receive a helpful welcome message when they walk in the front door.

But iBeacon development isn’t that simple and it’s challenging designers, coders and business development teams in often unexpected ways.

Brent Hieggelke of Urban Airship writes this week that the simple and obvious solutions might be fun or useful to your users at first. But if all you do is push welcome messages and a coupon or two, your app is more likely to end up in the virtual dust bin than a permanent fixture of your user’s background tray:

Seriously, though, after a few too many buzzing, irrelevant alerts, the best you can hope for (perhaps naively) is that customers tune you out and let your brand remain on their mobile devices. Some have envisioned scenarios where grocery stores become their own ad networks, auctioning off the end cap of each aisle for different brands to advertise to shoppers. Chiming, beeping, buzzing ads trip-wired to every aisle, hawking the latest must-have products — you won’t be able to put your phone down.

He suggests avoiding the obvious and thinking up a richer experience instead. In order to bring true value to your users he gives five recommendations for experience design:

  • Establish the expectation for valuable, relevant messages through your app’s regular push notifications
  • Use individual app preferences and behaviors to tailor beacon-triggered messages
  • Use responses to those messages as additional signals about users’ interests and preferences for ongoing segmentation
  • Build logic and trigger management into iBeacon deployments, including frequency caps and timing delays so you don’t over-message your audience
  • Leverage dwell times and distances from iBeacon to finesse messaging

His conclusion? “It is definitely time to start executing on your in-store and in-venue mobile experience. While it’s still early days for iBeacon, leaders and losers will emerge quickly, and the brands that will be rewarded most are those that focus on innovation for the sake of their customers’ experiences.”

5 Reasons iBeacon Development is So Bloody Difficult

Brent is right. But even before you figure out how to sequence and personalize messages or use timers or push messages to supplement your beacon-driven app, there are some other mountains to climb.

Because if you’ve spent any time with Bluetooth LE powered beacons, you’ve probably discovered that you’ve taken on a fiendishly difficult design/UX challenge.

Here are five reasons why:

Reason 1: Beacons Are Hardware

Stating the obvious perhaps, but how many app development teams have had to work with hardware before? Creating a social app is fine, creating a loyalty app that connects to a back-end cloud is more challenging, but add in needing to understand how a piece of hardware actually works and you’re taking on a new paradigm in app development.

Reason 2: Not All Beacons Are the Same

Create an app and then connect it up to a few Estimote beacons. Then reconnect it to a Kontakt, a Gimbal, a Radius virtual beacon or a BlueSense. I can almost guarantee that your app will behave differently for each beacon.

You might think it’s your fault, or maybe it’s an error in the Apple iBeacon framework. And that might be true. But it’s equally likely that it has something to do with the beacon. Consider:

  • Not all beacons broadcast at the same frequency
  • Not all beacons transmit the same power signal
  • Beacons poll for interference-free channels in different ways, dealing with WiFi or environmental factors with different algorithms and approaches
  • Not all beacons are based on the same Bluetooth LE chips and different chips have different bugs, fault tolerances and system specifications

Reason 3: Not All Physical Places Are the Same

Your app development team might be working in a workplace saturated with WiFi signals (or signals from multiple beacons). Your customer may have a coffee shop or they might have a store with a ton of metal shelves. All of these things can effect the performance of your beacons. And to make matters more challenging, these things can change based on time of day or even the weather.

Reason 4: Security is Harder

Depending on your use case, you’ll have different requirements for security. This is both hardware and software dependent and can involve both the physical device and the authentication keys used to both change the settings on, and recognize the advertising packet of your beacon.

Different beacons handle security in different ways. Some of them randomly broadcast public UUIDs, some of them have no security (but plan to add it later), and some of them embed encryption in their firmware. You’ll need to decide how to handle firmware changes, device “spoofing” and figure out whether your sub-channels are carrying any proprietary data.

Reason 5: Beacon Providers Have Different (or Non-Existent) Terms of Service

This might not matter if you’re working on a pet project of your own. Or the small retailer you’re working with might not care. But if you start thinking about a larger deployment and you’re building an app around, for example, Estimote beacons then you need to consider whether you want to bet your business on a non-existent licensing agreement.

Some beacon providers retain the rights to user data, some require you to use their back-end cloud services, some are completely open but don’t offer clear performance warranties. So in addition to all the programming and design challenges you have a business challenge as well: which beacon provider do you trust, and does the fact that they don’t have a clear EULA or TOS matter?

Bonus Reason: Beacons Represent the Transformation of UX

And yet all of the above pales in comparison to the opportunity.

We call iBeacon and Bluetooth LE the gateway drug to the Internet of Things. We believe that Bluetooth LE is the specification that will finally provide the glue to connect our devices, our homes, our offices and businesses.

The real world is the new digital interface. And so in spite the challenges of iBeacon development, it’s worth it.

You might need to do a lot more than stick a beacon on the wall and call didRangeBeacons but if you can tackle the moments of frustration and you can lead your team to think about user experiences in a new way then the world is wide open to you. And the very best will do more than push a message as a customer walks in the front door – they’ll create moments of delight, serendipity and joy.

Reminder: San Francisco iBeacon Hackathon

If you’re in the San Francisco area sign up for the iBeacon Hackathon Feb 28 – Mar 2. It will be really exciting to see what some talented developers come up with in solving these and other challenges. Register today.

Give Us A Follow

Join our weekly e-mail list for more on iBeacons. Check out our Twitter list to follow the best beacon tweets. Check out our BEEKn Google page and just generally stay in touch!

3 Responses to “iBeacon Development: 5 UX and Design Challenges”

  1. At the beginning, we may not think at beacons, as “storytelling machines”… Instead of that we may figure out beacons as, “tracking machines” for creating real-time in-store analytics for retailers. In this way, we may find a value proposition to the pay customer, while keeping the user mobile clean of non sense messages… Later on, as UX evolve, and with analytics on hand, we may include relevant communications and deep interactions.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>