Designing the Internet of Things

A guest post from Pavel, creator of the Blynk app

Favorited Favorite 0

Hi, SparkFun people!

I'm Pavel, creator of Blynk. My background is more in user experience and visual design, so this post is slightly different from what you usually see here. Since I’m a new guy here, let me tell you a bit about myself.

I’ve been designing web, mobile, and car interfaces for the past 10 years. I am obsessed with how everyday routines can be optimized, and how familiar things around us can be made better.

About three years ago, I came across Arduino and was amazed by how easy it was to convert some of my crazy ideas into prototypes with buttons, knobs, LEDs and so on. I never thought of myself as an engineer, but it seems that genes have a mind of their own. (My grandmother designed electric circuits and dashboard interfaces for USSR secret military projects, and my grandfather was a scientist, seriously tinkering with lasers for war airships during the Cold War.) Very quickly, I realized that things can talk to one another through the internet, opening so many possibilities.

The Internet of Things is definitely happening, but it is still young, and many aspects of it have yet to be explored. We makers are definitely on the front edge, shaping the industry of tomorrow and building the connected products of the future. The most awesome thing is that, with all the readily available information and components - and an amazing maker community - you can build almost anything at home. However, when technology is “solved,” another important aspect comes into play: user experience.

IoT reminds me of the early days of the internet, which was built by a group of developers...and used by other developers. It was focused primarily on technology; no one thought about how people will use it. Technology comes first, and as it evolves and more people adopt it, the focus shifts toward design and UX while technology becomes invisible.

alt text

The internet of the '90s, when design was, shall we say, neglected.

Next time you are making something cool (using the SparkFun Blynk Board, of course) try to think about how someone else, like perhaps your parents or non-tech-savvy friends, would use it. My advice is mostly software-related, but creative solutions might come from the engineering side.

Here are five basic tips on what to keep in mind when designing connected stuff:

1. Functionality can be distributed across devices and interactions.

You can set a smart thermostat with a hand, then someone can use a smartphone app to adjust it, and then a rule can trigger it to switch to a night mode.

2. Cloud services can be unavailable.

If the server is performing most of the functions, when there is no internet connection the device can obviously become inaccessible. Now imagine an internet door lock – if your lock is connected to the cloud and it goes offline, you are locked out or in. You get the idea.

3. Requests may take time.

It’s OK for an Instagram feed to show a spinning wheel, but latency can become a very frustrating experience when interacting with real objects.

4. Not everything is actually in sync.

When a sensor checks the temperature once in 15 minutes, and then the device goes to sleep, it doesn’t represent the current state when you are checking it on a mobile app. It’s a different experience from physical objects.

5. Consider interoperability.

It’s more a question of standards, but since there is no single protocol yet (another similarity with pre HTTP-era internet), you should consider how your product will talk to other things and services.

There is, of course, much more to consider, and if you are interested in the subject I would recommend looking at:

I’m convinced that for the Internet of Things' evolution, user experience will become the most important factor. With all the forecasts for billions of devices online, people will need to interact with them. They will need to operate and configure them, and create rules for how they will talk to one another, etc.

I do hope your ideas will turn into some fantastic things used by millions of people around world. Maybe you will design a new, smarter thermostat or (please no!) a better SmartPipe.

