Redesigning a task management experience

Jul. 2024

I led the redesign of LeadSimple’s task management experience; one of the most used areas of the product.

The goal was to reduce the interactions required to use this critical feature-set so new users could more easily adopt it after sign-up. We had 2 weeks to build and ship the changes.

We’ll walk through the full design process, outlining all the specific design decisions we made and why, and how users reacted to the changes.

My Role

I lead design for this project, with some assistance from a fellow designer on the team. I was responsible for:

Auditing our existing task management experience & user feedback about tasks
Identifying what needed to be improved
Defining the product requirements
Leading all the UX and UI design
The Problem & The Goal

LeadSimple is a large product that took a while for customers to set up. 

Goal: We wanted to create value for new users faster using our task management features. This would get them accustomed to doing their work from LeadSimple, instead of other task management systems they previously used.

Problem: Our task management experience required a lot of unnecessary interactions and wasn’t optimized for speed. It was also missing some valuable features that you can find in most task management apps out there.

We needed to optimize task management for speed-to-use and make it more useful so users could get value quickly.

Resources: We had one engineer on the project, and had to ship the changes in a 2 week timeframe.

Discovery

Discovery

Discovery

We were working with user feedback from numerous interviews we had done recently. We already knew of many things customers wanted us to change about tasks. This allowed us to get to solution design quickly.

UX Audit

We began by auditing the user experience of our existing task management features. We were looking for obvious ways to improve it.

Less important info stood out too much, obscured important info/actions.

Click targets weren't intuitive. Less important actions had larger click targets than the most commonly used ones.

Editing and creating tasks took users out of flow by opening a dialog, and it was difficult to find the setting you wanted to change.

The screen looked very cluttered. New users were easily overwhelmed by it.

  • It was a wall of mostly undifferentiated text and boxes - not organized in a way that allowed users to process information intuitively

  • Color usage was distracting, and inconsistent with the rest of the product

  • It displayed a ton of repetitive information

    • View process

    • Show instructions

    • Avatars even when you were looking at your own task

    • Delete button

Users confused the "complete" checkbox on tasks with a “select” action, since we used a checkbox for "select" elsewhere.

Some tasks let users take a special action—an email task let you click to compose an email directly from the task. But many users struggled to find it (it didn't look consistent with other buttons in the app) or were weren't sure what it would do when clicked.

Opportunity to Increase Value
Opportunity to Increase Value

Beyond these user experience issues, our task features weren’t as useful as other products. Users couldn’t easily organize or prioritize their tasks by the things they cared about, which made this area of the app less attractive to use.

Users had told us many times that in an ideal world they could group and filter their tasks by:

  • Customer type

  • Rental property (our product served property managers)

  • Process or type of work 

  • Priority

If users were going to switch to use our system, it needed to at least be comparable to what they were currently using.

Defining Product Requirements
Defining Product Requirements

"We limited scope to UX improvements that increased speed and reduced overwhelm."

To get users to switch, we knew we needed to make the tasks experience faster and less overwhelming at a minimum. We had to do this without disrupting existing users too much either.

We didn't have enough time to add many new features.

As a result, we limited scope to UX improvements that increased speed and reduced overwhelm, and saved the new features for later.

Shipping some meaningful improvements quickly was the main priority, even if there was more that could be done.

Solution Design

Solution Design

Solution Design

Finding Inspiration
Finding Inspiration

Before brainstorming ideas of our own, I wanted to understand how the best task and project management apps were designed. 

This step almost always helps me come up with solution ideas, or combinations of ideas, faster and ensures my design follows conventions users are more likely to be familiar with.

We compiled screenshots of all the key task flows from Todoist, Monday.com, Linear, Trello and others.

More often than not, you don’t have to reinvent the wheel. Someone has probably solved the same problem before. They can help you generate more solution ideas and keep it in line with modern conventions too.

Auditing Todoist's Design

Todoist was my main source of inspiration because of how clean and simple they kept the experience, yet without hiding useful information. 

Since tasks were one of the most used features of LeadSimple, we didn’t want to disrupt users too much by hiding information they found useful behind a click or hover state, but we also needed to create an organized and comfortable experience.

Clean & Simple Feel

Todoist had a very simple and clean experience. They achieved this with a few tactics.

Minimal use of color. It's only used for the elements that need to stand out from the rest (due date, priority, etc.).

No redundant information. All task actions–like delete–are hidden behind “hover”. The user only sees it if they need to see it

Centering the list of tasks with generous whitespace around it. This creates a crowded feel and narrows the width the user has to look at

Task Creation

The pop-up animation and large task name font feel friendly and snappy

The lack of backdrop color keeps the user in flow - sometimes dialogs with dark backgrounds can be jarring, and take you out of the experience

Pills are a very efficient use of horizontal space.

  • It’s easy to scan the pills for the setting you want to edit

  • When filled, the value replaces the label, which saves space

The user could easily tab between the name, description, and other settings.

You could also hit "enter" to save without leaving the keyboard (this is pretty standard, but it wasn't used in most dialogs in LeadSimple).

The user could customize task settings in the task name, using plain language!

This was probably out of scope for out 2-week project, but it could save users a ton of clicks when creating tasks.

Editing Tasks

The edit button wasn't visible unless you hover - it isn't the primary action.

The edit view was familiar. It gave the user almost the same experience as creating a task.

Plus, it might be faster to build if we used the same component for editing and creating.

Viewing Tasks

Clicking a task in Todoist opened a large dialog.

This gives the user plenty of space to complete the task, and leaves real estate for useful features like comments and team collaboration.

LeadSimple’s tasks could have long descriptions—we called them “instructions”.

A dialog was one way we could potentially display it.

Check Circle Instead of Checkbox

Todoist used a circular checkbox (I know you can’t have a circle box, but bear with me 😉). 

This might remove the confusion our users had where they expected our square checkbox to act like select-all, not “complete”.

Handling Long Task Lists

Todoist grouped tasks in collapsible sections. We could do a variation of this to let users see what they want to see without being overwhelmed, and prevent tasks from cascading infinitely down the screen.

Choosing What We Should Improve
Choosing What We Should Improve

We didn’t have enough time to completely overhaul the design of tasks. I had to be judicious.

Based on our audit of LeadSimple and Todoist, we thought these things would make the most impact to the user experience:

  • Heavily reduce or clean up the information on the task list - reduce overwhelm

  • Create a new in-line task creation and editing experience

  • Combine the “edit”, “view”, and “create” modes of tasks to reduce click targets and speed up development

Mockups

Mockups

Mockups

We jumped straight into high-fidelity mockups at this point, because more detail would make it easier to unveil anything that would be hard for the engineer to build. Plus, we already had existing components to use for tasks, so it wouldn’t slow us down much to work in higher fidelity.

Cleaning Up LeadSimple's Task List
Cleaning Up LeadSimple's Task List

There was a lot of information we could simply remove or hide:

“View Process” - we already displayed the name of the process on the task, so we could eliminate this button and link the process name instead to save space

Delete button - this could be displayed on hover without sacrificing usability on desktop. Task deletion was less common on mobile so we could display it in “view” mode there, behind an extra click

Delete button - this could be displayed on hover without sacrificing usability on desktop. Task deletion was less common on mobile so we could display it in “view” mode there, behind an extra click

“Show instructions” - it wasn’t a primary action, and the green color was part of a legacy theme, we could change the color to something less “loud”

Tasks with email and text templates attached created a lot of visual noise, and we could reduce this significantly by lightening the background color and reducing the surface area - users could still tell there was a template attached, but it wouldn’t “scream” at you anymore

The task type icon didn’t need to stand out so much - we could reduce its impact by using a gray color from our theme instead

The avatar only needed to be visible when the user was viewing someone else’s task list - otherwise, we could hide it when they were viewing their own tasks

The task action button (for communication tasks) didn’t look like a button and was visually “loud” - we could calm it down and make it look consistent with other buttons in the app by adding a border, removing the background and giving it a squared-off shape.

Centering the tasks on the screen, with left and right padding, would allow users to see more of tasks without moving their eyes from left to right, especially on larger screens

On small screens, we could allow tasks to expand to more or all of the screen width to make the most of the limited space.

Process names could be quite long - we could truncate them at a certain length to keep things clean

For tasks that were not associated with a process, we could use the process name space to locate attachments, priority (a new feature we wanted to add) and recurrence settings

Pagination of the list

The “overdue” task list could become very long if users didn’t build their processes well (processes were the primary source of Tasks in LeadSimple)

This overwhelmed some new users.

To reduce some of this overwhelm, we could paginate the task list to show fewer tasks in each group, and let users click ”show more” to expand a group. 

This would keep the “overdue” group short, but also ensure they saw the tasks that were due today.

Click Targets

We needed click targets for:

  • Completing a task

  • Viewing the associated process

  • Taking action (only for communication tasks)

  • Editing the task

  • Viewing the task

We could reprioritize the click targets based on which actions were primary:

  • Combine click targets for viewing & editing, and give those actions the largest click target (we would be combining those “views” anyways)

  • Give the associated process the next click target

Taking action on communication tasks - this action was already combined with the task type icon (on relevant tasks), so we decided to leave it there, but tweak the visual design of that button slightly (see above).

Task Creation, Edit, and View Modes
Task Creation, Edit, and View Modes

The engineer had told us it would save a lot of development time if we combined create, edit, and view modes. That way, he could reuse one React component.

This is the approach I took. 

Beyond saving development time, this would:

  • Keep users in flow by eliminating the dialog

  • Let users add tasks faster, without leaving their keyboard, using tab

  • Make the task settings more scannable

  • Feel familiar compared to other task management tools

Inline-Add & Edit

I also wanted to allow users to edit tasks inline so they didn’t have an extra click to edit the tasks. This would hopefully speed up their workflow a bit.

Ultimately, we didn’t have enough development time to make the task name and instructions fully inline-editable as intended. I compromised and ensured that the due date, assignee, priority, and other fields on tasks were editable inline though.

Customizing Task Settings

I had to decide how to order the other task settings, based on the priority of the user. 

I emailed some users who had given us feedback on tasks to see what they thought, and referenced Todoist’s approach. 

User’s feedback and Todoist’s approach led me to prioritize the settings like so:

  1. Due date/time - besides the task name and description, it’s probably the most customized setting on a task

  2. Repeat - this was a heavily used setting for one-off tasks, since many users used those for recurring todos

  3. Assignment - users often created tasks to delegate to another user

  4. Priority - this was a new feature, and we weren’t sure how frequently it would be used compared to other task settings, so I put it toward the end

  5. Task Type - it was rarely customized for one-off tasks so it was also put at the end

  6. Reminder - at this time, LeadSimple only offered email reminders, which many users didn’t find useful. I put this last in the lineup

"Repeat" Setting

The “repeat” setting needed to have several features. A dialog would be the easiest way to support these, but I thought that would take users out of flow too much. 

Instead, I came up with a sort of “inline dialog” with a confirmation button, and the option to clear it. 

I used “done” for the confirmation button label here instead of “save” to avoid confusion with saving the entire task.

Priority Setting & Accessibility

The priority setting was begging for a visual indicator to help the user differentiate high priority from low priority. 

I mostly followed Todoist’s approach here. 

Priority labels would be:

  • Priority 1

  • Priority 2

  • Priority 3

I expected that to be universally intuitive.

We would have a matching color for each. 

For accessibility though, I couldn’t only rely on color to differentiate priority in the task list. To address this, I abbreviated each priority to P1, P2, and P3, with a “flag” icon next to it. This would allow color-blind users to differentiate priority.

Other UX Tweaks

Centering the “Create Task” Button

The “Create Task” button was in the top-right corner, which was harder to find on larger screens. 

We created a section above the task list for that action and the new sort feature we were intending to add. And we changed the label from “create task” to “add task” to sound less formal.

I added a horizontal rule below it to differentiate from the list below.

Tooltips for Task Actions

Some users were afraid to click the task action button because they didn’t know what it would do. I added a tooltip over those buttons to make it more obvious what they would do when clicked.

Displaying Long Lists of Attachments

When users added one-off tasks–not associated to any process–they could upload attachments to those tasks. The attachment list could be long, so we had to find a way to display them in a clean way.

My solution was to:

  • Display attachments as pills

  • Truncate the attachment name after it reached more than 11 characters

  • Convert the “Add Attachment” button to an icon button when an attachment was added; this saved space

  • If the list was long enough, we would display a pill with the number of additional attachments as the label. When clicked, a menu would open where users could click to view or remove attachments.

  • The “Add Task” or “Save” button would be pushed down when attachments expanded beyond it, to prevent overlap, and maximize the horizontal space for attachments

Mobile

Every decision I made above was considered the mobile experience as well. 

Mobile presented several challenges. 

Space Constraints

Of course, we had less space to display information and needed to make strategic decisions about what to show or hide based on the user's needs.

The task title took up the most space, but it was also the most important piece of information on mobile. Users needed to be able to read it without tapping, so I decided to allow it to expand up to 3 lines. Todoist also took this approach.

I truncated the associated process name to fit mobile screen widths, and we removed the extra left-right padding so that tasks expanded the full width.

We also hid the “delete” action within the edit/view mode of tasks since it wasn’t a primary action on mobile.

Usability of “View” Mode on Mobile

When users expanded a task, I displayed the delete icon button again, along with a couple other actions. 

The process name would become clickable at this point so users could still access the process from here, but still without creating conflicting click targets.

To avoid weird double scrolling behavior, I opted to make the expanded task view hug its contents, rather than give it a max height and “overflow: scroll”. 

The other task settings would be horizontally scrollable to save space.

If we had more than 2 weeks to build these changes, I would have used a full-screen dialog for the expanded “view” mode on mobile.

This would give us more screen real estate to display the information more cleanly, and remove distractions so the user could focus on one task at a time.

After gut checking the feasibility of my designs with the engineer, we agreed this would definitely fill the 2 weeks that we had. 

At this point, we moved to development.

The End Result

The End Result

The End Result

Before
After

Creating a Task

Empty state when there are no tasks

"View More" to expand the Overdue section

Viewing and editing a task

The Launch & Customer Response
The Launch & Customer Response

We launched the changes to a private beta for 2 weeks before the public launch.

We had our internal support team and several customers using it to find bugs and UX issues. 

I had several calls with teammates and customers to review issues they were experiencing. 


Public Launch
Customers initially gave mixed feedback after the public launch. However, the overarching pattern was that they were frustrated that we changed things on them without much warning. 

Our marketing team had sent some in-app and email messages to customers in advance of the changes, but we could have given more of a “heads up” to avoid disrupting users. 

After a week or so, the bulk of user’s feedback was very positive about the changes, which confirmed to me that the updates hit the mark, just like we thought they would.

What I Learned

This project was a great example of working with my intuition, existing knowledge of users needs, and UX best practices to make a meaningful impact on the user experience, very quickly.

Since I already had so much prior knowledge of the user’s challenges with tasks, we were able to move a lot faster than otherwise, and save the full 2 weeks for development.

We could have given users more of a “heads up” prior to releasing the changes, or even let them opt into the change for a period of time. This was an oversight, especially since Tasks was one of the highest used screens in the product.

After some time, users did grow accustomed to it, so we were definitely on the right track.

I had to step away from this project before we officially released it.

But at the end of October the team launched it to beta before the project deadline and received glowing responses from beta testers.


This was version one. We expected this would help customers rely on our product for customer support use cases, but it didn’t solve all the challenges they had with our native support product. 


How would we improve our "native" product to make it easier to adopt? Will users pay the same amount of money for this as our “native” product? Could the extension solve mobile use cases?


I believe we were on the right track, but there was certainly more work to do.