The IoT is big and real. Countless people are looking into developing all kinds of products that have wireless capabilities and which integrate sensors of some kind. The IoT spans many markets, including industrial and consumer: there are hundreds of apps locating us, making us fitter or providing more comfortable and intelligent homes. With the diverse range of applications is a diverse range of technologies to support them. Just look on the wireless side and you’ll see plenty: NFC, RFID, BTLE, Zigbee, WiFi, and more recently NB-IoT/CAT M. There is a lot understand if we are to develop a product with the right mix of available technologies.

If we take Bluetooth technology for example, app developers can buy development kits complete with sensors from most if not all of the key semiconductor vendors, including Dialog and Nordic. However, even if you know how to build a smartphone app, manipulating Bluetooth and sensors on an embedded device is another kettle of fish.

Learning the skills required takes time, something people don’t usually have on a development project, and the documentation is often heavy and barely comprehensible if you don’t know what you don’t know. Even our own experts here at Cambridge Consultants say that it’s hard to find what you need to know, so imagine the pain for the novices.

Bluetooth Developer Studio is an attempt to do something about it, and it’s a great improvement. Yet, it obviously requires its users to be already familiar with the intricacies of Bluetooth because he structure of the software mirrors the complexity of the programming hierarchy. In a way, the UI helps to surface the complexity, but doesn’t make it easier to grasp.

Bluetooth dev studio

Bluetooth developer studio makes Bluetooth development more intuitive, but it still requires you to understand the domain very well to make sense of the concepts.

The problem is that all the tools start by explaining how Bluetooth works, and it’s down to the programmer to translate what they need to do in the way the software tool expects. You need to become expert in a specific area (in this example, Bluetooth) in order to do something reasonably simple (i.e. connect a sensor to your smartphone app). This is because the tools are developed by the engineers that know the technology, but do not necessarily think about the products or the people that are going to try and develop with them. Cambridge Consultants overlaps these industries and we believe that with a different perspective and the introduction of UX approaches in the tools development we can improve things for all users. Today they find tools to be unintuitive, particularly when they know the outcome they want, but don’t know how to get there.

With so much competition in the space, this is an opportunity to offer better options to software developers. Most people will do the bare minimum to get to the point they need, so thinking they will learn an entire domain is unrealistic. Instead, they use a project (i.e. connect a sensor and make an app) to learn a domain (i.e. Bluetooth).
We need to offer better options for these users. We need to offer tools that will teach the domain (i.e. Bluetooth) as people build their project (i.e. connecting a sensor and make an app) and will make them feel good at the same time.

Kathy Sierra described this issue very eloquently in her book Badass: Making Users Awesome and in a series of talks I had the opportunity to attend at Business of Software: See part 1 and part 2. In one of her slides, she demonstrates that most of the players in software creation, tend to compete on the features of their app or tool with the intent to make the app better. This is a questionable approach, in that it assumes that the more features the app or tool has, the better it is. In fact an app or tool can be more successful if it attempts to make its users better at what they do, rather than piling on more features that aren’t used.

Take Instagram for example, a wildly successful consumer app. It used very few features to take better pictures, at a time when phone cameras weren’t brilliant. Instead it allowed its users to show off “arty” pictures that were very easy to produce with simple filters.

One slide of Kathy Sierra’s talk at BoS 2013. There is far less competition when you build your tool to make a "super" use rather then making your tool better.

One slide of Kathy Sierra’s talk at BoS 2013. There is far less competition when you build your tool to make a “super” use rather than making your tool better.

This is good news for semiconductor vendors: there are very few tools out there that have been developed with this perspective in mind. It’s a great opportunity to differentiate.
For instance, creating a piece of software starting with what you want to do, and making it simple to learn Bluetooth concepts along the way, rather than the opposite? This is likely to demand UX skills that are more common in consumer product development, but will make a big difference.

Last year, our Experience Design (XD) team developed tools and concepts for one of our clients to help their developers to create applications more intuitively. We did it because it has many benefits, not just for the end user but also for the semiconductor vendor.

When the developers can learn more easily and develop quicker, better designed tools can lower the support burden to semiconductor companies and expand the accessible market beyond only those that have the domain expertise. An added bonus is that the new tool often becomes the platform of choice, even if silicon performance is not world leading. In turns, that platform becomes “sticky” because it will require more effort to get up to speed on an alternative platform.

We know we can go further. We know you could differentiate from your competition by creating software that would start with the outcome people want. If this is of interest, do contact us: we’d love to continue the story!


This article was co-written with Jez Stark, Head of Semiconductor Services.

Marine Barbaroux