Today we announced the launch of the Fontmoji keyboard; a project almost a year in the making. In this article I’m going to dive into some of the design questions that we encountered making this keyboard and how the goals of designing a keyboard have changed in recent years.
User behavior and the keyboard
Designing a keyboard in 2018 is vastly different than it was for the hundreds of developers that took to creating a better keyboard once Apple started allowing third-party keyboards in 2014. At that time, many users were very vocal about their displeasure with the standard iOS keyboard so third-party developers took to building a better mousetrap. Something that was easier to type on, faster, smarter ect. They wanted to build something to replace the iOS keyboard.
Over the years, user behavior has changed and people have become comfortable using multiple keyboards (thanks to emojis, Bitmoji and Giphy!). With a shift in user behavior came a shift in product goals. Our goal building the Fontmoji keyboard in 2018 wasn’t to replace your iOS keyboard, it was instead to design the best possible experience to co-exist with your other keyboards.
How to Avoid Keyboard Startup Suicide
We didn’t even try to compete with the standard iOS keyboard from a strictly ‘typing’ standpoint.
Instead we designed with the understanding that users would pop into the Fontmoji keyboard when they have something they want to say, and then pop back out to the regular iOS keyboard for their day to day texting.
Apple has done a good job of making this action of switching between keyboards a familiar user behavior. Part of this familiarity is because they made it the same action people take to get to their emojis that we need to add to every message we send! 😜
The standard iOS keyboard has made a lot of progress since 2014. They’ve added smarter auto-correcting (though it can still get you in trouble sometimes), “Quick Type”( their predictive text feature), and better options for accessibility. If you are an everyday iPhone user, you may not even realize how much you rely of these features until you try to type on another keyboard and find your text riddled with typos.
Apple has spent millions of dollars developing what is actually a very good keyboard (despite the gripes) and spending the time and money trying to build a keyboard that will be good enough for users to ditch the iOS keyboard and adopt a new one full time, can be a suicide mission for small startups.
What we focused on instead of full-time adoption, was designing the best possible experience while using the Fontmoji keyboard in conjunction with the standard iOS keyboard.
Fontmojify my words!
The first aspect of this is what we call “Fontmojifying”. The goal of fontmojifying is taking a text message that is already written, even if it is written outside of the Fontmoji keyboard, and converting it into a relevant fontmoji style to copy and send.
The idea behind this ties directly into the users behavior of switching between keyboards. We wanted our users to get to their ultimate goal of sending a fun and expressive message as quickly as possible. If a users types out a text, and then decided it would be better as a fontmoji, they can simply hit the globe to enter the fontmoji keyboard and their text message will automatically be converted into dozens of relevant fontmojis based on the keywords in their message.
Getting to the Fontmoji
Our ultimate goal is get our user from text message to a relevant and expressive fontmoji that they are excited to share in as few taps as possible. One method we implemented to guide users to tailored fontmoji recommendations in as few taps as possible is Tags.
As you can see in the example above, the tag “birthday” is recognized in the user’s text so we display their message in birthday themed fontmojis first. If they want to see other fontmojis they simply remove the tag by tapping the x or tap into a channel that interests them. We’ve found that using this method, our users choose a suggested fontmoji to send over 80% of the time!
Tap vs Long Press?
We had many discussions and did a lot of user research about the best ways to use tap and long press in the keyboard. Ultimately we decided, why not use them both?!
When a users sees the ‘fontmojified’ version of their text message, we want them to be able to copy and send that fontmoji as quickly as possible, but we also want to give them the option to open the fontmoji and edit it if they choose.
Our solution was using long press to copy directly from the grid view, and tap to open the fontmoji to edit.
The tap is consistent with the way our fontmoji cards act; once tapped, you are brought to a composition screen where you can type directly in that font. Because many stickers and gif apps use the tap as a way to copy, we were concerned some users may expect to copy the fontmoji when they tap it, instead of opening it to an editable state, so we once again decided to do both. When a user taps on a fontmoji, it both copies the fontmoji so they can go ahead and send it if that was their intended action AND it opens to an editable composition screen. The long press to copy and send without opening is more of a discoverable feature that we’ve found is a nice surprise for users.
Now that the app is live we get to see if the assumptions we’ve made are right or terribly wrong 😳🤞. We’re really excited to get user feedback and iterate on our findings. So please go check out the app and let us know your thoughts. Also leave any questions or comments about our design decisions illustrated above in the comments below and I’ll get back to you right away. Thanks for reading and if you enjoyed it, hit the 👏!