Tasks was originally built as a Hackathon project and consisted of a simple list UI that served the individual contributor use case decently well, but beyond that it started to break down.
I conducted user interviews with internal stakeholders, reviewed user feedback to understand the current pain points and worked closely with my product and engineering partners to begin mapping out solutions and roadmaps.
I also reviewed best-in-class task tools at the time to learn more about existing mental modals and interactions that would create a seamless, intuitive and fast interface.
After identifying the low hanging fruit all the way to the big bets such as project management features, I started design concepts on the first version of the redesign, which mostly focused on creating a new foundation of design and UI improvements that would make the tool easier to read and make core functionality such as editing tasks faster and with fewer clicks.
We launched the first redesign of the tool in 6 months with one engineer.
Over time, we iterated on the product to add more product management features that would allow managers to have better planning and oversight on work being done by multiple contributors allowing teams to operate more effectively.
Tasks became a powerful, fully featured tool by the time I left, allowing teams to organize work, create and edit tasks quickly and maintain better focus throughout the day.
Calendar
Another exciting project I worked on was Calendar. I collaborated with one engineer to create a completely new tool that streamlined meeting booking and attendance creating greater efficiency and less time wasted.
Originally rooms were scheduled using a separate tool, and calendar events were viewed and managed using Outlook. There was a lot of friction and inefficiency in the system and every booking error resulted in time wasted with people having their day interrupted for meetings that didn't have appropriate rooms booked or participants who hadn't responded causing people to have to quickly find new rooms or reschedule entirely. Designing a seamless and easy to use calendar tool that made booking accurate meetings across many locations was a clear opportunity for improvement.
I began my work on Calendar by assessing the current workflow and exploring the technical possibility with my engineering partner that we build one tool that pulled the meeting information from Outlook, presented your calendar and allowed you to book rooms as well as add your work status. This would essentially combine three tools into one. After brainstorming the technical challenges, we determined this would be doable if the work was planned out in stages.
As with any project, I also conducted user interviews to understand how people were using the current tools and what the pain points and opportunities for improvement were. I spoke with ICs, managers and admins who all had different use cases to consider.
After doing research, we established our first goal was to create a simple version that served most use cases and allowed you to book single meetings with accept and decline status. Much like Tasks, we started with designing the foundation of the UI in the most simple way possible, allowing for complexity to be added on top of it over time.
The most important and unique view to design in Calendar was the booking page. My goal was to create a view that would allow users to add invitees and have the date/time and room options update to accommodate them while displaying availability in a visually clean way. In most cases, once the invitees were added, the tool would automatically select the best time and room/s for all attendees based on their work status. This page created a much faster booking process and improved the booking experiences for most uses cases pretty quickly.
The UI also scaled to make it much faster and easier to book large meetings with teams spread out across different locations and timezones. This helped in preventing people from scheduling meetings outside timezones. We eventually added Work Hours as a setting as well.
Another important and common but complex use case was recurring meetings. It was clear from my initial interviews that recurring meetings were very important and commonly scheduled, however they were more challenging to implement, so we waited until after our first release to tackle them. With recurring meetings, the primary issue was that a single room would be booked for an entire series but sometimes that room wouldn't be available for one or more instances, having been previously booked. So our solution was to automatically check each instance and add a different room as a back up. This made recurring meetings much more reliable with fewer errors to manage.
After building the desktop version, we focused on mobile, bringing the same ease of booking to the palm of your hand, with the added use case of navigating your way around campus. This made booking meetings on the fly and going from meeting to meeting much faster, saving time that all accumulates in greater productivity.
and more...
In addition to Tasks and Calendar I also redesigned the Wiki, Intern Search, Profiles, Mobile Home, Diffs (our code review tool), Learn (an internal class and learnings tool) and created concepts for Teams and Projects.
Eventually I hired two contract designers and helped with hiring a design manager to grow the team and connect it to the core product organization.
For each of these projects, I partnered with one and sometimes two engineers to complete everything from initial research, roadmapping and feature requirements, project planning, design, hand-off, implementation and gathering feedback.
I worked with a Product Manager for the first 6 months who helped me get the lay of the land and understand the scope of projects we could tackle, and after he moved on from the team I took over product and design.
Each project required an ability to rapidly ramp up on very different problems and create solutions quickly to never be blocking engineers. I dove into design challenges some of which were completely foreign to me, such as the Diffs tool which is what engineers used to review and ship code across the company. No matter what the design problem, I was always able to tackle it through a process of asking as many questions as necessary, communicating thoroughly and regularly and ensuring shared understanding.
