Grammar and Spelling Checker
Designed to be a simple and elegant grammar and spelling checker tool for a document editing web app (WriteWay Writer), with the potential to expand in the future.
My Roles
Research
UX + UI Design
Documentation
My Tools
Figma
intro
The Brief
The launch of Writeway Writer was approaching, but it was still missing one key tool: Grammar and Spelling check. I knew from past interviews and research that many potential users would not even consider Writer if it did not check for grammar and spelling errors. Thus I was given the task of designing this tool.
In the initial meeting with the key stakeholders I learned about the general expectations of this tool:
simple enough to finish development in time for Version 1.0
compatible with the already chosen API (WebSpellChecker)
compatible with existing features (links, image objects, and text classes)
able to expand in the future (dedicated tab, settings, and dictionary)
The Process
explore
Competitive Analysis
After the initial meeting with the key stakeholders I began researching existing grammar and spelling checking tools. For example: Grammarly, Google Docs, and Microsoft Word.
From this I learned the most common colours, icons, and general flows for how a user expects a Grammar and Spelling checker to work.
Considering the Future + Edge Cases
For now we just needed an MVP, but I wanted to ensure that my designs could accommodate future feature expansions.
I began outlining where this tool might conflict with existing tools, flow diagrams, edge cases, pros vs. cons for features, and how user dictionaries could work with simple wireframes. Keeping an open communication with the developer who would be building this tool was also very informative. Something I noticed is that links with spelling errors posed a conflict of designs, as they had a lot of overlap in their interactions. For example, both of their on click pop ups appear below the error and link in question. I also began exploring how they could co-exist.
By considering the future and possible edge cases I had a better understanding of how this tool should behave, and everything I would need to outline in my future documentation for the developers.
4 Design Iterations
The first design iteration was simply a re-colour of the API’s UI. However this was not enough to fit in with the rest of the document editor, so I continued to iterate and experiment. As I continued to work the designs would also get simpler and cleaner, both to better match the document editor and to easily allow for feature expansion in the future.
For each version I would wireframe out a few use cases to see how well the UI would perform.
Throughout this process I would routinely check in with my team lead for feedback. Whenever it felt necessary we would also meet with key stakeholders, such as the CPO, to show my progress and ensure the design was meeting all expectations.
There was a lot of discussion over the ‘Ignore’ button early on and how exactly it would work. I encouraged following current standards based on my competitive research. This resulted in ultimately phasing out Ignore Once and only having Ignore All.
Out of Scope: Dialogue Box
A dialogue box allows a user to easily correct all of their errors as it jumps from one to the next automatically. I explored this feature through the first few iterations of the tool. Ultimately it was decided to be out of scope, but with all of my wireframes and simple prototypes it would be easy to implement in the future.
final designs
Documentation
Once all design needs were met it was time to stop iterating and begin creating the documentation. I designed a master component with all the variants it would need, which I learned from the explore phase. A new Figma page for the documentation was then created and broken down into 6 sections, with various prototypes to show the interactions in-depth.
view secondary documentation here
spelling error prototype / grammar error prototype / ignore all prototype
With this documentation the developers were able to successfully build the grammar and spelling checker. If they had questions I would clarify, and update the documentation if necessary.
Design Solutions
For one of the design problems, the overlap of links and this tool, the solution became one of my early concept sketches. Originally the link pop-up was also below the text, but it was redesigned to be above. The link designer and I worked together to ensure both of our tools could co-exist.
Reflection
Results
With this key tool, Writer become a viable document editor for many potential users. Without it many would have immediately dropped Writer.
Usability Tests
In other projects I was able to use a research tool called Maze, and gained many user insights from it. For example I created and ran an A/B test on two different versions for an onboarding experience. If I could go back I would use Maze to test the usability of this tool to see if there were any problem zones, especially with the more complicated interactions like an error within a link or image object.