Comments 23 comments

  • Hi Pavel Blynk rocks! Ive used it on several proyects and it is so easy. Thank you for taking the time to get it going and making it user firendly. The first time I used the esp thing it was not exactly simple..Blynk let me focus on my proyect and not so much on the software side. thanks again

    • Thank you for kind words! Glad you like Blynk. There is still a lot of room for improvement, but we really work hard on the best UX.

      ESP8266 can be tricky, for sure :) I hear you. I'm glad SparkFun took all the hassles out of it and made it much more accessible.

  • IOT is exactly a network of physical objects with network connectivity. The tips mentioned here surely are good as a Computer science engineer I have designed a project based on IOT but I didn’t go through this blog before and face lots of issue.

  • It's strange that nobody commented on SmartPipe :) I thought that it's as crazy as it could be

  • I know I've kind of chewed on you in other comments, but I really do want to thank you for the post. I've seen way too many products that were a "good idea" made bad by poor user interface.

    Back in the late 80s, I was involved in adding a new "option" to a half-million dollar product. When I went to the initial meeting, nobody said anything about "user interface". As a "former customer", this was critical to me, so for the next meeting (a couple of weeks later), I, as a then junior Engineer, offered a way that it might look to the user. I expected to have a lot of push-back, especially from the senior Engineers. I was floored when the response universally was "Hallelujah! We have a leader!" Most Engineers realize the importance of UX, but many don't know how to go about designing a good one.

    • This is so familiar :) Thanks for sharing your experience. For me, the best thing to see when designers works closely to engineers and share their knowledge. Even in Blynk we "fight" for ideas/implementation :) Which I find really cool because then great ideas and solutions are born.

  • On point #2, also consider what happens when the power goes out. Every year, somewhere in the U.S., there will be power outages of more than a week.

    In your example, even if you have thought to provide a "local processor" to lock/unlock the door, and a LiPo battery that is kept charged from the power grid, if the power goes out for a week, and the battery runs out of juice with you now locked inside 5 minutes before the levy breaks and the house gets flooded... think it can't happen? Ever heard the name "Katrina"?

    • That's a great scenario for an engineer ;) Of course design of the lock should provide mechanical access (no electronics involved)

      As I mentioned, all depends on the particular product. Every "principle" above has some priority depending on the appication. For example, it's ok if parking lot sensor disconnects and shows that it's "vacant". Who cares if it stays off there for even a week. While if someone's blood sugar level data is collected and analyzed in the cloud and battery dies, that's a different scale...

      • You always, always, need to consider "fail-safe". In my 35+ years as an Engineer, I spent about 20% of my effort making sure "it works right when everything goes right", and 80% making sure "it works right when things go wrong".

        As you point out, it is entirely dependent upon what the goal is. Alerting you that the snail-mail has been delivered is a nice convenience, but starting the sump pump in the basement is critical.

  • Hi Pavel, I've read about the app, seen the screen shots and it looks awesome.

    I however belong to the PIC crowd, and I was wondering where can I get the information required to code, for PIC, an interface to the App.

    Is there API information available? ... or enough info for me to develop my own microcontroller code (for sharing obviously).

    • Thank you!

      I'm not that familiar with PICs, but Blynk engineers might be. I've asked them already, but you can also do that on our forum: , or shoot and email to

      • Many PICs have on-board RTCCs...

        • If there is a requirement for RTCC, Ive been running software RTCC's valid till 2099 for years now, both using the main system crystal and a separate 32.768 crystal timer module. This is not an obstacle... at all.

      • rephrase: Where can I see the information necessary to make my own interface on the micro controller side. There is no "unified" compiler/environment for PICs so, coding our own Micro code would be much simpler. You would think using Microchip Compilers would be the solution but frankly, the tool chain sucks.

        According to Blynk's community, they seem to believe PICs are few and far between. I don't expect Blynk code for PICs any time soon.

        Quote: "while it is used for production, PIC is currently not very widespread among makers".

  • Thank you for point #2. "Cloud services can be unavailable."

    I don't know how many projects that I've seen that seem to expect the internet to actually be there at all times. (Shawn's breatholator tie for instance.) I'd like to see an easy to implement (and later analyze/plot/sort/etc.) method for phant (and other IoT services) for a date/time stamp to be associated to a data point from when the device took the reading, not when the cloud service received the data point. Most of them seem to take a single piece of data and assign the date/time when the server received that data point.

    • Yup! I actually had issues with WiFi when we were shooting the breathalyzer project. I think there's a way to have the Photon run without WiFi, but that's not its default behavior. For a real implementation on a project like that, I would want the microcontroller/SBC to collect data, store it to some kind of nonvolatile memory (e.g. SD card), and then only post to a site once it knows it has a solid Internet connection.

      [Edit] As an answer to your final point, you can create a separate field for a timestamp so you know the real collection time (and not post time). This requires a connection for NTP or access to an RTC. I did the NTP method with this tutorial.

    • Yes, exactly. I think that soon it will be less of a problem, but still, there should be always a "backdoor". Depending on the application or the product, connectivity design should be very well thought through. Most of the user frustrations come from system failures, so all the errors should be handled.

      • I designed and built what would now be called an "IoT" device that measures indoor temperature once an hour, and posts it to a "private" database on my personal web site. This was "pre-Phant", so that wasn't an option. (By regularly checking, we can tell that [a] the power is up and [b] the heat-pump is working. If we see problems, we can call a neighbor to check and/or take action when we're not there.)

        Anyway, this sort of thing is why I am always pissed off when a new Single Board Computer is announced that does NOT include an on-board Real-Time Clock Calendar. As someone who has worked in industry with what might be termed "Industrial IoT", this is just plain incompetent Engineering and/or marketing. As a board designer, today any CPU chip that does not have an on-board RTCC that supports battery backup of the RTCC would be rejected out-of-hand when designing a new board.

        • Agree, having RTC on board is usually super useful. However, if there is some connectivity, you can sync the internal timer with the cloud - it's also a solution. Even Arduino can run for a couple of weeks with +- correct time.

          Not for industrial applications, of course.

          We in Blynk made an "RTC widget" so that you can sync it when you need it.

          • I've had that aforementioned device have to run for nearly a month sans ANY net connectivity -- fortunately it was during a period when freezing wasn't a concern.

            BTW, it was caused by a cable-modem locking up. I've prevented repeats of this by powering said cable-modem through a ~$10 mechanical timer, and setting it to power cycle the modem (minimum off time for the lamp timer) in the wee hours (circa 3 AM, IIRC).

            Also, my device captures the time for power-down and power-up events -- couldn't do that with a <expletive left out> "widget" to get the time-of-day. Even getting time from GPS wouldn't work -- GPS receivers take time to "sync-up", and then there's the issue of what happens when a solar flare (or other event) knocks out the satellites... and all this doesn't address the issue of "flickering" power, which I had to deal with in about 1990. A true, battery backed RTCC is the ONLY viable solution. And I very much resent it when board "designers" try to force me to "hang a bag on the side" (i.e., a "shield", "cape", or other buzzword for a daughter board) when they could have easily made a better CPU choice and even just provided a couple of pads to connect the battery (and even made the RTCC's XTAL optional -- solder it and the requisite caps here if you need them).

Related Posts

Recent Posts

Dumpster Dive Returns


All Tags