LIFX — Chrome Extension
Client / Company: Independent project using LIFX API.
Role(s): UX Designer, Developer.
Contributions: General Feature Concept, Main User Flow, Wireframes, Front-End Code (HTML, CSS, JS), Backend Logic (JS, Ajax, Chrome Dev.)
Final Result / Deliverable: A fully functional Chrome Extension that allows users to control their LIFX lights from their Chrome Browser. More than 700 active users.
LIFX is slowly becoming one of the leaders in the connected lights segment. Its quality has been widely documented by consumers and journalists. Most of them agree that LIFX exceeds the performance and quality of other competing products like the Philips Hue.
However, one common complaint among customers is that LIFX lights software still doesn’t match the quality of their hardware.
One of their problems is the lack of control clients for different platforms. Since LIFX has an open RESTful API, I decided to tackle this problem and create the first Chrome Extension for LIFX (one of the most requested platforms and one that could also help users who desire native OS solutions to control their lights).
How to design and create a lean multi-purpose light control system for LIFX, that can live in a browser as an extension and can help users to achieve the level of control they get from the official mobile apps?
The whole motivation to create this Chrome Extension came from my own frustration. This frustration was mainly related with the fact that LIFX app offering didn’t having two things I considered vital to have a reasonable User Experience with my lights:
- The ability of controlling the lights from my computer. As a heavy laptop/desktop user this is a no brainer. Being able to control the lights from my work station is far more convenient that unlocking my phone and going through all the steps required to do it from the app. Context switching is an expensive UX sacrifice, and having changing devices has a very high context switching cost.
- LIFX does a great job at providing mechanics that allow users to achieve different light states and save those states as scenes. However the hierarchy of their app is excessively plain. For users this can be confusing since it’s hard to draw a line between setting up new scenes or activating previously created scenes. Even though their UI tries to be clear about this, as a user I find myself more times playing with new states than activating previous ones. This also has an expensive impact on the final user experience.
I knew that my frustration wasn’t exclusive to my persona, so I did a small validation exercise to determine the size of the problem and get a clear idea on where should I put my design and development efforts.
The first thing I did was to check if there were competing solutions. I did find a couple but I didn’t have to dig further to find out that these solutions simply didn’t work for LIFX users. Here are some of the reviews I found on an extension that claimed to be a LIFX compatible control:
I also gauge the interest for a Chrome Extension by doing a social media search. After a couple of minutes I was able to find requests like this one:
It was clear that users wanted a desktop solution to control their lights. A Chrome Extension was the perfect fit since it could be a OS agnostic solution and provide the value that many users were looking for.
After doing this validation I started working on some initial design concepts. I started with a simple heuristic that and sticked to that heuristic through all the design and development process. The heuristic I chose as the main driver of the process was: Minimalism.
I chose Minimalism as the main driving heuristic for this project because it was syntactically what I would expect from any software that claims to be a good user experience to control connected lights. Minimalism in the context of this project means:
- Fewer and less compromising choices.
- A leaner and simpler user interface.
- An unambiguous user goal and clear path for that goal.
Having this clear I started designing potential solutions that could exist in the constraints of a Chrome Extension dialogue.
Here are some of the initial sketches and idea deliberation that encompass my design reasoning:
After exploring more options I decided that I wanted to started with a simple approach that would work on the premise that any user could control their lights in a simple way by following a simple path:
Choosing a Light/Group of Lights > Changing Brightness > Changing Color.
As a heavy LIFX user I had the confidence that most users asking for a desktop version of the LIFX app, were looking for a simple solution that would allow them to simply tweak the brightness (or turning off the lights) and maybe changing the color.
I used some diagramming and charting artifacts to map an flow architecture that could help me to visualize different angles that achieved the minimal desired path I established. I also explored alternative paths to apply Scenes, which are the built-in LIFX property aggregators. Here is one of the final flow artifacts I used to determine the extension layout:
Although I wasn’t sure about what the dimension of the options appropriate to suffice most use cases, I stuck with my main heuristic and put together a design that gave users just a few brightness and color options.
Here is the main value proposal and design as explained in the promotion website of the extension.
The initial design I actually implemented and released followed the path I described before. The idea behind doing this was being extremely clear about the functionality.
Users who open the extension for the first time should be able to determine what to do in less than 4 seconds. This was my approach to achieve a UI with very low cognitive load.
After releasing the initial version of the extension I decided that I wanted to wait and see if it could get organic traction. This would prove that the extension was indeed solving a problem.
After one week of being released, the extension started to get some traction and users . Here are some of the initial reviews:
The initial reviews were pretty positive, but as shown in the example above there were some things I left out that were degrading the overall experience. I quickly learned that people did use groups (I don’t), so it was pretty important to bring support for this. Additionally, there was an embarrassing thing I overlooked. Of course users want to change the color of their lights, but they are most likely going to change between warm and cool, rather than between spectrum colors.
My first iteration of the extension was a quick update with support for groups + neutral color selection.
The process of iteration has been a continuous task. As the extension keeps getting new users, multiple new requests show up on my inbox.
Part of my process involves evaluating all the requests, determining the technical feasibility of those requests and then evaluating if they are aligned with the original heuristics of my design. If a request seems to oppose the Minimalist nature of the extension, I try to dig more into the problem and identify why a users is requesting a certain feature. Many times users might be dealing with a bug or perhaps they are hitting a usability wall. Staying true to your heuristics is a way to scope down problems and reveal unidentified issues.
Here is another example on how I approach this part of the process. For instance, not so long ago a user requested a way to set timed states in the extension:
This would be an awesome feature. The API gives support for this so there’s no need for developing a server side to handle this. However, at this point I had other competing requests. Since it’s hard to gauge the impact of this feature, this is a moment of the process in which is important to rely on the original heuristics.
Is this a power-user feature? How much “minimalism” and simplicity is being sacrificed if this feature is added to the extension? Would users easily understand the functionality behind this feature? Is there a way to add this feature without adding friction to the whole process?
Asking these questions allow me as a designer to put these requests in the right perspective. It’s also a good starting point for a quick evaluation exercise like the one pictured below:
After doing a quick evaluation, it’s somehow clear that adding this kind of feature can be expensive and could play against the main heuristic.
It’s important to mention that this doesn’t mean that feature is not valuable or not achievable. This is just a quick evaluation on determining the complexity of adding this kind of feature. Since there are multiple other requests competing for the limited time that I have for this project, I need to find a method that helps me to bring the greatest amount of value to the end user. Staying true to my original heuristics is an unmatched method to achieve this.
Although evaluating feature additions under the light of a heuristic can bring clarity to the additive nature of creating software, it’s definitely important to contrast any assumption with available data (if there’s data to analyze).
One common request that I got in both emails and thread comments was the ability to activate scenes from the extension.
I personally don’t use scenes that much, but I know they are an important piece of the LIFX Ecosystem experience.
In order to determine the best design for this problem I analyzed some of the available data I was capturing with Google Analytics.
One particular subset of behaviors that grabbed my attention was the use of the dropdown picker. At this point the extension had support for individual bulbs and groups, and both could be instantiated from a row of radio buttons and selected from the same dropdown.
Here is some data that shows the event flow for that particular dropdown:
One interesting thing that can be appreciated in this flow, is that there are multiple users doing certain actions, then selecting a bulb and then doing something else with the new bulb.
This is something expected if you have multiple bulbs, but also I originally assumed that users were going to control those bulbs through groups and not necessarily scenes.
This gave me an important insight about the LIFX ecosystem. Users don’t care that much about groups and instead they use scenes as the principal mechanism to control multiple lights.
The raw data also proved me right on this assumption. The event that tracks the dropdown for groups is ranked very low against other user events.
After analyzing this data I was able to determine the importance of “Scenes” as a feature. Also the data gave me clear insights about the dropdown and the importance of the UI element in the general behavior of the app.
Originally I planned to add support for scenes using a complete new row of UI, but using the data I was able to determine that users were learning and understanding the concept of the dropdown picker. With this insight I was able to create an implementation that added scenes as another possible selection from the dropdown picker, instead of creating extra UI that would compromise the simplicity of the app.
Solution / Current State
LIFX Web Control is currently the only available Chrome Extension for LIFX and the only platform agnostic solution for the LIFX Ecosystem.
Currently it has almost 1K users and most of them are actively using the extension.
Although I have limited time, I keep adding new features and fixing issues as they present. The latest update includes different things like the ability of toggling ON and OFF lights (before this was implicitly built into the brightness controller). This was another feature that I carefully evaluated using data and a heuristic analysis.
I also added features to enhance user on-boarding like oAuth Login and Notifications.
This is the current state of the extension with all the different improvements that had been implemented based on the collected feedback and usage data:
You can also see the latest update in the Chrome Web Store, and of course if you’re a LIFX user, I encourage you to download the extension and give me your feedback.