A language of light for IoT products

Melissa Coleman
Made by Many
Published in
10 min readMar 30, 2017

--

Comfortable with designing for screens? Here’s a primer on designing for a single pixel

If you’re working in a digital design environment you may have fantasised about which product you’d make for the IoT. You may have products on your radar that you love and wish you’d made, or seen ones you know you could improve upon. At Made by Many we satisfied our curiosity about creating for the IoT through a side project that became a real product: Hackaball. In addition to being great fun it was also an interesting test case in seeing how our skills in digital translated to the digital-physical product market — and in particular applying our skills in designing for screens to doing so for a single pixel.

At the end of 2016 after almost four years of development we started shipping Hackaball, a digital-physical toy that teaches kids aged 6–12 the basic concepts of coding through play. With our iOS and Mac apps kids can create new digital ballgames, using a visual, block-based programming language that controls the ball’s lights, sounds and vibrations.

In going from prototypes to a consumer product we’ve learned a vast amount. If you create digital products and want to learn about designing for the digital-physical product space we have insights to fast-track your prototyping. This article (which is the second in a trilogy — read the first on the making of Hackaball) will focus on designing light, since LEDs are one of the most widely used interfaces for communicating IoT product messages and were also a hugely important part of how our product Hackaball communicates with users.

Setting out on this challenge we had many questions. What processes work? What tools are available for prototyping with LEDs? How do decisions around light influence the product experience? How do you use LEDs to communicate product messages?

Here are four lessons we learned:

1. Lead product design through strong branding

Our approach to designing software-driven experiences was our starting point for creating an IoT product — and in a bigger way then we maybe originally expected. At Made by Many designers are responsible for product experience in the widest sense. This means we couldn’t simply leave design decisions for the physical product siloed off with our industrial design collaborators. Early on our designers Alex Harding, Mike Walker and Owen Thomas, realised that they needed to lead the prototyping process by focusing on branding. They developed a common vision for our app and ball that continued to direct our decisions for the industrial design, app design and interactions throughout the entire project. From day one our designers and developers collaborated closely with, first our in-house industrial designer Ben King, and later on our industrial design partner Map Project Office, to ensure branding was consistent across the product creating a seamless experience between the ball and the app. This is particularly important because one of the challenges of designing a connected product is that user attention is split between the app and your physical product, which greatly impacts user experience.

Hackaball with the free app for iOS and macOS

2. Learn the basics of designing light by experimenting with LEDs, materials and animations

Other people on your team may have the skills to propose options for integrating light in your product, but having some basic cross-disciplinary understanding of materials and light will definitely make you a better designer of IoT products. Some details:

LEDs are the right tools for designing light

There’s a big difference between designing for the screen and designing for LED lights. Your product probably consists of an app as well as a physical product so you’ll want to synchronise colours palettes between both of them. You can use illuminated plastics with colours to match your app, but what if you have a product where the light needs to change colour? The colours available on your screen can’t all be recreated by mixing the RGB values of an LED. Mixing light means varying light intensities and a zero value isn’t black, it’s simply the absence of light. R, G and B values might all not have the same light intensity, skewing the colours slightly from what you’d expect. It’s a frustrating exercise to design LED lights on the screen and then try to recreate those on your product. The other way around is much easier: start creating colour palettes straight from your LEDs and from there translate these back to the screen.

With Hackaball we built a simple colour picker and RGB text box inputs so our designer Mike Walker could quickly try out colours directly on the ball to build up Hackaball’s colour palette.

Left: colour picker with inputs to try RGB values, right: ball lighting up in Hot Pink

Physical pixels, diffusion and channeling light

There are three common approaches to using LEDs in a product: 1) direct light, essentially physical pixels; 2) indirect, diffused and reflected lights blending — for example Hackaball; and 3) channeling light through a material to illuminate it. The opening angle of your LED will influence the visual quality of the light, having more of a pixel type quality if the opening angle is narrow versus a blending quality for a wider opening angle. As a digital designer you may not automatically be involved in the decision around which electronic parts are chosen, so through self-study learn about which LEDs are generally available (brightness and sizes) and ask the factories you’re working with for samples to play with. Use simple prototyping tools for electronics such as Arduino and play around with materials like paper and plastics of different thicknesses and transparencies. By better understanding materials you can champion solutions that are most in line with your vision for the product. You can either do this together with your industrial design collaborators if they are working in house, or as self-study as a preparation for designing an IoT product with light.

Hackaball from top, with and without the cover diffusing the light

Integrating circuit boards into products

Your product is a 3D object, but LEDs will usually be mounted on a more or less 2D surface, the circuit board. In the case of Hackaball we mounted the LEDs on both sides of a single board. On Hackaball the LEDs are mounted straight onto the circuitboard but you could also mount them at a 90º angle. A third option is connecting your LEDs with wires coming off the board and the LEDs glued onto your plastics. This option requires more manual operations in the factory.

Placing LEDs on a single board means that lights can’t be in the exact same position on the top and bottom

Creating light animations, choosing the number and configuration of LEDs

If you want to learn about light animations a nice place to start is Adafruit’s great collection of tutorials. Below are some examples of Hackaball’s light animations:

Rainbow animation — an animation available for game play
Candy Cane animation — an animation available for game play

If you choose to configure your LEDs in a line, circle or grid then you can create animations that suggest movement of points or lines through your object. For Hackaball we used four LEDs in the top and four in the bottom. Because we are using the spherical form to diffuse the LEDs this suggests that lights are moving around a circle.

