Giving the Product Org a Memory
EverDriven's Research Framework
Click the headings to read more.
We're collecting feedback, but we're not learning from it.
By 2025, the UX Maturity Audit had put EverDriven's UX practice at Level 3 of 6 on the NN/g scale: functional and promising, but inconsistent and inefficient. The research side showed why. Feedback went in and nothing came out.
- Feedback disappeared. Over 500 product-request tickets sat with no routing or follow-up.
- Research was siloed. Marketing, Operations, Sales, and Product each gathered their own insights, with sporadic sharing and no research repository.
- Nothing was coordinated. CSAT surveys, CAB (Customer Advisory Board) meetings, and field observations happened independently. Four studies had been started and abandoned, and a comprehensive 2023 District Portal study was shelved.
- Nothing was measured. We couldn't tell whether what we built improved the experience. By 2025, I was relying on 18-month-old research and Driver Support calls to stay connected to users.
"Our experience has been that we put in a product request and it just goes to die." Internal stakeholder
The challenge: move EverDriven from Level 3 toward Level 4 by the end of Q2 FY27 (December 2026), with Level 5 as the long-term goal. This was the audit's first recommendation, and my UX Lead encouraged me to take it on as my year-long OKR.
Why This? Why Now?
I wanted to move EverDriven in three directions.
- From reactive to proactive. Teams found problems after launch or responded to competitor actions, because nothing told them what users needed before it. I wanted research to shape the work before it shipped.
- From subjective to objective. We valued users, but we didn't have systems to act on what we learned — our knowledge was largely tribal or colloquial. I wanted decisions to rest on graded evidence and measurable signals, not opinion.
- From fragmented to cooperative. Marketing, Operations, Sales, and Product each gathered their own insights, and often did not share them in a timely manner. I wanted one research ecosystem where everyone contributes and everyone benefits.
I designed a research loop for EverDriven with five stages: Listen (intake, CSAT surveys, CAB meetings, analytics), Capture (route it to the right team and store it), Synthesize (AI tools surface patterns and track competitors), Guide (research informs product and design decisions), and Decide and Act. Then I built the parts I could reach.
What exists:
- Munin, a Confluence research repository organized in three tiers by evidentiary weight, with a Slack-to-Confluence flow for adding to it. Live.
- Heimdall and Mímir, two Claude-based tools. Heimdall (the Research Synthesizer) synthesizes internal UX health, and Mímir (the Competitive Benchmarker) tracks competitors and driver sentiment. In beta, open to product, design, and marketing.
- A documented research process, with methods, confidence levels, and a rule that every design ties to a HEART signal before work begins. It lives in the Product Design team charter, written in July 2026 on top of design ops documents the team adopted in January.
Most of the tools I built were named after Norse mythology: Heimdall, who could see everything inside the realm; Mímir, who had knowledge beyond the realm; and the ravens Hugin and Munin (known as thought and memory), Odin's ravens who served as his extra eyes across the realm.
What was proposed or started and didn't land: HEART measurement for the mobile apps, a training series for Operations and Sales, and Hugin, a redesigned Jira intake.
The Work
Deciding What to Build First
Munin had to feed Heimdall, so the repository came first. The other candidate was Hugin, the redesigned Jira intake. I weighed it as a larger lift, and a lower priority than the overhaul of tech's Jira environments, so it went behind the repository.
I organized Munin by what a page is, not by which product it concerns. Every page lands in one of three tiers by evidentiary weight (Signals, Studies, or Synthesis) and carries labels for persona, product, and research type, so one artifact can belong to several at once.
The tiers decide how far a page can be trusted. A Signal is unsolicited input from one source at one moment, and it counts only in aggregate. A Study is deliberate research and can be cited alone. Synthesis answers a question across sources and is what stakeholders should be pointed at first. When it's unclear which tier a page belongs in, it defaults to Signal: a study mis-filed as a signal just gets aggregated, while a signal mis-filed as a study lets one offhand comment get quoted as evidence.
I also cut a label. I tested an Experience axis against the full set of artifacts, 19 at the time, and 11 of them carried three or more of its six values. A label that applies to most of the repository doesn't narrow a search.
The pages have two readers, people and the synthesis agent, so I wrote the rules for both. The agent can't read attachments or drafts, so key information goes in the published page body. Adding to it takes one step: post to the #research-share Slack channel, and an automated poller files it, though a person still has to apply the labels.
I built two tools with separate jobs. Heimdall looks inward at UX health. Mímir looks outward at competitors, driver sentiment, and industry trends. When a question belongs to the other tool, each one points to it instead of guessing.
I worked with Claude to write the specifications for both. The decisions about what each tool should read, trust, and refuse to claim were mine. Heimdall evaluates UX health across four dimensions (what's working, what's not, opportunities, and emerging trends), cites its evidence, separates validated findings from hypotheses, and reads only from the Munin space. Mímir tracks HopSkipDrive, FirstAlt, Adroit, and Uber/Lyft as a reference platform, and frames every competitive finding against EverDriven's own model before it informs a decision.
Both produced real output, and I treated both as beta. Heimdall's data was thin: it had Munin and HubSpot behind it, but three sources the framework named (Salesforce, Avoma/Gong, and the data lake) had no access set up for the design team. I would have wanted more sources before a full release.
I set one rule for the design team: define the HEART signal before the design starts, and grade every research claim before it informs a decision. A design isn't research-informed because it feels right.
Claims are graded high, medium, low, or gap. High means multiple independent sources, a large sample, or primary research with the affected users, and it's recent. Low is a single anecdote, an extrapolation, or research more than two fiscal years old. A gap gets stated plainly with the method that would close it, because assumptions dressed up as findings are worse than an acknowledged gap.
Interviews and surveys start with a hypothesis, what we'd do differently based on the answer, and what finding would confirm or refute it.
I also built the grading into a tool. The persona-generation skill I wrote for Heimdall drafts user personas from Munin research and survey data, requires every quote and request to trace to a named source, grades its own confidence, and only ever produces a draft for human review. We built three personas (district user, service provider, and caregiver), planned to use the caregiver persona and do research to enhance it, and I used Heimdall to produce a list of driver-shaped holes, the gaps in what our research knew about drivers. That list helped guide the driver foundational research we started in September 2026.
The skill also had to account for weak data. The caregiver survey I drew on had almost 600 respondents over six months, but no owner, wasn't an NPS, and had Likert questions written to skew positive. Its most useful part was the long-form text, and the scores had to be read with a grain of salt. I raised the survey with marketing, and they told me they had closed it.
I used Heimdall myself on the no-show flow. I didn't pull individual Munin pages; I asked it about no-shows, and it synthesized the answer. It gave me information on increasing the no-show wait time from two minutes to five, which was also a parent pain point (drivers leaving too quickly), and it pulled service provider quotes about their pain points. I used both while working with the product manager and the engineering manager on a solution. The wait time is a process change, so the most design could do was recommend it.
I wrote these into the research process pages and the Product Design team charter, in July 2026, building on the design ops document my manager wrote in late 2025. It also records our design principles, which my manager developed and I documented. The design ops documents it builds on were adopted by the team in January 2026 and announced by my manager at a lunch and learn in February. We all agreed to it. I can't speak to how anyone else used the rules.
Teaching Operations and Sales to Notice
UX can't be everywhere, but Operations and Sales already are. I planned a training series to teach them to recognize UX friction and report it, to use their existing skills working with our users and enhance them for better information.
I wrote the first script, "What is UX?", a four-minute video script built on one idea: the friction people notice every day is data, and there's a way to send it to the people who can act. I'd planned more, even a list of them, but we never got there. The LMS went live right at start-up, the company's busiest time of year, and some content made it in, including Tacos and Topics, my lunch-and-learn series, but it was prerecorded. None of my framework videos shipped.
I tied the framework's measurement to Google's HEART model, and the work stopped at the analytics foundation. HEART needs events that mean something, and ours didn't: one mobile event was literally named "button tapped."
In February 2026, the mobile engineering manager, the mobile PM, and I worked through HEART for SafeRoute and RideAware: goals, signals, and metrics for each, then the metrics we wanted to start with. The analytics setup would have needed an overhaul to support it, so I wrote new event names across several Confluence documents, organized by large flows, using a Claude skill I developed. The work was repeatedly reprioritized. Then the mobile engineering team was eliminated, which ended the roadmap it depended on. None of the mobile measurement was implemented.
I ran a third workshop, for TripCentral, on October 21, 2026. My role was eliminated in a reduction in force the next day, so I don't know what happens with it.
What I Learned: These were my first experiences with running a workshop, and my first time working with HEART. Looking back, I would have spent more time working on actual goals, instead of trying to push forward to get the matrix done.
Several pieces of the framework depended on systems other people owned, and most went their own way: intake, customer surveys, and the CAB.
Intake. I initially took the intake redesign on as part of the framework. As I'd designed it, Hugin routed tickets by product and type and gave submitters follow-up. The VPs of Product and Engineering later built their own system, separate from my work. Once implemented, it would route every request through the C-suite, but it wouldn't give requestors visibility into request status or the pain point raised.
Surveys. I'd planned a CSAT program with Marketing: a biannual survey timed after peak activity, plus feedback at key touchpoints. CX pulse surveys replaced it.
The CAB. We participated in CAB meetings, but the door to improving the CAB format never opened.
Customer Experience. One partnership was still moving when my role ended. The Customer Experience team, part of Operations, and I had started monthly meetings so that research stayed aligned and future surveys could serve both CX and UX. The VP of CX was setting a cross-organization research committee as an OKR for Q3 of the fiscal year (January to March 2027), and we had been planning it together. The committee had originally been planned for Q1 (July to September 2026), but the VP of Product reprioritized it, which pushed it to Q3.
Adoption stayed low in the parts that were mine, too. Munin was live, and the Slack flow was open to both design and product. I demoed it at a product team meeting, and I used it myself while I was actively doing research, when it was valuable to me. I don't know why it wasn't adopted after that. Heimdall and Mímir were open to product, design, and marketing, and as far as I know I was the only person using them.
What landed
- Heimdall's synthesis informed real work. It helped build three personas, its list of driver-shaped holes guided the driver foundational research we started in September 2026, and it supported a recommendation to raise the no-show wait time from two minutes to five, a pain point for parents. That's a process change, so design could only recommend it.
- Research projects were started, the driver foundational research and RideAware research, as the beginning of a more regular research cadence for our product organization.
- Heimdall and Mímir ran in beta, open to product, design, and marketing. Mímir's output reached a product marketer and the director of business process improvement, and I don't know whether they used it. As far as I know, I was the only person using either tool.
- Munin, the research repository, went live with a Slack-to-Confluence flow for additions. It held 19 artifacts when I tested its labeling scheme and more by the end, though I don't have a count: CAB transcripts, survey results, one-off conversations with users, field research notes, and more. The VP of Product and I contributed, and before the Slack flow my design manager sent me artifacts to add. Adoption stayed low.
- The research process is documented in the Product Design team charter: methods, confidence levels, and a HEART signal defined before design. The charter, written in July 2026, builds on design ops documents the team adopted in January 2026.
What didn't land
- HEART measurement for mobile was never implemented. Workshops ran for three products, but the mobile engineering team was eliminated, which ended the roadmap the work depended on. The TripCentral workshop was the day before my role was eliminated, so I don't know its outcome.
- Planned pieces went elsewhere or stalled. The VPs of Product and Engineering built their own intake system, CX pulse surveys replaced the CSAT program, and the training series never shipped.
- The Customer Experience partnership was cut short. We had started monthly research meetings. A cross-organization research committee was planned for Q1 (July to September 2026), moved to Q3 (January to March 2027) when the VP of Product reprioritized it, and had not launched when my role was eliminated.
What I can't say
- Whether maturity moved. I'd started the next maturity audit to measure progress toward Level 4, and it won't be completed. I also don't expect the company to keep using Heimdall or Mímir.
Reflection
Sometimes, people are more comfortable with a broken system.
Building the framework was the easy half. The hard part wasn't implementing it, it was getting people on my side. I had the verbal support of our VP of Product, but it was only verbal, and the framework was often not his priority.
Verbal support isn't sponsorship, something I learned the hard way. Many people said they wanted to overhaul how we handled research, but it didn't go further than that. Our approach to research and metrics hadn't changed in the four years I'd been there, and most people took an "if it ain't broke" approach. This enabled us to simply check the box when we implemented Google Analytics, and made us comfortable with our primary success metric being "did it ship?"
While this was a struggle on the people end, this project was a whirlwind of AI tech experimentation. I learned to use gherkin syntax (a structured method of writing user stories) to construct project instructions, skills, and tasks. This knowledge enabled me to streamline other projects, like the follow-up maturity audit this year. The framework also became a key piece of a design agent I was building with my coworker, both for company context and general UX knowledge.
What I’d Do Differently Next Time
- Build stronger relationships with stakeholders. Working cross-functionally outside of tech was a weakness for this project. EverDriven's tech department was largely spurred on by other departments, which means I could have found more action-driven sponsors to adopt the framework faster.
- Work on building the LMS knowledge base sooner, in the hopes of encouraging higher-quality surveys, follow ups, and base UX knowledge across the organization.
- Advocate for prioritizing the Google Analytics overhaul. We went for years without a proper analytics system, which hurt the HEART workshop goals and crippled us when looking for ways to define success and identify problems.