Grammarly Keyboard and Usability Suggestions
By Nathan C. Nagy (n.c.nagy1[at]gmail.com)
Grammarly Keyboard is an alternative keyboard to the stock virtual keyboard that comes on the user's phone. There are many keyboards to choose from for Android users, but Grammarly keyboard possesses a unique value proposition. Its integration of Grammarly advanced grammar checker into the keyboard offers increased confidence in producing high-quality error-free mobile communication.
For any business software that includes text input capability, extensive understanding of UX design can play a crucial role in assisting users in catching typing/grammatical errors that they make, enhancing the utility and the desirability of the app.
The app is considerably well designed. I am especially impressed by their adaptation of the word suggestion row found above most virtual keyboards to integrate advanced suggestions from the integrated Grammarly service. Each individual suggestion is contained inside its own box with white small text above the suggested text change indicating the category of the suggestion such as spelling, and various types of grammar suggestions. By pressing on a suggestion or the top left Grammarly logo the user is presented with a panel further explaining the type of error and the offered suggestion. Bright green boxes on the top right corner indicate when an auto-correction occurs. This well thought out design choice is highly effective at bringing to the user’s attention that the software made an auto-correction, helping the user to avoid any embarrassing autocorrect errors. As far as I know, currently there is no mobile virtual keyboard that has put as significant consideration into solving this issue despite how frequently auto-correct errors occurs in daily use of smartphones.
Usability Problems and Suggested Design Solutions
Problem 1
I will start off with a major usability issue that is the most straightforward from a design perspective to fix: the lack of a simple way to ensure what the user is typing is “secure” and not being uploaded to Grammarly services. When typing in passwords or typing other sensitive material, many users would want to have the peace of mind that the keyboard they are using in no way can compromise this information. The easiest way for a Grammarly keyboard user to ensure this is to switch to another keyboard such as SwiftKey or Gboard. Obviously, forcing users to install and switch to another keyboard app is not in Grammarly’s self-interest.
Other virtual keyboard competitors such as Gboard or the previously mentioned SwiftKey can be looked to for inspiration for a solution. Both keyboards offer a “private mode” that is intuitive for the user as they can understand what the feature does already from their experience with most web browsers with such a feature. To indicate the mode is activated in other keyboards, there is a consistent visual cue such as the appearance of an icon and/or changing the colouration of the entire keyboard. The UX challenge of implementing such a feature for Grammarly keyboard is visually communicating that certain features are no longer available when the private mode is activated. My suggestion is to have a private mode icon beside the top left Grammarly logo that is also crossed out when the mode is activated to communicate that the keyboard is no longer connected to the online service (as shown in the left image of Figure 1). Informative text about the private mode should be located in the suggestion panel displayed when the user presses the Grammarly logo (see the right image of Figure 1).
Figure 1. Integration of a "Private Mode". Keyboard view on the left and edit suggestion info panel view on the right.
Problem 2
The next usability problem I found was the smallness of the white text categorizing the type of grammar error being corrected. The font size of the text may be difficult for individuals with visual impairments to read. This issue can be somewhat mitigated via the already existing option to select from three different heights of the keyboard appearance where this text may be increased to about font 10 on a 5.5-inch screen. I suggest the additional inclusion of symbols to augment the small text to indicate the suggestion category (see left image of Figure 2). This design change would not just be better for users with visual impairments, but the symbols will aid average users to more quickly comprehend the nature of the suggestion. As a user becomes more familiar with the symbols, the user will immediately recognize the symbol without the need of reading the smaller text reducing cognitive workload while composing a message. An option can be included for experienced users of the keyboard to only show the icons so the keyboard will take up less vertical space leaving more room to display the text being composed.
Figure 2. Inclusion of icons in addition of icons with suggestion text to indicate edit suggestion (left) and advance option displaying only icons (right).
Problem 3
The final issue I observed was in terms of user workflow. Often times, a user may want to temporarily deactivate auto-correct when, for example, writing foreign words but may forget to reactivate auto-correct after they are done. The user may continue typing in the wrong mode for a while, trusting that their basic typos or purposely abbreviated spellings will be auto-corrected, before they realize that auto-correct is off. This issue can be alleviated by a constant and clear visual indicator of the current auto-correct status. I suggest a crossed out icon to appear when auto-correct is off in the location that the autocorrect notification usually appears (top left corner; see figure 3).
Figure 3. Inclusion of an icon to indicate that auto-correct is disabled.
