← All work The research practice

Starting a research practice at a company with no usage data

OPEXUS grew up as a developer-led company, and for most of its history it built what its customers asked for. It heard from a handful of them and took what they said literally, with no way to tell whether a problem was common or belonged to a few power users, and it had no usage data for any of its products. I was the first hire in the product organization that was formed to change that.

The accounts in decline
Company
OPEXUS / Casepoint
Role
Lead Product Designer: user research, product analytics, sole Pendo administrator
Timeline
2023 – 2025
Outcome
$10M in at-risk revenue identified; research cited in a Senate Judiciary Committee hearing

Talking to customers

I started traveling to where FOIA officers work and watching them process requests, from intake through search, review, approval, and release. Seeing the same work done at many agencies showed which problems were common and which belonged to one customer. I began with the customers who were already the most involved, people I had met at our summits and customer advisory councils, and they introduced me to others. Some sessions were on site and some were remote. I arranged them myself, under a plan agreed with leadership.

Getting customers to take part

The biggest barrier was that government customers did not want to take part. Research participants are usually paid, or at least fed, and federal employees are not allowed to accept either from a vendor. We gave them a sense of ownership over the product by showing them how their ideas were being folded into the roadmap, and at our summits they could tell other agencies that a feature had been built with their input.

Customers also took part in working groups, where we showed them sketches before anything was built, because people have less to say about something that looks finished. In time product managers ran customer calls as well, and we pooled what we heard. The research went into the quarterly product reviews, and each team was given a goal for the number of customers it spoke with.

Once AI tools could write code, I would sit with a customer at their office, sketch a solution, and have a working prototype for my team’s design review. A change cost little to make, so we could release it, watch what people did with it, and revise about ten times faster than before. We got far more research done.

What the visits found

The largest delay in the process was outside our software. To answer a request, an officer has to collect documents from record custodians: the scientists, lawyers, and policy analysts in other offices who hold them. They have deadlines of their own and do not report to the FOIA office. In ten years of request data, the wait for records rose from about 30% of the average response time in fiscal 2015 to about 90% in 2024.

Where the response time goes

I presented the finding at the company town hall, at the sales kickoff, and to customers at the summits. The sales team used it as a discovery question on calls. It was cited in the Senate Judiciary Committee’s hearing on the Freedom of Information Act, and it was part of the argument for the public records portal.

Usage data

Approval for Pendo

To find out which parts of the products were used, I asked the company to buy Pendo, a product analytics tool. The constraints were cost, security, and the engineering time needed to install it. I wrote a business case, the tool went through a security and compliance review, and we ran a trial on one product before committing to the rest. I also had to win over the engineering leads, whose teams would be doing the installation. The process made all of us uncomfortable, but I thought the company needed to do the work to grow intelligently.

Once it was approved, I worked with the engineering leads to get it installed in more than ten applications, and I was its only administrator. Having been a front-end developer, I could go through each installation with the engineers.

I also used the platform for in-app surveys, for session replays that showed what had led up to a reported bug, for announcing changes to customers, and for automations into Jira. With revenue operations I connected it to Salesforce, which gave the company its first way to tie the use of a feature to revenue.

The same data went into design. It showed the ten things people searched for most often, and the new search screen puts them one click away. I also tagged the features that did not follow the design system, so that I knew where each one was and how much it was used. Both are in the design system case study.

The adoption finding

In January 2025 OPEXUS merged with Casepoint, and the combined company had to decide what to keep from two overlapping product suites. FOIAXpress had three main modules: Case Processing for intake and workflow, Document Management for storing records, and the Document Viewer for review and redaction. All three were sold as core, on the assumption that an agency using the first would use the other two.

Case Processing was in heavy use. At many accounts Document Management and the Viewer reached only 12 to 18% of users, and at five of the largest accounts Document Management reached 7% or less. Agencies ran intake and workflow in our product and did the rest somewhere else.

Whether to raise it

I found the gap while working in the data. I had not been asked to look at module adoption. Raising it meant putting my name on a number that contradicted how the product was sold, and I had to be sure of the number before I did. It bore on what the combined company would keep, so I took it to my manager, who took it to leadership.

The adoption chart

The case for combining the two suites shifted from the overlapping repositories to finding and reviewing records, the part of the process agencies struggled with. I stopped proposing improvements to the Viewer and designed for the workflow agencies were running.

The staffing cuts

In early 2025 federal agencies began cutting staff under the Department of Government Efficiency, and our pricing was per seat. Tracking was already running in every product, so the exposure could be measured within days.

For each account I fitted a trend to its weekly active users, flagged the ones in decline, and set them against annual recurring revenue. By the end of June the accounts paying more than $100,000 a year had 15% fewer weekly users than in January, while the smaller ones had grown. The flagged accounts were worth more than $10M a year. That was early enough to inform a pricing revision, and it gave the account and marketing teams a list of customers to contact first.

Weekly active users, 2025
The accounts in decline

Research for the portal

For the public records portal I interviewed people who file requests often, several of them journalists, to learn how they would read an interruption in the request form. I ran moderated usability tests with twelve people who had filed requests before, to see whether they could find a document in the reading room. What those studies changed is in the portal case study.

What I learned

Have an opinion and own it

Putting my name on the adoption finding was the hard part. I titled the chart “Does anyone use Document Management?” and took it to my manager, and it changed the case for combining the two product suites.

Gather enough data to be directionally right

I started the visits with the customers who were already the most involved, not a representative sample. The wait for records that I saw there was borne out by ten years of request data. After the staffing cuts began I fitted a trend to each account’s weekly users within days, in time to inform a pricing revision.

What I would do differently

Administering Pendo took about a day a week away from design. At OPEXUS that was worth it, because nobody else would have done it and I could do the technical work myself. At a company with a data team I would spend that day on the questions and leave the instrumentation to them.