A review's status is what the accessibility program runs on. It tells a planner where a review is in the process, a reviewer whether a flow is ready to work on, and a product team when a review is complete and ready to act on. Requirements for review statuses had sat undefined for months, because every proposed model broke on edge cases in the review process that the team kept surfacing.

I ran working sessions with engineering and the program team to zoom out and map every stage a review could move through, rather than debating statuses as hypotheticals. Once we had a full picture of the review's journey, we could choose statuses based on the state of the review data and how actionable that data was for whoever needed to act on it next.

I designed six states across a planning phase and an execution phase. Review planners move a review from Draft plan to Plan ready, then specialists take it from To do to In progress to Done, with Blocked when work was held up. To reduce the status maintenance burden, I tied transitions to actions in the product, so assigning a review team advanced it automatically from Plan ready to To do.

With hundreds of reviews running at once, review teams needed status to lead the information architecture rather than sit as one more column in a table. Status then appeared only wherever it added clarity, most visibly on the home page, where reviews were grouped into tables by state so a reviewer could jump straight to the ones they needed, and it dropped out of single-status tables entirely.

Months of debate resolved in days, which unblocked engineering to build against a stable, team-defined model. More than that, the status model became the mental model users navigated by, so a planner thinking "show me everything in progress" could act on that thought directly. It made the review process faster to move through and lighter in cognitive load.

The scorecard had to answer two very different questions from the same data. A VP needed the current state and direction of an entire app, so they could report where accessibility stood and where it still had to get to. A product team needed to know which of their specific flows were failing and what to fix. One audience was scanning for direction, the other for a to-do list, and both had to find what they needed in the same tool.

I mapped the accessibility data onto the way the company was already organized, as a hierarchy running from the whole company down through app, product area, product, and feature, to the individual flows a review produced. The owner of each level asked a slightly different question, but underneath it was always the same one. Where does our accessibility stand now, how does that compare to where it has been, and what do we need to do to reach our goals? So I designed one view that answered that question at every level.

I designed one page to work at every level, from the whole company down to a single feature. I built it from three parts, a pie chart showing how the current level scores today, a history chart showing how it has moved over time, and a breakdown table showing what sits inside it, down to individual flows at the lowest level. That let leadership use the pie and history to see which parts of the organization needed to improve, while product teams used the table to act on their own flows. Because this was a tool for measuring accessibility, I designed it to meet WCAG requirements itself, so that anyone at Meta could use it.

One tool served every level of the company at once, from a VP tracking a whole app to the team fixing a single flow. More than that, it became the main tool the company used to steer toward its accessibility goal ahead of the European Accessibility Act. Leadership used it to see which parts of the organization were on track and which were falling behind, and product teams used it to plan and prioritize the work to get it done on time. It was the shared instrument that turned a company-wide regulatory deadline into specific, trackable next steps for the teams who had to meet it.

The original task design named an owner, but that owner was only a snapshot of who was actually needed in an accessibility fix. Tasks often need a product designer, a content designer, and an engineer working together. Sometimes a team could not fix a task at all, because the real cause lived in a framework, a design system, or another product entirely. The task tool captured none of that, naming one owner and leaving the rest undocumented.

Before designing anything, I sat down with the cross-functional team to model the data underneath the tool, because the plugin was only as good as its understanding of how tasks actually got resolved. We worked through which issue types required which roles, and documented the dependencies that came up again and again across the team's existing accessibility work. That let me design the plugin around what was really happening rather than around the task record as it already existed.

I designed the plugin to live inside the task itself, adding two things the task tool did not have. The first was a contributor section that captured every role a fix required, a product designer, a content designer, an engineer, each marked recommended or not needed. I designed the logic that set those roles automatically from the issue type, so a color-contrast issue arrived with a product designer recommended, and teams could adjust from there, with every contributor staying on record after the task closed. The second was a dependency system, so when the real cause belonged to a design system, a framework team, or another product, a team could hand the task to whoever could resolve it and it stopped counting against their score.

The plugin appeared on every task the program generated. Automatic role assignment put the right people on a task from the start, and the dependency system let teams hand off what was not theirs, so tasks moved forward instead of going stale in a backlog. What had been a heavy, manual lift for program managers became something teams could resolve on their own, and tasks closed faster as a result.