Database Design — Cross-Team Workflow
Building a tracking system for accessibility work that spanned legal, licensing, and platform teams, replacing a spreadsheet and email setup that couldn't show shared status.
Making a piece of content accessible wasn't one task. It was three, running in parallel, owned by three different teams: legal documentation, licensing and permissions clearance, and the platform work to actually implement the accessible format. Each had its own pace. None of them could see what the other two were doing.
This case study covers the database I built to fix that — and the decision to route it through the same accessibility review it was designed to track.
Status lived in a spreadsheet, plus whatever email threads the spreadsheet couldn't capture. A spreadsheet can hold a status. It can't link that status to two other teams' parallel work on the same item, or flag when one track is blocking another.
No one could see another team's progress without asking directly. That produced two failure modes, both common: teams duplicated effort on items because they didn't know work was already underway, and other items stalled because no one knew whose turn it was to act next.
Every task — across all three tracks — moved through the same stages:
The problem was never a missing spreadsheet column. It was that three teams were doing interdependent work with no shared view of each other's progress. A spreadsheet can record what one team is doing. It can't represent how three teams' work on the same item relates, or let someone regroup that same data by a different axis depending on what they need that day.
The fix needed relationships between records, and views flexible enough for people to organize their own work inside them. That's a different requirement than "a better spreadsheet" — it's the actual case for a relational database over a sheet, not a preference for newer tools.