Ona needed an enterprise data collection and field survey platform that non-expert users such as frontline staff at NGOs could use to manage complex workflows: sign-up, onboarding, data collection, permissions, and cross-team data management.
Ona Data is a mobile and web-based data collection and visualization platform. It is primary used by organizations to build digital forms and gather field data offline on Android devices or tablet and mobile web browsers. When reconnected, data automatically syncs to the website where it is available to analyze using maps or charts, export as structured data, or connect to data tools using an API.
My Role & Process
Ona Data grew out of work the co-founders had done at Columbia University's Earth Institute, supporting large-scale data projects including the Millennium Villages Project, where we built survey tools for enumerators working in the field. That experience is what convinced us the data collection space could use enterprise-focused solutions focused on better data collaboration, rather than only one-off tools for individual research efforts.
I owned initial UX strategy and design end-to-end for the platform, from early research through wireframes, prototypes, and developer hand-off. The platform started with a lean team. Over the years, we grew from a few engineers, a support lead, an account manager, and me, to into a full cross-functional org: a technical lead, an account management team, a larger engineering team, SRE and QA engineers, a support team, and eventually several mid-level designers I mentored into owning most of the platform's newer features.
As product design lead on the project, my primary goals were to keep the roadmap grounded in real needs rather than anecdotes and maintain UX quality. We ran quarterly roadmap strategy sessions that weighed requests from support and business development against what the technical team could realistically deliver, and tied the result back to one narrative the whole team could aim for. To ensure design quality and UI/UX consistency, I worked with my designers to produce a design system and component library to keep the platform's surface consistent. For large new features, I worked closely with designers, support team, and engineers to make sure we understood the full problem, and we mandated a design QA step before anything was deployed to production.
Alongside the product work, I built a retention strategy: a plan covering lifecycle phases, account health metrics, and segment-specific tactics for enterprise versus SMB customers, including a gap-period email sequence and an enterprise check-in framework. The goal was to look for reduced usage and time between projects as the primary retention risks, which shifted our retention to be proactive rather than waiting to engage with users when they reached out to cancel.
Early Ona Data strategy sessions
Key design challenges
Building forms without writing code
Ona Data's most powerful feature is also its most complex: forms are authored as XLSForms, using a spreadsheet to define fields, labels, choice lists, form logic, and variable names. It was a foundational technical requirement we could not build around for our use cases, so we had to find a way to prevent errors. We created a wizard-style flow that verifies the spreadsheet on the way in and lets a user preview and check the resulting form before it goes live. This helped non-technical program manager feel more confident in their work.
Key steps in the add form wizard
Permission levels
Permissions were the flow we spent the most time on, and the one I'd still call unfinished. The hard part is that the same permission model has to work for a small team of a few users and for an enterprise account managing thousands, and those are genuinely different problems. What we landed on works well for the large majority of users, but scaling it cleanly to very large enterprise accounts is something we kept iterating on rather than something we ever fully solved.
We initially introduced project-level permissions that passed to all forms in the project. Enterprise users needed more granular permissions, so we worked closely with them to define additional form-level controls.
Form data view
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. We built one solid 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.
We found through surveys that most organizations employ data analysts and have existing data visualization tools at an organization level, so we chose to offer just enough functionality in the form activity view to help real-time tracking during live data collection and light data analysis.
Activity view
The activity view needed to show a detailed record of anything that touched the data, but a literal line-by-line log of every action would have been unusable. We scoped it by asking what people actually came to this view to do — mainly catching destructive actions like deleted or edited submissions, and seeing who had access to what — and designed around those two jobs rather than trying to represent everything. We also grouped related activity instead of listing every event individually. It launched at the form level first and got a strong response; users have since been asking for the same view at the account and project levels.
The activity log groups similar items and highlights data access and changes to the database. We decided what to show based on closely working with users through early prototyping.
Outcome
Our product discipline showed up in the business results: enterprise revenue and the account management and support function built around it both grew, and those relationships opened adjacent lines of business, including data visualization and custom training. Ona Data ARR has been consistent or grown since launch.
As of 2025, Ona Data accumulated 230M+ submissions and 580K+ forms since launch and been deployed enterprise-wide by UN organizations and global humanitarian partners. It's been used in almost every country in the world, supporting an array of vital impact projects, from helping countries eliminate polio and recover after devastating natural disasters.
Reflection
Ona Data wasn't a single-revenue-stream product, which is what made prioritization genuinely hard. Beyond the standard tier for organizations running 10–20 projects, we supported enterprise clients running hundreds of projects across countries, an on-premise version for large enterprise clients, and large data-collection engagements tied to custom dashboards we built — all on a team small enough that most of its capacity went to maintaining what already existed, in a mature market with real competition.
The real conflict was between what would open new revenue and what would keep existing enterprise clients happy, knowing that every new feature meant ongoing cost, not just build effort. I resolved that by building a framework that weighed lifetime engineering cost against value to key users and revenue potential, which gave us a real basis for prioritization instead of the gut calls that had worked when we were smaller. We backed it with a standing group of engaged users we could go to for feedback before committing engineering time to it.
Role: Design Director and IC