Case study · Enterprise product design
AWS teams tracked work in 3 or 4 different tools, so I designed one that 500 people chose to use every day.
Task-it is an internal task management platform that consolidated fragmented tracking tools into one system with role-agnostic patterns.
- Role
- Senior UX designer and lead designer, Amazon Web Services
- Timeline
- 2021 to 2023
- Worked with
- 3 product managers, 8 engineers, and a UX researcher
- Status
- Launched, with patterns adopted in other AWS internal tools
- 500Daily active users across 15+ AWS teams within 18 months of launch
- 3 to 4 → 1Separate tracking systems consolidated into one platform
- OrganicGrowth came from word of mouth, not mandates from leadership
Some details are omitted for confidentiality.
Step 1 · Context
Work lived in Jira, internal systems, and spreadsheets, and nobody could see across teams.
AWS teams used 3 or 4 different task tracking tools. That meant fragmented workflows, poor cross-team visibility, and real time lost to context-switching. Product managers struggled to get a unified view of work across teams, and individual contributors were frustrated by updating multiple systems.
OpportunityHow might one system serve product managers tracking roadmaps, engineers managing technical debt, and support teams triaging customer issues?
Step 2 · Research
Users would not accept a more complicated process, so research came before any wireframe.
User interviews
Their role, the products they use to manage work, and why some avoided the existing internal product.
Competitive analysis
What else teams used internally, and what it offered that the internal system did not.
Hands-on testing
I worked inside the system we were replacing to find its issues, then compared them against the interviews.
Observation
Where users always go, and which tasks they perform every day.
Anything more complicated than what they had would be a deal-breaker, no matter the directives from management.
Who it was for
The beta targeted individual contributors, with a mix of high-interaction and low-interaction users in three groups. After discussions with product management, we split them into two tiers.
Actively added items to a team’s task queue. Tier 1: they used existing tools many times a day and could drive adoption.
Responsible for delivery and success of daily and long-term goals. Not ICs, but they shaped which tasks teams took on.
Stayed outside day-to-day operations but influenced the work. Tier 2: weekly check-ins, and a likely blocker to adoption if things got harder to find.
Step 3 · Key decisions
Every step in every flow had two goals: follow what users expect, and make the process simpler.
Users expected to create work items, view them, and organize their work in one system. Anything beyond that had to earn its place. I used user flows and states to find where success and failure paths could break the experience before any mockup existed.
Let users set the priority
More attributes were planned, so the Task Details page had to adapt. I ran a card-sorting survey that included existing and future attributes, with one prompt: which attributes are required for you to get your work done most efficiently? Users set the order, not the team.
Step 4 · Final design
Wireframes, then mockups, then three revisions driven by what users ranked.
I start wireframes from existing components, add redacted-script placeholder text and basic headings, and review with product management, development, and fellow designers. Mockups give the full look and feel for user testing and final development review.
After the card sort, I revised the page to match the updated attribute priorities.
Step 5 · Impact
From 50 pilot users to 500 daily active users in 18 months, mostly by word of mouth.
- 500Daily active users across 15+ AWS teams within 18 months of launch.
- 3 to 4 → 1Legacy tools consolidated, reducing tool sprawl and maintenance overhead.
- AdoptedDesign patterns now used in other AWS internal applications.
Adoption
Pilot teams in Q2 2022, general availability by Q4 2022, and growth across product, engineering, and support organizations.
User feedback
Post-launch usability testing showed high satisfaction. “Finally, one place to see all my work.” “Task-it adapts to how I work, not the other way around.”
Business impact
Better visibility into status, blockers, and dependencies, and a shorter onboarding path with one tool to learn instead of several.
Step 6 · What I learned
Give internal tools the same rigor as customer-facing products, stay flexible, and keep researching.
Internal tools deserve design rigor
Research, prototyping, and testing built a tool people wanted to use, with adoption driven by users and not by mandate.
Flexibility beats rigid workflows
Role-agnostic patterns that adapted to different team structures were the key to broad adoption.
Continuous research is essential
Regular usability tests caught issues early and kept us building what users needed, not what we assumed.