ClickUp Mobile Docs Product – UX Case Study
What is ClickUp?
ClickUp is a productivity and project management platform designed to help teams and individuals collaborate, document, and manage work efficiently. The platform provides a robust suite of tools, including task management, goal tracking, and an advanced document editor, allowing users to centralize their workflows in one place. By offering a flexible and customizable system, ClickUp empowers teams across industries to streamline their operations, improve productivity, and maintain transparency in their work processes.
Overview of ClickUp Mobile Docs design
Here we'll go through whole story from early idea and discovery phase to fully refined designs with a pursuit to bring next-level, world class mobile docs experience to ClickUp users
Design ClickUp Mobile Docs was a part of initiative of bringing its experience to the new, world-class level, giving users ability to read, manage, edit and collaborate on their Docs on the go.
Problem
Although first version of Docs designs was planned for a world-class solid document view & edit experience, in reality it never left rough, half-built MVP state due to lack of Eng resources at early stages, so overall experience was rather undeniably poor, and serving only need to be there for a checkmark open and read docs.
Part of the problem was that tech framework that was used for mobile docs editing wasn't native, making it almost impossible to provide decent level of visual and interaction experiences, especially with heavy list of text formats, block types, and other elements users need to be able to view consistently across Web & Mobile. There was no way to translate text formatting between desktop and mobile well, making it impossible to implement most of rich text editing, block types, page font properties, consistently.
Also generally, after 2 years in the market with Mobile app we collected a huge amount of user feedback, internal feedback, usability test insights and app usage analytics. It was just about time to make strong move on bringing Mobile Docs to next, serious, world-class level of mobile doc editing.
Solution
The only way to approach bring the mobile Docs to the next level and fix existing problems was feature redesign from ground, addressing dozens of small known problems and using leverage of strong Eng team that was able to implement whole new, Native editing framework.
Redesign included two major parts:
1. It addressed discoveries of user surveys, feedback of users on app platforms, customer calls analytics and UX research insights with aim to fix user problems and provide better experience.
2. Optimising mobile docs experience for both mobile platforms including tablet, focusing on making Docs actually work for mobile users rather than trying to load all the features from Web. It would mean providing Read and Collaboration experience first and somewhat reprioritising Editing.
My Role
I led design process from end-end.
Working closely with Product Manager to get analytics, surveys, and all the data for informed decision making process
Working with Engineers to define constraints as well as get early feedback to various elements of design
Pixel by pixel design QA of product as it was getting built out.
Tools
Figma
Amplitude
ClickUp
Maze
Team
Engineering Manager
Product Manager
Product Designer (me)
3-5 Engineers (varied depending on a phase)
Quality Assurance Engineer
My Design Process
Explore & Define
Ideate
Design
Build
Analyse & Reiterate
Main challenge: How to keep it both simple and complex?
During the ideation phase of the project with was rather continuous process than a short-period stage, we conducted user survey with a goal to understand, what were users looking to use mobile docs for the most. We didn't limit it to only ClickUp app and wanted to hear what aspects of doc and note apps user value the most. During customer calls we also figured out more of real world use cases. The main outcome was that users prioritised being able to Read and quickly take notes on the go rather than being able to perform complex actions.
In addition, users wanted to be able to collaborate. Like users using mobile docs to leave comments during calls, or answer comments on the docs while on the go without having to open Web version.
Given the defined core user needs, we also got a massive feedback on market stores of users lacking sophisticated features they had on desktop version. Which sounded like quite a dilemma and challenge, because in reality we'd have to provide both simplicity and complexity without compromising each of these.
The solution we'd come up with is integrating Progressive Disclosure approach, where we'd prioritise top user needs first but gave an easy way to dive deeper into complex functionality when users need them.
Basics
Main Scene Anatomy
The main scene of mobile docs was the page view.
Page view would be working area and also the entry point to secondary, deeper features such as setting page properties, leaving comments, conducting search, or adding content such as images, files, or various doc blocks.
It was important to make right decisions to make the most important features more signified than secondary, while still providing easy 1-click access to the secondary layers.
Content Blocks
Content blocks are important atoms of content structure, they are building blocks that allow to create a very custom formatted pages, that include tables, banners, lists, files, images, links, embedded websites or ClickUp elements such as other Docs, Views, Tasks. And so much more. You can see a sneak peek overview of possible options. Some blocks have quite unique treatment and UX such as images or tables.
Docs Navigation
Navigating around the ClickUp Doc allows to have a complex sub-pages structure to organise documents the way users want. In reality, ClickUp Docs are mostly used for business purposes to write technical documentations, project requirements, organise work and other countless sophisticated use cases. So yes, complexity is inevitable, and we needed to answer it with easy, snappy way to move through the Document as well as provide high-level navigation through user and organisation Docs.
Pages can have subpages. User might start from a subpage by opening a link and not having clarity of where she or he is located at the present state. To answer that, we designed a navigation modal that can be always accessed from the top.
We knew about bottom being more accessible, but in reality it might be often hidden by keyboard in edit state, so topbar appeared the most reliable and discoverable to access navigation.
Navigating through the page can be as easy as a scroll. However, there's a few hidden bottlenecks that might make the flow confusing.
1. Long pages would be hard to scroll through, especially without understanding how big they are. A solution here is to use assistive scroll pin, that would indicate the user read position area.
Scrolling back up from long pages might take as long as getting down, so to fix that we've added the scroll back up button
Top and bottom bars aren't really adding value for scroll through scanability, and in fact, take space. So on a scroll down, they would hide and allow to see more of content. Scroll up would get them back, it's a common pattern that makes a good job for saving space here.
On long pages that have page of contents, we would use scroll pin as a way to navigate through the page sections, with haptic feedback added on switch transition, giving a proper feedback for successful action.
Search
Placing search down was one of decisions to increase its discoverability and make it a part of being able to navigate through the document quickly.
Collaboration
Working on a Docs with comments
Collaboration is a part of ClickUp, in fact, it's the second most important aspect after task management, and tightly coupled with it. In docs, it means being able to communicate contextually about small areas of focus as well as globally, related to a whole page.
The most important aspect of commenting in Docs appears to be able to view context of a comment. So we designed split view, which addresses this mobile-specific challenge. With split view users can easily see the context of a comment, or easily switch between them.
And as an addition to driving user engagement, indicator of who's watching or editing the doc has been added, so work can be more fun.
Viewing comments
Previewing comments happens in two steps, depending on user needs. Simple comment overview can happen with help of a first click on a comment and seeing the thread. Next level, if user want to make a stop and work on a thread closer would be swiping up the split screen preview, to enter a full screen state.
Keeping the context
One of edge cases, yet the biggest source of opened comments would be inbox. User would open the update about a new comment on a Doc. And ... Wouldn't have easy access to the context of that update. How to fix that? Force user to jump between the doc and comment page? I decided to solve it by having a preview on a long-press, available anywhere. This would solve a problem of increased cognitive load on users, forcing them to find a context of a comment, allowing to instantly preview what was comment related to.
Editing Docs
Editing Docs is meant to provide simple basics, be discoverable and easy to access.
To understand what types of edit actions are more important over the others, we used a previously mentioned general survey that indicated that user prioritise the most simple actions like bold, italic, adding image.
Second part that we could get insight from is actual data on different types of blocks usage, from existing Docs all over ClickUp. We didn't reference existing Mobile Docs analytics as it was too rough to reference.
It was quite obvious, and confirmed our previous assumptions, that we should keep things simple. At the same time we could prioritise items by priority from list elements to banners, user mentions and others and be confident in hiding some elements from main flows, knowing that most of the users won't need them.
We had to keep in mind following: Editing can happen two ways:
1. No typing action. These are the least effort to make, so should be prioritised.
2. Manual editing & typing with keyboard present.
Next, I'm going to show you how these two got implemented, yet still keeping complex functionality required by cross-platform consistency.
Mobile Document-editing UX
Let's take a look at the general schema of editing menus navigation to understand the global picture.
First, user has access to no-keyboard bottom bar insert menu. That's where we put the most prioritised items within 1-2 clicks reach: Access recent options, insert a text block, image, list or mention someone.
Second, after user calls the keyboard - a layer of toolbar comes in. At the basic layer it solves the same goal of having instant access to one click actions, without typing. Such as add comment at the marker position, start bullet lists, undo-redo. That's it. Nothing else is needed for now.
Third level is when complexity is needed. It has rich editing sub-menu for most popular text formatting variants. And for the most sophisticated elements adding, there's insert menu, where user can search for an element that's needed or scroll through it.
Now, let's take a look at each scenario below.
First layer: No keyboard editing
First layer of no keyboard edit/insert menu. It's called by plus button in left corner of bottom bar and brings recently used elements, recommended options first and the provides a scroll through category types. Then, we make the most important actions such as adding a list, text type blocks or adding image by having them as tabs on the toolbar. And search is there to answer any instant sophisticated user request, to shortcut the complex navigation. Just type to add.
Keyboard based & toolbar editing
1. After a tap on a content, user can see keyboard opened, with a toolbar.
In this case we keep the most important actions as adding al list, mentioning, adding comment yet, having same insert menu accessible, as well as a click-away rich text editing.
2. After selecting a text, where rich text editing sub-menu would get activated right away.
Main reason is to allow to instantly perform simple b/i/u/s actions as well as allow to leave contextual comment quickly, by providing the pop-up menu near the selection.
Keyboard Toolbar & Menu states
Each action is a separate flow and has got its own picker or a menu when necessary. Not all the actions are one-click but where possible, we try to cut the flow as in the mentioning user: User can pick from recently picked users list or start typing to find a right person.
Blocks interactions
Working with blocks is always contextual. User can long press on a block to access the menu to edit it, or keep moving finger to reorder blocks. Most of blocks have their own menu groups, such as text edit block menus, table block menu, image blocks and so on.
Docs Tables
Docs TablesTables are important building blocks to store and organise information inside Docs. Mobile Doc tables provide slick and easy read experience, but also ready for editing when user needs it. We knew that realistically, they'd be mostly used for viewing or very simple text editing, so kept the cell editor limited to the basic rich text options only.
Tablet version
Tablet users is 4th largest ClickUp Mobile audience, so it was important to bring in the high quality tablet version, that would be more demanding to complex functionality and editing since some users are using their tablet devices as work stations with attached keyboards.
Amazing part of Tablet design is that it allows really fast navigation across ClickUp ecosystem.
Design System & Dark Theme
ClickUp Mobile uses a sophisticated design system, based on figma variables, that includes well thought-through color tokens system, that allows to convert light to dark mode designs seamlessly. I worked closely with Engineering over past few years to make sure we integrate proper design system approach and translate it well into the code. As a result, we built out infrastructure to import all the themes and styles directly from Figma design libraries in no time.
AI as part of Docs experience?
ClickUp had integrated AI models from earliest days, allowing various use cases across the features including Docs. In fact, ability to work with Docs content using AI was made perfectly for mobile user experience. For example, to write a summary about a huge, complex document to read it on the go, draft a project specification or a marketing text on the go wouldn't require hours of editing and formatting using mobile anymore. It's a perfect way to bridge gap between restrictive reality of Mobile apps world and rich possibilities of ClickUp ecosystem, including Docs. But important to mention, all the texts here were written manually :D
Thank you for reading!
It's been few years non-stop project, a part of ClickUp mobile product designs which I led from end to end. We've started with simple note-taking MVP and reached the point of being capable to deliver world-class quality mobile Docs software, which is just gaining traction. It's been a apart of other core redesign initiatives, in line with Task view, Home, Inbox and Core Navigation experiences.
I left some rather technical and organisational design nuances for the back stage, but let me know if that's something that might interest you too.
Please feel free to reach out with any questions.
