Usability Review
What I think about Google Docs
A heuristics check on the collaborative side of Google Docs
A couple of days ago I came across this problem statement which needed me to critically review the collaboration workflows in Google Docs.
Google Docs is an excellent online word processing platform with some of the most advanced features that focus on increasing work efficiency and delivering excellent User Experience. Among these, Google Docs provides some features which are focused upon aiding collaboration among teams and individuals while working on documents.
I have listed the major collaboration related tasks and I have critiqued my experience of using Google Docs to achieve those tasks. I have also identified the pain points and scope of improvement based on my critique.
Disclaimer
All of the observations, critiques, and suggestions are solely based on my comprehension and experience of using Google Docs.My conclusions might change after actual user research and testing. While writing this critique, I did not consider any kind of business, technological, or other resource-based constraints.
This review/study is part of my learning as a student of Design and is in no way an attempt to mar Google Doc’s online image. No copyright infringement intended.
Major Collaboration Related Tasks
After careful examination of the interface and analyzing the workflows, I came to the conclusion that users wish to achieve these three major collaboration related tasks:
- Share Documents with different people
- Exchange Reviews and Suggestions
- Work collaboratively with colleagues
Collaborative Working with Google Docs
Google Docs provides a set of features to achieve the above goals.
- Share Documents: Share documents with different permissions
- Comments and Tasks: Add comments and assign tasks to collaborators
- Collaborative Editing in real-time: View, suggest or edit documents with collaborators in real-time
- Version History: Create and manage different versions of the document
- Suggesting Mode: Suggest changes directly in the document
- Chat with collaborators: Chat with collaborators and reviewers in real-time
Nielsen’s Heuristics
To proceed with this review, I’d like to use Nielsen’s Heuristics. These heuristics are general principles for interaction design. They are called “heuristics” because they are broad rules of thumb and not specific usability guidelines. I believe they can be helpful in a review like this.
Note that I’m not following the typical Heuristic Evaluation Method as it often requires more than one participant.
Severity Index
I’ll be using a severity index to rate and prioritize the problems based on my observations and conscience. This approach will help us identify and segregate the ‘major’ and ‘minor’ issues on a more comprehensive quantifiable scale of 0–5. Higher the severity index, severe the issue.
Reviewing the Experience
Based on the heuristics and general design principles, I found 25 usability issues in the collaborative workflows of Google Docs. I have pointed out the major violated heuristic and graded their severity according to the severity index.
Issue#1
Unable to share a document with different people with different permissions and message at a time
Severity: 2
Heuristics Violated: Flexibility and efficiency of use
Description: Whenever adding people to a document by their email, a user cannot add different permissions for different emails, everyone added will get the same permission and message. To give different permissions the user has to go through the share document process again and then change the permissions for different people. Although the usage frequency of this feature is quite less during the lifecycle of a document I guess an interaction that solves the permission mapping to collaborators while adding them to the document will result in increased efficiency of work.
Issue#2
By default the ‘Get Link’ configuration is set to ‘Restricted’
Severity: 0
Heuristics Violated: None
Description: In the Share Document modal, the configuration of the ‘Get Link’ is set to ‘Restricted’ which means only the people added to the document can use the link. If no one is added then it redirects the flow towards the ‘Add using email’ and while adding the people through that flow, invitations are sent through the email itself, which makes me question the usability of the ‘Get Link’ function. If some people are already added in the document, and a user wants to share a link to an outsider, it is quite possible that he copies the link and sends it without knowing it is restricted as it is not visually evident enough. I believe that the ‘Get Link’ function is generally used to send documents to outsiders so the preferred default option should be ‘Anyone with the link’.
Issue#3
The link configuration status of the ‘Get Link’ function is not prominent enough
Severity: 3
Heuristics Violated: Visibility of system status
Description: The Get Link function has two configurations — Restricted & Anyone with the link. Now while using the get link option, I went on directly copying the link without reading the grey colored copy. It looks like some ‘not-so-important’ text and doesn’t look like a switchable option. I believe most users will go on ignoring it as happened with my friend — Akshay; I asked him to share the link of a test document with me and he just clicked on share and copied the link without even noticing the configuration. Some aesthetic changes can fix this like if the option looks more like a switch or maybe we can have a prompt every time someone copies the link if it’s feasible in terms of the user experience.
Issue#4
The link configuration status of the ‘Get Link’ function is not prominent enough
Severity: 3
Heuristics Violated: Consistency and standards
Description: Continuing the same usability test with Akshay I found out this problem. Now the copy sounded a bit weird to me too but I thought it’ll work. On the contrary, when Akshay copied the restricted link and I pointed out that he copied the wrong one, still he wasn’t able to figure out what to change and where to click. I believe it had something to with the visibility of the change button or the language used or both. I think we need a better interaction method that solves the problem of showing the currently active configuration (Restricted/Anyone with the link) and switching between them.
Issue#5
The ‘Done’ button leads and misleads
Severity: 2
Heuristics Violated: Match between system and the real world
Description: Alright this one’s a bit controversial. So I believe that the reason for keeping a Done button in these modules is for the purpose of acknowledgment workflows i.e. for checking who is added to the documents and pressing done or maybe copying the link and pressing done to mark the process as complete. But I think in some cases the done button is a bit more prominent than required. For example, when copying links from the expanded bottom modal, there are high chances of pressing the done button then the copy link button which makes the user open the Share dialogue again and going through the same process again. Basically clicking the Done button closes the Share dialogue but it isn’t clear enough because words like Done & Complete refer to the successful completion of a process whereas here the Done button works just like a Close button.
Issue#6
Permission visibility in ‘Get Link’ modal is quite weak and prone to ignorance
Severity: 1
Heuristics Violated: Visibility of system status
Description: While getting a link for ‘anyone with the link’ the permission status for the link (viewer/commenter/editor) is shown in plain grey text. I believe showing them with more priority may help with more context and the possibility of ignoring it may decrease.
Issue#7
Top and bottom modal clickability
Severity: 0
Heuristics Violated: None
Description: I don’t think this a usability problem. It’s a better and more contextual replacement for using tabs. The only thing I’m a bit doubtful about is the clickability of the modals. Both of them are clickable but I think it would have been a bit more intuitive if the cursor turned to a finger-pointer on hovering. Overall, it’s an awesome modern and fluent interface and I like it.
Issue#8
Collaborators’ details are not shown upfront in the mobile version of Docs
Severity: 2
Heuristics Violated: Visibility of system status
Description: In the mobile version of Google Docs, showing collaborative information becomes a challenge. Details like the name of the collaborator on the cursor are only shown when it is active. Also, the names of all the collaborators of the document are not shown upfront — probably one of the trade-offs for the responsive version of such a powerful tool. These are minor usability issues but I don’t think they caused a lot of problems while working.
Issue#9
General comments about the document are not possible
Severity: 2
Heuristics Violated: Flexibility and efficiency of use
Description: Comments are generally linked to a piece of text. So the contents of a comment are a point-out or a reference/review to that piece of text. But for the minute cases in which the reviewer wants to make a general comment about the overall document, it’s not possible! A simple soution can be adding the option to comment independently without referencing a piece of text.
Issue#10
Unable to find a particular comment
Severity: 3
Heuristics Violated: Flexibility and efficiency of use
Description: After making a comment there’s no way to search for a comment if a remember a keyword or the name of the tagged person. You have to manually scroll to find a certain comment. If the number of comments increases over a certain value, it becomes virtually impossible to find a particular comment. A basic search option can solve this issue.
Issue#11
Segregation of comments
Severity: 3
Heuristics Violated: Flexibility and efficiency of use
Description: Comment management becomes inefficient once the number of comments goes over a certain value. There’s no way to sort/filter the comments based on the resolved/unresolved state or by the assigned person. There’s no way to sort comments by date or urgency. Some filter/sort options can be added to solve these issues keeping in mind that these options don’t overwhelm the user.
Issue#12
Link to the text not shown on the comment (in the workspace)
Severity: 2
Heuristics Violated: Visibility of system status
Description: Every comment is linked to a text piece and that linked text is shown in the comments in the comment history box but isn’t shown in the comments in the workspace. Instead, clicking on the comment highlights the text linked to it. I think a better approach can be used inspired by the Grammarly editor where the linked word can be highlighted when the user hovers over the comment and the linked text can also be shown in the comment just like in the comment history box.
Issue#13
Resolve button on the comment cards seems disabled at first sight until it’s hovered on
Severity: 0
Heuristics Violated: None
Description: The Resolve button on the comment cards seems disabled due to its looks and feel until the users hover on it and it looks like an active button. I don’t think this is a usability problem but perhaps a design decision taken by the Google Docs team to avoid distractions for the user.
Issue#14
Add comment button disappears once a comment is made on a text piece
Severity: 0
Heuristics Violated: User control and freedom
Description: After selecting a text, add comment button appears on the right side of the page. After making a comment, the button disappears. If you select the same text again, the comment button doesn’t appear instead the previous comment appears. I don’t think this is a usability issue but actually, a good feature that helps keep the comments segregated and managed in a single thread. Although the system doesn’t strictly prevent the users to comment, the comments can still be added from other add comment buttons.
Issue#15
Add comment and Notifications
Severity: 3
Heuristics Violated: Consistency and standards
Description: The notifications and add comment buttons feel quite of place, both are placed at the same place but they perform two different kinds of interactions — one is a settings module and the other one is an add component CTA. I think they should be shown differently. The notifications settings module should also show the current status of notifications unlike now where one has to open the notification module to check the status.
Issue#16
Poor discoverability of the suggesting mode
Severity: 3
Heuristics Violated: Recognition rather than recall
Description: My opinion about the suggesting mode is quite positive. I really like this feature but I believe the poor discoverability of this feature results in a lot of users never even discovering it. I understand the current placement of the feature is quite logical and it can work great if a user is told about it once but currently I don’t think it is something intuitive. People who don’t know about it still prefer to use comments — as I got to know from one of my friends — Sejal (frequent Docs user). After talking to her on phone I got to know that she preferred to use comments for every kind of communication with her peers, she didn’t even know or cared that suggesting mode existed and was reluctant to start using suggestions when I told her about the feature.
Issue#17
Unable to resolve suggestions in the comment history
Severity: 0
Heuristics Violated: Flexibility and efficiency of use
Description: I don’t think this is a usability issue. It’s probably one of design decisions taken by the team to avoid errors while approving or declining suggestions. Suggestions are precise changes in the documents and the changes get accepted or deleted with the click of just one button. Such changes must be handled with care and need more context while interacting with them. So, according to me, it’s good that the user isn’t allowed to resolve suggestions in the comment history.
Issue#18
Usability of the suggesting mode is not conveyed
Severity: 2
Heuristics Violated: Help and documentation
Description: Once in the suggesting mode, a user requires more than just a micro-copy to figure out how it actually works. It’s mostly unclear until one actually makes changes and then observes to understand how the feature actually works. It works fine for now but the onboarding can be made a bit more contextual probably by using images or gifs just like Adobe Photoshop 2020 uses to introduce its tools.
Issue#19
Version name of the document is not visible
Severity: 3
Heuristics Violated: Visibility of system status
Description: The current version of the document is not visible. ‘Saved to Drive’ isn’t enough context and I believe the version name should be shown so the user should be clear which is the current version and what changes are made or should be made to the current version. Additionally, an option can be provided to save the current state to a specific version with features like overwrite and restore.
Issue#20
Poor discoverability of the Version History tool
Severity: 3
Heuristics Violated: Recognition rather than recall
Description: The current process of accessing version history goes through the file menu but it’s not intuitive enough. Although most people may remember it once told. The current decision to keep it buried in the menu was probably a usability data-dependent decision but I believe a small icon/link can be kept in the workplace upfront to increase accessibility. I really like this feature and I feel it is a bit congruent to the git version control system.
Issue#21
Unable to search for a particular version
Severity: 2
Heuristics Violated: Flexibility and efficiency of use
Description: In case the number of versions increase, version management becomes tedious. Searching for a particular version becomes a real tough job. Although I can’t say how many versions of a document are made generally. In the end, adding a search option is a data-dependent decision.
Issue#22
Unable to filter/sort changes according to collaborators
Severity: 2
Heuristics Violated: Flexibility and efficiency of use
Description: A filter/sort feature for the changes made according to the collaborators can be helpful to quantify the work done by each collaborator and can help in the constructive benchmarking of the collaborators. Such data can help the organization monitor the working efficiency of the employees. Although I’m not sure if this is a correct way of judging someone’s working efficiency.
Issue#23
Poor discoverability of the chat feature
Severity: 3
Heuristics Violated: Recognition rather than recall
Description: Let’s talk about this chat feature. One of the weirdest chats I’ve ever observed or probably the only one. The chat icon does not convey the presence of a chat feature unless you hover and it shows a tooltip and it is only visible when more than one collaborator is working together. The chat option should be made more prominent and optionally a text like ‘Chats’ can be written with the icon to make it obvious.
Issue#24
Chats and chat history are deleted after every session
Severity: 4
Heuristics Violated: Error prevention
Description: For some reason, Google Docs decided to keep these chats sessional and they delete the history after each session. I think they were intended for some informal conversations. Hence, it is quite different from conventional chatting platforms. The thing that bugs me is that the system doesn’t convey this anyway. It isn’t until you chat once, log off, and then reopen the document later only to know that the chats have disappeared. A simple micro-copy can save this from happening which can warn the user about the sessional chats and that they are cleared after every session.
Issue#25
Chats can’t be accessed on the mobile version of Docs
Severity: 3
Heuristics Violated: Flexibility and efficiency of use
Description: Let’s talk about this chat feature. One of the weirdest chats I’ve ever observed or probably the only one. The chat icon does not convey the presence of a chat feature unless you hover and it shows a tooltip and it is only visible when more than one collaborator is working together. The chat option should be made more prominent and optionally a text like ‘Chats’ can be written with the icon to make it obvious.
My Thoughts
Google is an organization with highly skilled individuals. I believe the products made at google have a lot of thought put in them by some of the greatest heads of the design industry. So I think every decision they took had a quite broad and deep perspective and me critiquing those decisions as a part of the five-day design task is prone to misjudgments and errors.
Nevertheless, I tried my best to avoid deviations and keep my findings close to the domain of the problem statement. Suggestions welcome :D
What do you think of this review? Let me know!
