When webOS went from using a physical keyboard to a digital keyboard, I designed all aspects related to the switch. This meant establishing how the keyboard interacted with system elements (e.g. textfields), designing how the actual keyboard worked in QWERTY, QWERTZ, and AZERTY, and also defining text correction rules.

I worked with usability team to test the wireframes, the visual designer to make it beautiful, and with the lead developer on a daily basis to make tweaks as things got built.
Design Lead
Product definition
Interaction design


I worked closely with the product manager and dev lead to define the product requirements since this was a brand new feature for webOS. We leveraged learnings from behavior on the physical keyboard as well as patterns of how people tap buttons and other targets on the screen.


Since our software keyboard was arriving a little later to the game than other mobile OSs, we could learn from their keyboards what we thought worked well, could be improved on, and places we could innovate. We did many user studies watching how users typed on iOS, Blackberry, and Android.


A lot of key stakeholders, many in upper management, wanted to add predictive text because of the apparent utility of having a row of words available to you based on what you're typing. However, after experiencing it first-hand, I felt it hurt the typing experience because it divided attention between continuuing to type letters or checking if the word I was typing has appeared.

My opinion alone wasn't enough to convince upper management, so we tested it to collect some real data. In our usability tests, we measured that people typed significantly slower with the predictive text than without it. We used that data to convince the key stakeholders to exclude predictive text.


I took the competitive research, user research, and early requirements and started sketching on paper ideas for the keyboard. One of the biggest pain points from other keyboards that we wanted to fix was the amount of switching between modes to find numbers or symbols. If you didn't memorize which mode each of those characters appeared, you had to search every time - a tedious, and sometimes overwhelming, process. So, we sought to eliminate switching modes as much as possible.


One of my ideas was to add an extra row of keys for the numbers. The device's large screen certainly allowed for it, so it was a matter of weighing the utility vs reduction in screen space. Visually, the number keys had to look different so they didn't interfere with looking for letters while typing. So, I made them half-height keys and a different color. As you can see below, the letter keys are still clear and the number keys sit where you know they're there but don't get in the way.

Another benefit of the extra row, was that it also allowed space for adding in commonly used symbols. Now, the keyboard started to resemble the physical keyboards that customers were already accustomed to using. They wouldn't have to learn how to use this keyboard.


After usability testing the initial design of the keyboard, I found that people ignored the key to the left of the spacebar, but found the layout to be very useful.

I also added a tab key as a way to either insert a tab or navigate between next and previous textfields just as a physical keyboard works.


In the final version, I worked with the visual designer to add in the visual styles as well as make some minor tweaks. One notable tweak was to make the enter button be text rather than a symbol. We found that users were confusing that button with the delete button.

Additionally, but not shown here, we added in the AZERTY and QWERTZ designs for international users, as well as defining which additional symbols would appear on each key upon a press and hold.