Turning internal workflows into usable data products

The situation

Grant management and survey management looked like separate projects, but both depended on a chain of intake, review, status changes, follow-up, and reporting. Much of that structure lived in spreadsheets, messages, and individual memory.

The design question

How could internal tools make the next action obvious while still respecting the differences between programs, reviewers, and reporting needs?

My contribution

I mapped the workflows, information models, decision points, and user responsibilities. This revealed which patterns could become reusable product capabilities and which needed to remain specific to the work.

The system

The resulting product direction organized information around applications or responses, review states, ownership, exceptions, and outcomes. Instead of reproducing a spreadsheet on a screen, the design made the workflow itself visible.

Outcome and lesson

Teams gained a clearer way to coordinate work and understand progress. The broader lesson was that internal software is still a product: its users need clarity, feedback, and a design that reflects how decisions actually happen.