Siren animation — an animation available for game play

3. Decide on a common language for communicating light designs across disciplines

Depending on the amount of freedom you want to change light animations of your product in the future, you may find you need to come up with a modular way of describing light animations. This is especially useful if you and your firmware developers aren’t working in the same space and you need a more formalised approach to communicating your designs. One way of thinking about this is to describe animations frame by frame, noting the timing of the full animation or the timing between frames, the transition between them (for example wipe or crossfade) and whether or not and how your animation is looping.

Light design for Hackaball’s Chameleon light pattern describing keyframes in the animation, the colours from our custom colour palette, full duration of the animations and transitions between frames — design by Sam Small

If you know that you’re not designing a finite set of animations, for example if you want users to create animations, then it’s important that your firmware developer also approaches the implementation in this way from the start. If you and your firmware developer together create a protocol for light animations it will start out with a slightly bigger investment on the tech side, but the tradeoff is great flexibility for changing designs in the long run.

4. Communicate product messages by building on familiar patterns

From the get-go we knew Hackaball’s interactions and animations needed to be extremely simple and unambiguous since we wanted the product to be easily understandable without relying heavily on textual messages in the app. We also needed to distinguish them from the animations used in game play so that kids could immediately identify the internal state of the ball. In a product with no screen and no easy way for users to debug it, the animations show exactly what users need to know to navigate through the ball’s internal states.

The best way we could think of to keep Hackaball’s animations simple to understand was to tap into the collective understanding of digital interactions and metaphors around light. In a globalised digital world you can safely count on people being familiar with common metaphors like the traffic light. In Hackaball we’ve used a traffic light animation to indicate readiness for game play.

The Game Starts animation uses the traffic light metaphor

Even more familiar, however, is the idea that an illuminated LED means the product is working. Similarly a light animation can signify dynamic actions of a product such as sleeping or processing information. Speed and rhythm are particularly relevant, with animations being anthropomorphised through metaphors such as the breathing light and heartbeat. Considerations here are the same as for screen-based animations where loading can appear faster when using a fast animation and events that require immediate attention, such as a battery running out, should be more easily noticeable than, say, a charging or sleeping indicator. Apple’s “breathing” light indicator, the ellipsis (…) typing indicator in iMessage and loading animations such as spinners and progress bars are all examples of digital communication that easily translate to new LED animations. Digital-physical designers should build on the knowledge that people have acquired through use of digital products.

Sleeping animation using a ‘breathing’ light

An example of how we implemented this in Hackaball is the sleeping animation. Single LEDs are slowly going on and off after one another in a random sequence. The LED lighting up is always mirrored by an LED on the opposite side of the ball, so that from whatever angle you look at it there’s always a light animating, and it never looks as if it’s been turned off. Inspired by ‘breathing’ lights, which are based on the physical body, our lights faded very slowly with long pauses in between the fades to suggest deep rest. For charging we reused the same animation but changed its colour to orange. We want to discourage users from actively playing with the ball during charging so having the charging animation resemble the slow sleeping animation is a suggestion to be gentle with the ball.

The Waiting animation — a calm animation for when the ball is waiting for user input

The waiting animation communicates Hackaball’s most neutral state. It’s a calming, pulsing blue light. It is slow, but brighter and faster than the sleeping animation. The ball is awake and awaiting instructions to play a game, pair to the app, or try out game actions.

Pairing and Firmware animation

Our most active light animation is the one indicating pairing and receiving firmware. A white light spins around to show that the ball is processing information. For both actions we wanted kids to be very aware of what the ball needed, so effort was put into making it very noticeable. The speed also helps in making a longer process such as updating firmware seem quicker in the same way as spinners in screen-based interactions.

So did our skills in digital translate to digital-physical products?

Yes — and it’s likely that they will for you too. The Product Thinking that helped us create a wide variety of digital products has a lot of overlap with a digital-physical product design process. User experience and iterative design are both key to digital design and industrial design. Hopefully you’ll be able to bridge the gaps that remain with our tips. In summary, to up your game in IoT design skills:

  • Create a strong brand to make product and app feel like one single experience
  • Experiment with LEDs and materials to get an intuitive understanding of light in physical products
  • Decide on a common language for communicating light designs across disciplines

And

  • Build on existing design patterns to communicate product messaging

Thanks for reading — and I hope you feel inspired to go out and build the next generation of products!

We’re excited about the IoT product space, so contact us on newprojects@madebymany.com if you’d like to work with Made by Many to realise your next IoT product.

We found a very last batch of Hackaballs! Buy them on our website.

If you’d like to understand what it meant for Made by Many to take on a side project like Hackaball read Stuart Eccles’ article or Tim Malbon’s. Our pre-Kickstarter design process was also really nicely documented at Core 77.

A big shoutout to the designers who’ve made Hackaball the beautiful, fun and educational product that it is: Alex Harding, Mike Walker, Sam Small, Tom Harding, Owen Thomas, Tom White and Ian Bach and industrial designers Ben King, MAP’s Julie Arrive, Jon Marshall and Jacky Chung. Thanks also to Julian James, Seb Potter, Jamie Mayes, Richard Ling, Rachel Mercer, Valentina Etaghene, Matt Williams, William Owen, Peter Parkes and all the great many people who’ve worked on this project without whom it just wouldn’t exist!

--

--

Melissa Coleman
Made by Many

Creative Technologist | Curator | Artist working on Hackaball at Made by Many ❤ IoT, wearables and diversity