Table of Contents
When it comes to designing a virtual keyboard for smartphones, most company leaders would flock toward creating a similar, if not identical, user interface to the well-known incumbents’ virtual keyboards. On iOS, it’s all about copying Apple’s QuickType, and on Android, it’s all about copying Google’s Gboard, right?
The typical conclusion for these leaders is the following: the smartphone user is typing on the stock Apple QuickType or Google’s Gboard, so why fiddle around and create a new interface design language when THE reference is right in front of you? Well, after spending many years in the industry, we’ve found this conclusion to be fundamentally incorrect!
Surprised? Let me explain.
Context
Let’s imagine for a second that we’re using the virtual keyboard from Apple like the image above.
The User Interface is grayish, it has bounded boxes surrounding each key, and the taps behave in a particular fashion. When you touch a key, the next word is predicted, and if you happen to swipe across the letters, it switches to swipe input. All the while you type, it autocorrects.
The keyboard changes languages smoothly, but it still has many issues some users can’t tolerate. It has flaws. Google’s Gboard does too, just like any virtual keyboard on the market.
Taking this as an example, here are my 2 most important advice when building your software keyboard app.
Number 1: Think twice before copying the stock keyboard interface
Coming back to the Apple keyboard user. Most product designers would actually design a copycat of the stock keyboard because “disturbing” the user with a new user interface is a recipe for disaster. People find comfort in familiar things, and like to stick with what they know, right?
Wrong.
With keyboards it’s the opposite. If you ship a copycat, you’re inviting the end user to compare your product with the iOS stock keyboard from Apple (or Gboard for Android users). This means that the user will naturally compare and flag whatever doesn’t correspond 1 to 1 with Apple’s stock typing experience.
Another issue surrounding the “product in use” is that if it is 100% identical to the default, how can you know which one you’re actually using? Your user won’t be able to quickly know if they’re using your virtual keyboard or Apple’s stock keyboard.
For the sake of the argument, if you compare an Orange with another Orange, you won’t be able to tell the difference between them unless you pay close attention to the details. This comparison most likely will result in you sticking with one or the other based on micro details. This said, if you now compare an Apple with an Orange, you’ll see they aren’t the same, and you won’t try and compare them at a micro level, but rather at a macro level. Both are spherically shaped, yes, but fundamentally different.
Our Fleksy keyboard products for iOS and Android, powered by our Fleksy SDK, have a very different look and feel because only in such a way can the end user clearly distinguish which one is Fleksy and which one is the stock keyboard. It also prevents the end user from comparing them with one another because they aren’t the same at all (apart from the fact that both are software keyboards!).
Also, the Fleksy keyboard SDK makes it easy to build your own branded look and feel. Take advantage of creating your own custom typing experience!
Number 2: The onboarding phase of a virtual keyboard app is crucial
On another note, I often see app descriptions that avoid mentioning the existence of a virtual software keyboard in their app illustrations and description. The issue with excluding the keyboard is that smartphone users will have to install and start using your app.
If they download your app thinking it doesn’t include a virtual keyboard, you’ll be creating a friction point, resulting in lower conversion and retention rates. Explain and illustrate your keyboard product front and center. It’s actually a very good differentiator.
Once it’s downloaded, the end user will have to set-up the virtual keyboard. Taking them by the hand during the installation process is key, especially on iOS. For Android, it’s a more straightforward process so it shouldn’t concern you.
At Fleksy, our existing clients are coming from various industries. For example, in Healthcare, our Data Layer helps clients understand, prevent or treat mental health diseases while the end-user types across SMS, Messaging or the Browser.
These companies keyboard apps’ onboarding experience is what I categorize as “incentivized” which means they’re involving the end-user emotionally (and mentally) to type on a new virtual keyboard in order to receive health benefits.
Compare Healthcare keyboards with Fleksy’s own end-user keyboard app which focuses on providing a high level of customizations and privacy, and you’ll see that healthcare yields roughly 50 to 75% higher conversion rates from a new app download to a keyboard daily active user.
Don’t get me wrong, Fleksy has a strong “customization” incentive for its users, but it’s not nearly as strong as the benefit of improving your mental health condition — especially if you really need it to live longer and happier.
Bottom line
The virtual keyboard is a very powerful user interface, capable of being present across any app on one’s smartphone. At Fleksy, we have one of the best third party virtual keyboard technologies in the world and our powerful software development kit provides companies and developers an easy way to integrate a custom keyboard app into their mobile app.
Whether you’re building a novel CRM mobile app, a Digital Phenotyping healthcare app or a productivity app, the virtual keyboard SDK from Fleksy integrates into your product in only 5 minutes. We are excited to help you out in your journey by providing the very best typing experience for your users. Get in touch today !
