Overcoming Common Pitfalls When Creating Apps for Bluetooth Devices

As a product manager (PM), I work with complex technical products all the time. But recently, building an app to support a Bluetooth-enabled ‘smart’ product proved especially challenging - from making the user experience seamless; to making smart decisions on app structure; to defining the best way to present the user with the information they need at the right time.

This experience taught me how to avoid pitfalls that are unique to the development of apps built to communicate with Bluetooth devices, especially when the app not only receives data from the Bluetooth device, but also continuously pushes data back to it. Here are my top recommendations for product managers, developers, and designers to consider.

Develop clear definitions to ease communication between project members

One unexpected challenge I faced during this project was the confusion caused by different terminology related to Bluetooth tech. Even though Bluetooth has been around for years, not everyone understands its related terms or uses them in the same way. For example: pairing vs. connecting, BLE, UUID, mandatory settings vs. app permissions, peripherals look up vs. connecting - to name a few.

After seeing a few miscommunication stumbles at the start of the project, I created a glossary to standardize the language used across the whole team. Stakeholders, product managers, designers, and developers were then able to better communicate and avoid unnecessary back-and-forth.

This first step helped reduce friction, create smoother communication and clearer requirements, and - most importantly - save time! On future complex tech projects, developing a glossary of related terms for everyone to use will be at the top of my checklist.

Identify what the user really needs to know and when

There is a unique challenge related to managing Bluetooth-enabled devices from an app - and it’s all about user experience. If you’ve ever used Bluetooth, I bet you’ve asked yourself the following questions: Is the device connected? Why can’t I trigger this action? What went wrong? Is the status I’m viewing on the app the latest, or is there a syncing problem?

We tackled these UX challenges first by identifying what the user needs to know at key moments in the app, and what they don’t. As the product owner, I needed to translate the system’s complexity into a clear and easy mental model to help users understand how the app works with their device and the current state of both the device and connection. Identifying and aligning on the important information upfront also made it easier for the team to work in a more efficient way. UI designers had a clearer understanding of the user interactions' logic and architecture, allowing them to focus on main interactions first and develop a design that worked well, regardless of tech constraints or connectivity. Moreover, developers could recognize API requirements and prioritize them accordingly.

Once we knew what we needed to tell the user and when, we then established the sensitive information that users would want to be aware of at all times. For instance, imagine a user is managing their home security system from a mobile app. The sensitive data they will want to know includes: Is the alarm currently activated? Are cameras currently recording? Whereas when were cameras turned off/on? is likely less important at that moment. By identifying the most important data for the user, we can also establish which data must come from the hardware (and is only available when it is connected to the app) versus which data can be handled on a backend/platform side, and thus accessible directly on the app with an internet connection.

For example, imagine a smart device that needs a battery level of x% to work well. The current battery level is only visible to the user when the device and app are connected. But if it was a high-priority for users to see battery usage patterns, then while the device was connected, you could continuously send the battery level to the app and backend. Therefore, you could later display a usage chart in the app, regardless of whether the hardware was connected at the time.

Make it clear to the user what they can do in the connected vs. disconnected states

A Bluetooth-dependent app can only communicate with the hardware when it’s connected, so we needed to identify the functionality that should be available to users when connected versus disconnected. We also needed to make those states and capabilities obvious and easy.

Compare this with how you might think of online and offline modes with certain web apps, like the basic offline View-only versus Edit mode on a Google Doc. View-only mode is similar to when Bluetooth is disconnected, and we can only show the user the device’s current status. Edit mode equates to when Bluetooth connectivity allows the user to take action from the app to the smart device.

Now consider how that experience would be if Google didn’t make it clear that the user was offline and what they can or can’t do. The user might tap buttons and not understand why they didn’t work or had been disabled, they might read content not realizing it wasn’t the most recent, and it would generally cause a frustrating experience. So consider how to handle states when no external device is connected. Is the first step to encourage users to connect immediately, or is there important functionality that the user can do without a connection? (In the second case, you don’t want users to feel ‘blocked’ by not being connected.) Overall, make sure to provide users with an intuitive next step and give them real-time feedback on what’s happening through messaging and animations. When needed, provide easy access to help or tutorials - any relevant UX tool to prevent users from being left hanging or forced to search elsewhere for troubleshooting tips.

It’s also important to define what is available to the user when. This becomes especially important in cases where the app can connect and handle multiple pieces of hardware equipment. Make sure to create a coherent understanding of which hardware piece is being used, current states, and available functions. Additionally, present key functionalities and their current trigger status in a way that minimizes the demand on the user’s attention. This helps reduce the user’s frustration at the inevitable Bluetooth limitations, allowing them to understand what is going on, the latest status, and what they need to do next.

Make tech limitations less painful for the user

All of the above takeaways also help with this last, but not least important, learning.

They say “if you can’t beat them, join them,” and the same goes for complex technology. Bluetooth constraints include range limits, the complexity of managing multiple devices connected at a time, and what can feel like painfully long connectivity times. So if you are the product manager of an app that’s dependent on Bluetooth technology, accept the reality of dealing with these limitations and find the best way to smartly address them.

It’s important to leverage available UX tools to make these limitations feel less painful to the user. For example:

Follow established platform conventions to make the elements on your app recognizable. It’s not time to reinvent the wheel when you’re already trying to solve significant UX challenges. For example, most everyone is familiar with the Bluetooth icon, so your designers don’t need to create their own version of it, which would only confuse users.
If the app needs permissions, be sure to explain why to the user, and do it upfront for a better onboarding experience. You don’t want users to start using a Bluetooth dependent app without the ability to do anything due to lack of permissions.
Consider the user experience for various scenarios like loading times, searching for in-range devices, possible connectivity loss, or another phone “stealing” control (when another user/app connects to that device, and as a result, disconnects the first user).
Use clear signposting for cross-device/user interactions and data/content synchronization. Users don’t want bad surprises, so remember to keep them informed, especially with sensitive data updates.
Find creative ways to deal with data and content that can sometimes be out of sync, like making use of time stamps for providing “last synced at” information. It’s best to find a balance between transparency and over-explanation. The complex nitty-gritty of how the system works would probably confuse the user. On the other hand, lack of transparency regarding delays or whether a triggered command has been executed might lead to incorrect assumptions.

Technical complexity will vary a lot between projects, but hopefully these tips will help address the challenges of developing Bluetooth-enabled products. Remember to establish a shared understanding of common terms with your team, identify what the user needs to know and when, define necessary functionality for different states, and most importantly - learn to work within the technical limitations of Bluetooth technology.

If you are interested in reading more on this subject, here are some additional articles to check out: