Case Study: Tasks
The following details the process and principles I employed to define and build one of the internal tools I worked on at Facebook. Every project is different, and the process can and does vary based on the needs and goals of the client, team or company. I make every effort to thoughtfully respond to the different needs and tailor my approach, always keeping in mind that process is not an end in an of itself. I like to stay lean and gear toward testing something finished, even if it's not perfect.
Tasks was the first project I worked on at Facebook, and what I was initially hired for. When I joined, it was a tool mostly used by engineers and IT to track bugs and open help tickets.
The two engineers working on it had received a lot of feedback from employees but weren't really sure how to interpret the feedback and improve the UI. In addition, there was no PM or design manager on the team, so it was our responsibility to establish goals and product vision in the beginning.
- Save people (and the company) time
- Improve collaboration and communication
- Make Tasks useful for everyone, not just engineers
- Make it delightful/easy to use
In order to really understand how people were using the tool, I set up about a dozen user interviews with people throughout the company who were active users. I ran through a script of questions about their use case, and showed them a rough prototype of an initial design mock to quickly get feedback.
Some of the key findings that helped shape the initial product decisions were:
- The desire to create many tasks in quick succession
- The ability to edit tasks quickly
- The desire for better readability/hierarchy
- Better task organization/management
- More ways to collaborate/be productive
- Make it more geared toward design/engineering collaboration
- More visual thumbnails for attachments
Working closely with the engineers, I created initial mocks that formed the foundation of the first redesign. Using our FIG (Facebook Interface Guidelines) as much as possible, I applied our design language to make it feel familiar and intuitive. After multiple rounds of revision and feedback amongst the team, we built our first version and started testing it with employees.
Iteration happened on almost every element of the UI, but some recurring themes that I explored extensively were:
Creating a task used to be done with a button in the upper left, but that seemed too detached from the task list and didn't allow people to create tasks quickly. We had some technical limitations with doing inline editing initially, so I devised a design for a new task field at the top of the table that allowed for continual task creation.
Closing a task
I wanted this to be intuitive, but I also wanted it to be clean. I tried multiple versions with a check box, but too many people were confused by it, so I changed to a toggle. I would have liked to remove the Save button and make all changes auto-save, but a technical limitation prevented that.
Our initial design didn't focus on search, but after releasing V1, we decided to prioritize redesigning how searching works. This required completely rethinking the UI to include a large search bar. We went back to the New Task button, and built inline editing so people could continuously create new tasks.
Instead of having to click an edit button, I designed a simple hover and click method to adding content to the task.
Exploration concepts in Sketch
The overall design solutions and principles we derived were:
- Make the UI feel clean and simple to focus on content
- Create informational hierarchy using type, color and contextual grouping
- Make it feel familiar, using as many existing UI components as possible
- Make sure changes provide significant ROI, otherwise bias toward what is familiar if it's not totally broken
- Design better ways to organize tasks and focus on primary use cases such as personal, collaboration and triage
- Provide more value at scale by focusing on project management solutions for teams
Current product and design exploration
Results were admittedly hard to measure with data on this project. Because we were initially focused on getting the tool to a baseline state, we weren't super focused on hitting specific numbers, and we didn't have a resource for data science or research. For feedback we relied heavily on our user feedback group, which was a pretty good barometer for noticing macro trends. This of course is not the most quantitative way to understand usage, but the qualitative learning was enough to get us going until we grew the product team to encompass more roles. Overall, our feedback was extremely positive, and eventually resulted in:
- More engineering teams wanting designers to help them, and appreciating the benefit of design
- Teams started looking to Tasks as an example for designing tools and dashboards internally and borrowing from it
- More teams reported using Tasks for collaboration cross-fucntionally, and liking it
- My team got more head count for designers and PMs and we created a reporting structure into to the core Product Design org