Task-It!

Role

Lead Designer

Areas

User research, Wireframes, User journeys, Mockups, Prototyping

Problem

After more than a decade of minimal updates, multiple subscription services, and independent teams, it became apparent that a single, scalable solution was needed. This project was to replace the existing systems, eliminating costs and overhead.

Challenge

With multiple systems container millions of tasks (both current and historical) as well as a growing need for various integrations, it was apparent that the user base would be the biggest challenge. Creating something that could not only handle all of the various methods of work, but also the vast historical nature of teams, presented a very unique situation. Additionally, the product had to be one that all users could utilize, no matter their working method. This included, but was not limited to, users with accessibility needs, users who preferred "terminal" or "keyboard" commands, and those who relied on standard keyboard-mouse usage.

Constraints

The biggest constraint was that of time. As each day passed, users were onboarded to either the older solution or to products that required licenses and cost the company money. The team was given one year to put together an initial release to be announced at an upcoming conference.

---

The Process

Before any design work (wireframes, mockups, prototypes) could begin, extensive user research and testing was needed.

Research methods with example questions:

• User interviews
  • Ask users what their role is on their product team.
  • What product(s) do they use to manage their work?
  • If they do not use the existing internal product, why not?
• Competitive analysis
  • What products are used internally, besides the previous internal-built system?
  • Why are they used? What do they provide that the current internal system does not?
• On-hand testing
  • As a user, I needed to work within the system we were working to replace so that I can find the issues that currently exist.
  • Findings were compared against user interviews. Those interviews were also used as a basis for various testing methods.
• Observe users
  • Watch how users use the products: where do they always visit? What tasks are they always performing?

Once a baseline had been established, the first round of user flow diagrams and analysis took place. Each step in the various user flows had two goals:

1. Follow user expectations
   • Users expected to be able to perform basic tasks, such as creating work items, viewing work items, and organizing their work in a single system.
2. Simplify existing processes
   • Users would not accept a more complicated process. Interviews taught me that anything more complicated than what they had would be a deal-breaker for switching to, no matter the directives from management.

Target Audience

For the initial release (scoped internally as a "beta"), the target audience consisted of Individual Contributors (IC), with a mix of high-interaction and low-interaction users. These were categorized as "Contributors", "Owners", and "Viewers".

• Contributor
  • Those who actively added items to a team's task queue.
• Owner
  • Individuals who were, at a high-level, responsible for the delivery and success daily and long-term tasks and goals. While not ICs, Owners had a direct hand in what tasks teams took on.
• Viewer
  • Those who stayed on the "outside" of the day-to-day operations, but could influence the work taking place. Viewers were not considered to be a top-level user, but the entire process had to take into account their work. If things became harder for them to see/find, then they were likely to become a blocker to adoption.

After discussions with Project Management (PM), it was determined that the target audience would be broken down into tiers: Tier 1 and Tier 2.

• Tier 1 consisted of those who used the existing solutions multiple times per day and could assist with driving adoption. These were the Contributors.
• Tier 2 consisted of those who interactive with existing solutions on a weekly basis, and then only to monitor the work being done by those in Tier 1.

User flows, Wireframes, and Mockups

For the initial Task Details view, user flows and wireframes were used to identify possible errors. The findings from this work would go on to determine the direction of the final mockups.

Initial findings

Based off of these user flows, I determined that the success and failures paths needed to be looked at further. Depending on the user, these paths had the potential to break experiences and decrease the usability and delight in the product.

Testing and Revisions

As part of the iterative process, I consistently looked at user feedback and heat-mapping to determine if there were any changes needed. From the beginning, it was known that additional attributes would be made available to users and that the Task Details page would have to be able to adapt accordingly.

As part of the testing process, I created a card-sorting survey for users, where I included all of the existing attributes, as well as some future-planned attributes, and asked users to order them by priority. Priority was determined by the user, with the only prompt being "what attribute(s) are required for you to get your work done in the most efficient manner?".

Revisions

After analyzing the results of the card-sorting user testing, additional mockups were created to task with the updated attribute priorities.

---