Ona Data

Launching a product

I reviewed feedback and made the key decisions for establishing an enterprise-level product from the university-built software. Our future customers would be organizations with many roles and layers of management. Before designing anything, I talked to existing users of the old app and assessed competitors: Fulcrum, KoboToolbox, ODK, and SurveyCTO. The themes that came up established v1 of the app.

Put forms in projects; put projects in organizations

Organizations needed more than just a list of forms. The old app listed out forms in a table format. Some organizations have thousands of forms. They asked for a better search or filters for the table. I read between the lines and saw they needed a system that aligned with how they worked: international NGOs oversaw multiple country offices with multiple project teams. This foundational approach established the model for data access and sales, and it turned out to make a lot of sense.

Letting admins fine-tune permissions

Permissions were the highest-priority theme and we built them on top of the new project and organization approach. My priority was to give enterprise users with thousands of users across country offices permissions that are explicit, tuneable, and auditable.

Smarter checks to reduce error

Data collection forms in Ona Data are authored as XLSForms, a spreadsheet defining fields, labels, choice lists, form logic, and variable names. I could not design around this technical requirement, so I looked for ways to prevent errors. We created a wizard-style flow that verifies the spreadsheet on the way in and lets a user preview the resulting form before it goes live, which helped program managers feel more confident in their work.

A form dashboard to cover 80% of the need

Given how varied the underlying data could be, a single data view was never going to satisfy everyone, and we didn't have the resourcing to build a custom view for every use case. I designed a default view that covered the common cases, then gave power users a path out through specialized exports and APIs that pushed data into tools like Power BI and Tableau.

Growth, Retention and Churn

Establishing a research program

Our growth through our first years were exponential. Our bet paid off, but our next steps presented a process problem. We started small, but the platform needed a team to maintain, and having a shared point of view of what to build would not come without effort. I led the effort to gather feedback and make decisions with data.

Unlike our field products, this wasn’t a job for in-context observation — these users sit at desks in country offices and I needed breadth. I ran a survey that returned 79 responses from day-to-day users across 40 offices, paired with one-on-one client interviews, and I stood up a standing group of three enterprise organizations for roadmap feedback. I weighted that group deliberately: what their accounts need has a way of arriving at every other account eighteen months later.

A framework for decision-making

I built a prioritization framework weighing three things against each other: lifetime cost to maintain, value to our key users, and revenue potential. It wasn’t sophisticated. The point was that it existed and everyone could see it, so disagreements moved from “I think users want this” to “we disagree about the cost column.” That’s an argument you can finish.

I validated against the standing group and against willingness-to-pay conversations before anything reached engineering.

Reassuring admins with an audit view

I scoped it to two jobs: catching destructive actions — deletions, edits — and seeing who has access to data. We used grouping to keep it manageable and shipped it at the form level first. The response was strong enough that users are now asking for it at project and account level.

Catching bad data while it can still be fixed with AI

Field data goes wrong in recognizable ways: a fifteen-minute form completed in ninety seconds, a GPS point that doesn't move, the same answer repeated straight down a column. All of it is obvious the moment a submission arrives and invisible three weeks later, when an analyst opens the export and the enumerator has long since moved on. I designed anomaly detection to flag those patterns on arrival, inside the data view people already check. Figma Make let me skip mockups and go straight to a working prototype using our design system.