Since joining Microsoft, the SwiftKey team continued to enhance the personal ways that our users communicate with their friends.
We looked outside of conventional text input by adding GIF’s, predictive emoji, a clipboard and theme switcher - key insights from our user research team. This case study shows the process behind our toolbar - the platform that enables us to achieve our goals.
Create a common access point for new extensions, improve discoverability of existing features, and design a simple and easy to use navigation.
Our first keyboard extension - the clipboard, was placed in a menu that we use to switch keyboards, but this was less than ideal. We knew from observing users during usability testing that they struggled to find it hidden behind a long press and it wasn't a scalable solution for more integrations.
Our first keyboard extension, the clipboard, was placed in a menu that we use to switch keyboards, but this was less than ideal. We knew that our users would struggle to find it hidden behind a long press, and it wasn't a scalable solution.
Sketching & Collaboration
We used Invision Freehand to sketch out new ideas and proposals. It’s easy enough for any team member to use and initiates collaboration. A few different designs took shape, with a focus on the interaction with the candidate bar (the word predictions at the top of the keyboard).
From the sketches and conversations with the team we made a few prototypes. By creating quick design prototypes we were able to start a focussed discussion on the product and engineers began thinking about how to build it.
Combined search and menu with swiping interaction. This was one of the first prototypes that we made, and it's probably the closest to the design that we eventually shipped to market.
Combined search and menu, above keyboard. This design allows the user to leave the toolbar there at all times if they wish and has 100% discoverability as we can launch with it enabled. On the flip side, it takes up more of the screen and adds to memory issues specifically on iOS.
Seperated search and menu, with two access points. A simple design that seperates the search from extensions. We found that discoverability was slightly worse with more entry points, with some people missing search.
After a lot of discussion amongst the team and taking into account some potential tech constraints, we settled on a design to take forward. At this point I set about the visual design and animation details. As the search would be embedded in the toolbar, and in the subsequent emoji and GIF panels, it would be important for these screens to transition fluidly.
From the beginning, one of our aims was to increase discoverability of old and new features. In the past we've had success in subtle animations to grab the users attention, but had failed to implement the animations properly. We decided to build in our “red dot” notification into our toolbar button. This button has a few different states including the plus icon, and dismiss, back arrow as well the notification itself. The output is one small JSON file that can be controlled in code using Lottie. Another advantage is the ability to easily change the colours of the icon, including the notification colour, which needs to vary slightly for some themes.