Sometimes You Have to Boil the OCEAN

Modernizing how Ohio delivers funding across 18+ programs, from citizen-facing applications to the internal systems and processes behind them.

Duration

2022–2026

Client

Ohio Department of Development

Services

Business analysis

Systems design

UI/UX

At the center of financial aid operations at the Ohio Department of Development was OCEAN, an aging system that had accumulated over a decade of undocumented processes, dirty data, and technical dependencies.

Replacing it meant rethinking the entire lifecycle of an application, from intake and evaluation through approval, payment, and reporting. Each program operated differently, with its own eligibility rules, approval paths, funding structures, and connections to outside organizations.

But OCEAN was only half the challenge. More than 18 programs needed to be brought online, replacing outdated paper processes with digital applications and intuitive portals where Ohioans could apply, edit submissions, and track their application status.

What looked like a single Salesforce implementation was actually a network of people, processes, platforms, and data.

No application traveled in a straight line. Each program relied on a different combination of internal teams, external organizations, data sources, and systems to move an application from submission to payment.

But across that complexity, the ecosystem could be understood through four dimensions:

People: Clients, subgrantees, DoD staff, agency staff, and external organizations
Processes: Application intake, evaluation, approval, fund disbursement, and reporting
Platforms: Salesforce Public Sector Solutions, legacy Salesforce, OCEAN, the OCEAN database, MuleSoft, and utility SFTPs
Data: Historical records, new application data, federal and state aid financials, and external spreadsheets

My role rarely stayed inside a job description.

Over nearly five years, I became a utility player for the project, stepping into gaps wherever they emerged. I worked across business analysis, quality assurance, data, integrations, and implementation, often learning new tools or domains as the work demanded.

As the team changed over time, I also became a source of continuity. My knowledge extended beyond individual programs to how decisions had been made, how systems connected, where data lived, and why processes worked the way they did. That context made it easier for me to move between teams, translate across disciplines, and take on whatever the project needed next.

Before we could define what needed to be built, we had to understand how each program actually worked.

Every program began with a discovery process that translated existing operations into documented workflows and, ultimately, actionable user stories.

Discover

Document

Define

Facilitated working sessions with product owners, stakeholders, and subject matter experts to understand how each program operated from beginning to end.

Documented each step in the end-to-end process, including the people, roles, systems, and handoffs involved. Translated those findings into a shared understanding of how the program worked.

Broke down documented processes into individual user stories that captured what the system needed to support. These stories became the foundation of each program’s requirements.

As each program moved into development, I shifted between business analysis and quality assurance, testing the functionality we had defined while continuing to gather requirements for upcoming programs. This meant working across multiple stages of the project simultaneously, from defining what came next to validating what had already been built.

Testing Scope & Responsibilities

01 / FUNCTIONAL

02 / INTEGRATIONS

Acceptance + Regression

Systems + Data

Wrote test cases and test plans, performed acceptance testing in QA and Stage, and conducted regression testing.

Tested utility file integrations and data migrations to validate information moving between systems.

03 / RELEASES

04 / USER VALIDATION

Smoke Testing

User Acceptance Testing

Performed smoke tests following Stage and Production releases to verify critical functionality.

Facilitated UAT with Department of Development staff to validate functionality against their program requirements.

What began as a legacy system replacement became a transformation of how the Ohio Department of Development delivered financial aid. Across 18+ programs, we brought applications online, introduced self-service portals for Ohioans, and modernized the internal systems responsible for evaluating applications, approving funding, disbursing payments, and reporting. The result was more than new technology. We connected previously fragmented processes, people, and data into a more cohesive system that supported the entire funding lifecycle, from application to disbursement.

Nearly five years on this project taught me that the most complex problems rarely fit neatly within a single discipline. I learned that understanding how a system works is only half the challenge; understanding the people, decisions, and history behind it is just as important. As my responsibilities evolved, I became increasingly comfortable navigating ambiguity, connecting dots across teams, and learning whatever the problem demanded. Ultimately, this experience shaped the way I approach design today: look beyond the immediate problem, understand the bigger picture, and never let an unfamiliar challenge stop me from figuring it out.