RGB Keyboard Lighting

HP has been a juggernaut in the PC hardware industry for many years. With many business and commercial desktops and notebooks out, HP decided to test the waters in the gaming industry with their acquisition of the PC Brand, Voodoo. While HP did release a model few years back, it wasn’t until I joined the team in 2016 that HP decided to jump headfirst into the gaming industry.

Now completely rebranded, OMEN’s mission is to increase gameplay efficiency by giving users easy access to control their hardware and software gaming settings through an application called OMEN Command Center. Through features such as overclocking, lighting, and macros, OMEN Command Center hopes to be the one-stop spot for all PC gaming settings.

One of the key features of the OMEN notebooks is RGB keyboard lighting. Every key on the keyboard will be programmable, so each key could theoretically be a different color. Because OMEN was late to the gaming industry, and there are other competitors with similar capabilities, the OMEN team was doing what it could to catch up with the market. For first release, the goal for the RGB lighting feature was to create the product fast and bring it to the market as soon as possible, not to design for differentiators from our competitors.

Fig2. OMEN X 17 with RGB capabilities

Wouldn’t it be great to see the lights on your keyboard pulse to the sounds of each kill? Or to have all your macro keys lit up so you can kick some ass next time you play Overwatch?

While HP took a break from the gaming space, other companies like Alienware and Razer have completely revamped the gaming experience. To get a better understanding of the market and what gamers thought of lighting while gaming, we first jumped into the research phase.

As with other projects, I first talked to ten people (gamers and non-gamers) and had quick conversations with them about their thoughts on keyboard lighting. This helped us gain insights into our user and not go too deep into the design process with biased assumptions. From here, we jumped into our competitors’ products to understand how they solved problems and how we could improve upon their user experiences.

Fig3. Competitive Analysis Comparison

From our initial research phase, the Product Manager and I came up with 3 sets of priorities that matched both the business and user goals.

1. Intuitive Design - Easily allows users to do basic lighting changes without confusion
2. Competitive Parity- Ensuring that our preset animations are at par is not better than our competitors
3. Suprise Delights- Create new and unique animations that's OMEN only

Looking into our competitor’s products, we found most of them to be confusing and difficult to make simple changes. Our competitors included tons of functionality into their applications, but without a good foundation, they ended up making the interface too complex to use.

Despite their confusing UIs, competitors did have a lot of features that would genuinely excite users. With lots of preset animations (wave, sparkle, etc.), templates where specific keys are lit up based on type of games( first person shooter, multiplayer online battle arena, etc.), and fully customizable keyboards, our goal was to bring these same features into our product but to design them in a more intuitive way.

While working on the design process, the product manager and I were simultaneously working with our vendor to perfect our animations. Most of our competitors had similar animations (wave, color cycle, sparkle, ripple, etc.), so those were all ones we wanted to make sure we included as well. In addition to those animations, the industrial design team created two more that were OMEN specific: the OMEN X, Raindrop, and Audio Pulse. We gave these animations to our vendor and after the first iteration, they sent us a keyboard prototype to play around with.

Fig4. Still from a video sent to the vendors explaining the changes needed to be made

It took us three iterations to get to our final version of the animations. We had a back and forth conversation with the vendor asking them to tweak colors, timings, speed, and size. While there were additional changes we would have liked to make, we were forced to focus fully on the software design process due to upcoming deadlines.

Building upon the different experiences we’ve seen, we arranged the content in a way that seemed more intuitive. The best experience we had seen was Razer’s UI, but they made a lot of choices that were not easy to understand. The basic animation customization was shown upfront but a lot of the static controls and advanced settings were hidden. Using our current structure in the app, we came up with the first iteration of the lighting architecture.

Fig5. Initial idea for RGB lighting architecture

To better understand how users categorized the same information, we did a quick usability test with ten internal gamers. We first asked them general questions on if they owned a RGB keyboard and their thoughts on it and then we held a two step test; We started off with a card sorting exercise and then showed them the mockup of what the architecture could look like.

While it was pretty intuitive, most users wanted to recategorize the information. They felt Audio Pulse was a type of animation, Custom should be a part of Static as each key could only be one color, and Off seemed liked it should be a mode and not a separate toggle.

Fig6. Cardsorting exercise done with gamers

Fig7. New architecture for RGB lighting

When we ran that UX Research and Usability study, we asked the users a lot of questions on RGB keyboards, their thoughts on the functionality, what they would like on an RGB keyboard, and if they owned one, their thoughts on it. Based off the users’ answers, we chose two personas from our list that represented the users the most.

Fig8. Personas used for RGB lighting

Using our Research studies and Personas, we started to map out a Customer Journey Map to pinpoint users needs, goals, and thinking throughout the entire experience. With this information, we were able to conduct task analysis. With many different options to customize your keyboard, creating a flow was extremely important in finding the path that made the most sense.

Fig9. Customer journey mapping

Fig10. Task flow for RGB lighting

With our task flows complete, we were able to start working on the wireframes and added more details to each of the screens. Our visual designer then went in and turned the wireframes into full mockups. Using a simple Invision prototype, we tested our designs with internal gamers. While there was some great feedback, it was hard to understand what users thought of the actual experience as Invision was very limiting. The RGB keyboard is a very hardware dependent feature, and we wouldn’t be able to get useful feedback till our developers finished building the product.

Fig11. Initial Mockups

When our development team finished building the experience, we decided to conduct full Usability Testing through a research facility called Nichols Research. Through them, we were able to get enough gamers over a two day period and were able to show them the product.

While our researcher was talking to the participants, the rest of the team took part in collaborative note-taking. Each person was to take notes and write one piece of information on a single post it. Each post it was color coordinated by Observations, User Quotes, Opportunities and User Needs, Problems, and About the User. After each session, we put the post-its on a chart, and discuss the things we observed during testing. Through this, we were able to:

‍1. Gain insights and develop high-quality solutions through diverse points of views,
2. Engage all team members constructively,
3. Generate top findings, and
4. Demonstrate to stakeholders how fast we can gather actionable information

Fig13. Collaborative note-taking during usability testing

Our findings were that most of the interface was extremely easy to use and very intuitive. Most users had no issues with the interface and asked when they could get their hands on the product.

While most of the interface was solid, there was one section where every user was confused. Under Static, there is a section called Custom where the user could essentially make every key a different color. Within this section, the interaction for setting a color to multiple keys at a single time was not understandable to users and many people could not figure out the task we had given them.

Moving into the final iteration, we made changes based off of the feedback we received during the Usability Testing. While that interaction was a definite must to change, there was another interaction that came up during testing that we wanted to implement.

Users wanted to select keys to change the color of them in different ways. Some clicked on each individual key and held down shift at the same time to multi-select keys, but some dragged and held their mouse down over a section of the keyboard to select multiple keys at once. While this was in our original plan, our development team could not implement this in time for first release. Moving forward, this is something we’d like to implement in the following release.

Fig14. Final mockups