Typing layouts
LEAD DESIGNER • Foundational user research • Design research • Interaction design • Usability research (prototyping) • Implementation and production design
SwiftKey Keyboard supports over 300 languages. During the time that I worked on the product, I designed typing experiences for languages like Farsi, Hebrew, Arabic or Japanese (this case study's topic).
Different languages layouts
Japanese layouts
In 2019 I led the design on the V-team that was tasked with improving SwiftKey's Japanese typing experience. The working group consisted of UX Research, Design, PM, Data, Community, Engineering and Languages teams members. We also worked closely with our partner team based in Tokyo.
Finished designs
PHASE 1 - Foundational research and exploratory design
Designing for a language that you don’t speak has to start with user research. In the first phase of the project all team members investigated in their areas of expertise to evaluate current SwiftKey's Japanese typing experience from different angles.
Process
Before proposing improvements I had to not only understand Japanese keyboards, and the machine learning techniques behind them, but also get the general idea about the language. I relied on input from experts on the team to understand details of behavioural typing problems.
Existing layout design critique
I worked alongside User Researcher. I moderated user interviews, talked to Japanese translator and ran layouts co-creation sessions. Informed by user feedback I evaluated our current layout's design and did competitors benchmarking.
Session with translator - illustration instead of a photo for privacy reasons
Overall we used the following qualitative research methods:
• surveying beta users,
• analysing support tickets to identify the main issues raised by the community,
• competitors benchmarking,
• interviews with experts: translator and native speakers.
For the quantitative insights we looked into language models performance and prediction speed modelling.
PHASE 2 - Design and executional research
After the investigation phase and prioritisation exercise I had a number of design areas to focus on. Combined, they would improve the overall typing experience.
Process
Hiragana, 12 key layout improvements
The 12-key layout had numerous visual design issues that together contributed to the feeling of business and the typing experience being difficult. I updated the layout based on insights from community tickets and interviews with native speakers. I also worked closely with our team in Tokyo to collect further feedback.
Improvements breakdown
We had to balance the number of design suggestions with engineering availability. My approach was to design incrementally and test with users to check if the experience is not compromised if we implement only part of the suggested changes.
Layout progression and prototype for testing
Improving Language Switching Spacebar
Some keys within layouts have specific micro-interaction. In a complex layout system, that supports hundreds of languages, some behaviours inherited between layouts didn't make sense in a specific language context. That was the case with the language switching spacebar. Its default settings didn't make sense in a 12-key grid where spacebar is the same width as character keys.
Key pop-up and language switching spacebar changes
New layout - 12 Key Latin
In SwiftKey, users can choose to type Japanese using Latin characters via the Japanese QWERTY layout or with Hiragana characters on the 12-key layout. When 12-key Hiragana layout is set as default, user might still need to occasionally input Latin characters (for names etc.). For that use case we needed to introduce 12-key layout that would allow for Latin script input but still return Japanese predictions.
I designed the layout based on the same grid as 12-key Hiragana. This layout includes numbers so I also updated the label on key that switches to secondary layout. Usually it is "123" but in this case it didn't provide any valuable information to the users, as the numbers were already displayed on main panel, so I swapped it with "1&+" characters that gave users better idea of additional characters they can find there.
12 Key Latin layout
Layouts navigation changes
With the introduction of this new layout our navigation patterns needed to change. Users can toggle between Latin and Hiragana and access secondary layouts from either. The secondary layout switcher key always leads back to Hiragana input regardless of which layout it was initially accessed from.
Navigation changes
Flick key behaviour - behavioural specs
In the 12-key layout style, users can insert letters by either cycling through the characters set or by flicking in the direction of the character they want. If flick is enabled key pop up will displays additional labels.
We added setting for users to choose whether the key responds to cycle, flick or both. That required design changes in settings, installation flow as well as detailed specs for engineers to implement cycle and flick across both 12-key layouts, including strings for accessibility mode support.
Prototypes for testing
Overall we ran three rounds of testing. Two sets of interviews with Japanese speakers that lived in London, all of them were bi-lingual and used English as well as Japanese in their daily typing; and one round with users in Tokyo that typed in Japanese only.
I explored couple of settings models. One, where the preference pops up at the end of language download flow, and another that ends on a language specific dedicated settings page. Although the second option tested better we didn't implement that flow. It would impact our settings model for all languages and was outside of scope for the project. The first option still passed the usability check.
Split layouts for Duo devices
SwiftKey now also works on the dual screen device - Microsoft Duo. That presents new sets of typing challenges and adds to the product complexity. While working on the Japanese project I was also supporting the effort of optimising layouts for two screen typing experience.
For QWERTY type layouts the longitudinal diary typing study results showed that splitting keys made sense for typing experience. For Japanese I recommended not to split the grid and instead leave it on one screen. We don't split 12-Key layouts for thumb typing mode on single screen devices and for Dual screen I applied the same logic.
Duo device frame with QUERTY and 12-Key Hiragana
Outcomes
All improvements showcased in this case study shipped to market. We collected positive feedback from our community.