P. Moss Drouin - Research, Design

Research systems

2026-03-12T00:00:00+00:00

Implementing research systems that scale</h1>
</p>

The Problem</h2>
I joined the eRegulations team from the beginning as a half-time designer/researcher, splitting my time between this team and another. Early on, I contributed to research by learning how regulations are structured and used by policy experts and conducting comparative reviews of policy research tools.</p>
But I was watching something troubling happen: the team had completed discovery research, but no one could see how it connected to the next phase of work. There was confusion and frustration. The discovery research existed, but it was organized in a way that only the original researcher understood. The team cared deeply about research, but the current system wasn’t working.</p>
When the researcher moved to another team, I stepped in to take over research. We were at a critical moment: we had mountains of discovery insights and a ton of evaluative research ahead of us. The team needed research to be accessible, usable, and collaborative.</p>

The Approach</h2>

Diagnosing the System</h3>
I started by mapping the current state: where were research artifacts living? How were they organized? Who could access them? What happened when someone needed an insight?</p>
The answer was scattered: discovery research in one part of the repository, no one understood the structure, templates didn’t exist, and there was no shared understanding about what counted as “research” or “an insight.” We needed a home and a shared vocabulary.</p>
I created a conceptual model showing current state (above) vs. ideal state (below) – rough sketches in Excalidraw that I walked through with the product manager. I demonstrated how the team needed a “home” for research that connected outward to tools they already used (Dovetail, Google Docs, Mural), not a replacement system that required learning something new.</p>
</p>
</p>

Building the Infrastructure</h3>
I designed two interconnected Notion databases:</p>
Research Participants</strong> — who we talked to, what activities they participated in, relevant details </p>
Research Activities</strong> — what research we did, who participated, links to plans, conversation guides, synthesis boards </p>
Notion became the hub. It linked out to Dovetail (our research repository), Google Docs (research plans and conversation guides), and Mural (synthesis boards). One system, multiple tools, clear connections.</p>
I also created templates:</p>

Research plan template</li>
Conversation guide template</li>
Research insights template</li> </ul>
The templates weren’t just formats, they embedded good research practice. A research plan template that starts with “What do you want to know?” forces you to think about methodology before jumping to execution.</p>
Making Research Collaborative</h3>
I ran back-to-back evaluative research: early design concepts → mid-fidelity prototypes → live prototype testing. But I didn’t do it alone.</p>
I paired with designers and taught them:</p>

How to write a research plan guided by research questions</li>
How to facilitate a research session</li>
How to do collaborative analysis and synthesis</li> </ul>
They ran usability tests, preference tests, surveys. The repository structure meant they knew exactly where to document findings and how to connect them to previous research.</p>
The product manager and subject matter expert/policy expert started doing secondary research—literature reviews, competitive analysis, synthesis of existing data. They didn’t have to start from scratch each time; they could leverage insights we’d already collected and carry that work forward for new initiatives.</p>
The Shift</h2>
Before:</strong> Research was a specialist activity that only one person did, and artifacts lived in a black box. Team members cared about research but felt locked out.</p>
After:</strong> Research became a shared practice. The team understood the structure. Multiple people could contribute—designers running tests, PM doing secondary research, SME synthesizing policy implications. New team members could step in and immediately understand what had been done and why it mattered.</p>
The “aha moment” for the team was seeing how easy it was to use multiple systems that work together—not replacing tools, but connecting them with clear logic.</p>
</p>
The Impact</h2>
Immediate</h3>

Capacity expanded</strong>:

Designers, PM, and SME all contributing research activities</li>
Research became usable</strong>:

Team could navigate it, understand it, build on it</li>
Shared language emerged</strong>:

Everyone understood what “research question,” “insight,” “synthesis” meant</li> </ul>
Lasting</h3>
The systems I built outlived my tenure. The team was able to backfill my position with a junior researcher instead of a senior one, because the research practice and infrastructure were strong enough that a less-experienced researcher could step in and succeed.</p>
When the team later faced a situation where they couldn’t access users (for this policy research tool), they didn’t slow down – they didn’t have to. They had two years of organized research to draw from. They leveraged existing insights and data to keep moving forward until they could conduct new research again.</p>
When the junior researcher who replaced me was promoted to another team, he reflected on the value of the systems I built:</p>

“The most valuable thing was being able to go back to find things that we learned before, or research that was done before. I’ve become more appreciative of that because I’ve had to do a lot of that in my new project in Confluence. The previous team didn’t have a super solid repository, and I’ve already run into things where there was this whole chunk of research that existed that I didn’t have access to or didn’t get to read about until now. Dovetail was pretty comprehensive in how it allowed me to find past research. I think that might be a factor of the structure that existed before—especially for eRegs. I think it was solid. I greatly benefited from there being a structure in the tool when I started</p> </blockquote>
Key Learnings</h2>
Systems thinking matters as much as research skill</strong> You can do brilliant research, but if no one can find it or understand it, it doesn’t compound. Building systems that make research accessible and usable is as important as the research itself.</p>
Trust enables systems work</strong> I had buy-in from my product manager because I built a high level of trust with her over time. That trust meant she was willing to invest time in redesigning how we worked, even when it wasn’t directly tied to shipping a feature.</p>
Templates embed best practices</strong> A good template isn’t just a format—it’s a way to encode good research practice into the team’s workflow. A research plan template that starts with research questions forces methodological thinking before execution.</p>
Capacity building is succession planning</strong> By making research collaborative and teaching others how to do it, I made myself less necessary. That’s not a bug—it’s the goal. The team’s research capacity didn’t depend on me staying; it depended on systems and skills that could outlive my tenure.</p>
Connect tools; don’t replace them</strong> Teams already have tools they know. The breakthrough wasn’t building a new system—it was creating a hub (Notion) that connected existing tools (Dovetail, Google Docs, Mural) with clear logic and shared language.</p>

This work exemplifies</h2>

Systems thinking</strong> — diagnosing organizational problems and designing solutions that scale</li>
Leadership without authority</strong> — influencing how a team works through trust and clear thinking, not hierarchy</li>
Knowledge transfer</strong> — building systems and practices that outlive your tenure</li>
Organizational design</strong> — understanding that research is a practice, not a person</li> </ul>

Co-designing with data

2026-03-12T00:00:00+00:00

</p>
From ambiguous data to clear direction</h1>
Context & Challenge</h2>
The problem</h3>
The VA had a hunch that surfacing military service history in veterans’ profiles could help them connect their service to disability claims, but no one understood how this data would actually appear to veterans or what impact it would have. The team had access to the underlying data structure, but couldn’t visualize what veterans would see, much less whether the data was even accurate or useful.</p>
</p>
The users</h3>
16 veterans across all six military branches (Air Force, Army, Coast Guard, Marine Corps, Navy, Space Force), with varying service lengths, ranks, and service types. All had filed disability claims. 50% had filed PACT Act claims; 50% had served overseas. Participants ranged from ages 25–65+, with diverse education levels and geographic locations (5 urban, 11 rural).</p>
The constraints</h3>

Data quality unknown</strong>: No one had validated VADIR (VA/DoD Identity Repository) data against veteran experience</li>
Stakeholder uncertainty</strong>: VEO and the Profile team couldn’t decide which data elements were safe and useful to display without veteran input</li>
Emotional stakes</strong>: Veterans’ military records impact their ability to access healthcare and disability benefits – data has consequences</li> </ul>
Research Process</h2>
I conducted 16 semi-structured interviews with veterans, walked through their actual production data to validate accuracy, and used a mental model mapping activity to understand their priorities.</p>
</p>
Rather than showing wireframes, I partnered with our backend engineer to pull real VADIR data, convert JSON to CSV, and visualize it on Mural boards so veterans could validate it themselves—centering them as experts in their own experience.</p>
</p>
Key findings</h3>

Location > MOS for disability claims</strong>: When connecting service to medical issues, location context was more useful than MOS alone</li>
Data quality was worse than expected</strong>: Service dates were off; MOS codes were inaccurate or missing; deployment data had duplicates and missing locations.</li>
Veterans already have workarounds</strong>: Veterans already use their DD214s, branch-specific records, and their own documentation to file claims.</li> </ul>
Fortunately, safe data did exist</strong>: Branch of service, period of service type (active/reserves), and character of discharge were accurate for 13–15 of 15 veterans and genuinely useful.</p>
Design Process</h2>
Research-informed design direction</h3>
Rather than pursuing the original MVP scope (MOS + dates + duty status), I recommended a data-quality-first approach</strong>: only surface data elements that are accurate and</em> useful.</p>

Implement</strong>: Period of service type (active/reserves) and character of discharge, as both had strong data quality and veterans found them valuable</li>
Do not implement</strong>: Military occupational specialties—data inconsistencies made them unreliable, and veterans already have better sources (DD214, SURF)</li>
Monitor for future</strong>: Deployment locations - veterans desperately want this, but data quality isn’t there yet; recommend VEO prioritize DoD data improvements</li> </ul>
I presented this not as “data is broken” but as “here’s what we can safely ship now, here’s what needs DoD partnership to fix, and here’s why veterans care about each piece.”</p>
Solution validation</h3>
Validation happened in real time during research sessions. Veterans validated their own data, articulated their priorities, then</em> evaluated a mockup against those priorities. This meant feedback was grounded in their actual needs, not abstract preferences.</p>
</p>
Final Design</h2>
Design solutions</h3>
Period of service type (active duty, reserves, etc.) and character of discharge were added to the VA.gov Profile military information section, displaying alongside branch of service and service dates.</p>
Design decisions</h3>
Why period of service type and discharge?</strong></p>

Accuracy</strong>: 15/15 veterans confirmed branch data was correct; 13/15 confirmed discharge type was correct</li>
Utility</strong>: Veterans found value in seeing active vs. inactive reserves status; discharge type matters for benefits eligibility</li>
Trust</strong>: These data elements are already on DD214s, so veterans can verify them independently</li> </ul>
Why not MOS?</strong></p>

Only 3/10 veterans said their MOS codes were actually accurate.</li>
Effective dates were wrong for 5/10 veterans, indicating deeper issues.</li>
Veterans already have better sources (DD214, branch-specific records).</li> </ul>
By showing inaccurate data to the veterans it belonged to</em>, stakeholders immediately understood the stakes. One veteran saw discharge information that contradicted their DD214—information they’d been fighting for years to correct. That emotional understanding led to concrete action: VEO updated their roadmap to prioritize DoD data quality improvements, and the team shipped only the data elements they could confidently stand behind.</p>
Accessibility & inclusive design</h3>
Trauma-informed facilitation prioritized veterans’ interpretation of their own data and made clear that confusing or inaccurate information was a system problem</em>, not their misunderstanding—essential when data represents lived experience and directly impacts access to healthcare and benefits.</p>
Impact & Outcomes</h2>
What shipped</h3>
Period of service type and character of discharge were added to the VA.gov Profile military information section. All veterans with authenticated VA.gov Profile accounts can now see this information—millions of veterans. Implementation occurred approximately summer 2024, a few months after research concluded in March 2024.</p>
Metrics & results</h3>

==☞ Recs implemented</strong>:==

Both recommended data elements were built and deployed</li>
==☞ Roadmap influenced</strong>:==

VEO updated their roadmap based on findings, prioritizing efforts to improve data quality</li>
==☞ Veterans reached</strong>:==

Millions of veterans now have access to more complete military service information in their profiles</li> </ul>
Key learnings</h3>
Real data > synthetic data</strong> Pulling actual production data and having veterans validate it revealed problems no amount of wireframe testing could have surfaced. One veteran’s inaccurate discharge information made the stakes visceral for stakeholders.</p>
Trauma-informed research is essential</strong> Several veterans found it traumatizing to see inaccurate information about their own service—especially those whose military careers were cut short by injury. Adjusting facilitation to prioritize their interpretation wasn’t just ethical; it was necessary to maintain trust and get honest feedback.</p>
Partnership is force multiplier</strong> I could not have done this research without my backend engineer extracting JSON into workable CSV format. That collaboration—data expertise + research/design expertise—made the research possible and credible to stakeholders.</p>
Mental models reveal priorities</strong> The mapping activity fit real data validation, mental model discovery, and</em> mockup feedback into an hour-long session. Each activity built on the previous one, so feedback was concrete and actionable, not abstract.</p>
“Do not build” is a valid research outcome</strong> Recommending against</em> MOS implementation was only possible because I had data to back it up. By showing inaccurate data to veterans and documenting gaps, I could present the recommendation as “here’s what we can ship safely now, here’s what needs fixing first” rather than “this is a bad idea.”</p>

[!info] View the real artifacts from this study Research questions & recruitment plan</a></strong> This plan helped everyone on our team get on the same page and make sure that we were asking the right questions, and that we’d get actionable answers. I worked with Perigean, VA.gov’s recruitment partner, to recruit veterans as research participants.</p>
Conversation guide</a></strong> This is the structure I used for each research session to guide myself through each part.</p>
Findings & recommendations</a></strong> These were my initial research findings. The information is quite dense, but my team used this format, and it worked well internally, but it is not as friendly for stakeholders.</p>
Stakeholder readout</a></strong> This is the research readout I did for the VEO stakeholders. I don’t typically add my speaker notes to presentation pdfs, but even in PPT form, the information is dense, and I wanted each slide to stand alone. This came in handy when the stakeholders asked for my research artifacts as they were ready to discuss and approve my recommendations.</p> </blockquote>

Computer-Aided Tagging: Designing for Community Trust

2026-03-12T00:00:00+00:00

Computer-Aided Tagging: Designing for Community Trust</h1>
</p>

Screenshot of the Wikimedia Commons homepage.</figcaption> </figure>
Overview</h2>
Wikimedia Commons hosts nearly 140 million freely licensed educational media files used across Wikipedia, educational platforms, and news publications worldwide. But in 2016, the platform had a critical limitation: its metadata infrastructure was built on 15-year-old technology designed for text, not multimedia.</p>
The Alfred P. Sloan Foundation recognized this challenge and awarded Wikimedia Foundation a $3 million grant to transform Commons into a modern, machine-readable platform. The Structured Data on Commons (SDC) project was a three-year initiative to create infrastructure that would enable the global volunteer community to add, edit, and search media using structured metadata.</p>

</li> </ul>

Wikidata's data model.</figcaption> </figure>

</li> </ul>

Example of what data items will live where.</figcaption> </figure>
By 2019, the project had successfully created the technical foundation. Now came the next challenge: how do we help millions of volunteers actually use</em> this infrastructure to add metadata to files?</p>
The Challenge: Scaling Metadata Addition</h2>
The SDC infrastructure was ready, but the team faced a scaling problem: a metadata quota we needed to meet. We used personas to help think this through:</p>

Laszlo</strong>, an experienced Commons admin, was overwhelmed by the number of images needing metadata. Bots could help, but humans needed to choose appropriate tags (impossible to do for millions of files).</li>
Penny</strong>, a casual Commons uploader, wanted to make her images more discoverable, but the existing metadata editing interfaces were too complex. She needed a faster, easier way to contribute.</li> </ul>
The core design challenge: How might we use computer vision to suggest tags while making it easy for both casual contributors and experienced curators to add accurate, consistent metadata?</em></p>
My Role</h2>
As the lead UX designer on the Structured Data team, I was responsible for researching, designing, and testing the Computer-Aided Tagging (CAT) tool. I was the only full-time designer embedded on our core team, working alongside product managers, engineers, and community relations specialists. I partnered with a senior design researcher on generative research and collaborated extensively with developers on implementation.</p>
Understanding the Community: Research & Insights</h2>
The senior design researcher and I conducted extensive generative research with the Commons community. We conducted:</p>

Expert interviews</strong> with long-time community members, administrators, and power users to understand historical context and pain points</li>
Comparative analysis</strong> of how other platforms handled suggested metadata and AI-assisted tagging</li>
Community consultations</strong> to gather feedback on design concepts and validate assumptions</li> </ul>
Key Findings</h3>
</p>

User flow of one of the primary personas.</figcaption> </figure>
Three critical insights emerged from this research:</p>
1. Precision matters more than volume.</strong></p>
Unlike casual tagging systems, Commons users wanted specific</em> tags. If an image showed a poodle, they wanted “poodle,” not “dog.” If it showed a specific painting, they wanted the painting identified, not just “painting.” Broad, generic tags were seen as less helpful than no tags at all.</p>
2. The community was skeptical of automation but open to verification.</strong></p>
Human verification wasn’t optional, it was essential to community buy-in. But if verification was easy and transparent, the community was willing to work with AI-assisted tools.</p>
3. Different user types had different needs.</strong></p>
Casual uploaders wanted quick, easy ways to add a few tags to their own work. Experienced curators wanted tools that could help them work through backlogs efficiently without creating additional work. Bot developers wanted APIs and data structures they could build on top of.</p>
Design Approach: Building on Community Expertise</h2>
Based on my research, I worked with the team to establish design principles that would guide our work:</p>

Human verification first.</strong> Tags would never be automatically added. Users would review each suggestion and confirm or reject it.</li>
Respect expertise.</strong> The interface should work with</em> the community’s existing knowledge and workflows, not replace them.</li>
Transparency.</strong> Users should understand where suggestions came from and why they were made.</li> </ul>
Design Process</h3>
I created interactive prototypes in Sketch and worked closely with developers to build functional prototypes for testing. I conducted multiple rounds of usability testing:</p>

Testing with community members:</strong> I observed how experienced Commons contributors interacted with the interface, gathering feedback on terminology, layout, and workflows.</li>
Testing with new users:</strong> Using UserTesting.com, I tested designs with people unfamiliar with Commons to ensure the interface was accessible to casual contributors.</li>
Community consultations:</strong> I facilitated open feedback sessions where I presented design concepts and gathered input on everything from interface layouts to terminology choices.</li> </ul>
</p>

Icon explorations for "tags."</figcaption> </figure>
</p>

Example of tag interactions.</figcaption> </figure>
Key Design Decisions</h3>
1. Opt-in design with notifications</strong></p>
Users could opt into the tool through their preferences or during upload. Once they opted in, they’d receive notifications when their uploads were ready for tagging. This ensured engaged community members could monitor quality while respecting user autonomy.</p>
2. Simple confirm/reject/skip workflow</strong></p>
Rather than forcing users to make a decision on every tag, I designed a workflow where users could:</p>

Confirm</strong> a tag they agreed with</li>
Reject</strong> a tag they disagreed with</li>
Skip</strong> a tag they weren’t sure about</li> </ul>
This reduced friction and made the task feel less overwhelming.</p>
3. Visible feedback on quality</strong></p>
I designed the interface to show users which tags were being accepted and rejected by the community, creating a feedback loop that helped improve the model over time.</p>
4. Mobile-first design</strong></p>
I designed the interface to work on mobile devices, recognizing that many community members contribute from phones and tablets.</p>
5. Privacy-first architecture</strong></p>
No personal information (IP addresses, usernames) was sent to the computer vision provider. All suggestions were stored separately until human confirmation. This addressed community concerns about data privacy and corporate involvement.</p>

Computer-suggested tags.</figcaption> </figure>

Human-chosen tags.</figcaption> </figure>

End of flow confirmation.</figcaption> </figure> </div>
Results: Enabling Community Contribution at Scale</h2>
The Computer-Aided Tagging tool saw meaningful adoption:</p>

5,809 users</strong> made edits via the tool by February 2022</li>
341,957 files</strong> had edits made through Computer-Aided Tagging</li>
72% of edits</strong> came from the file uploaders themselves, showing that casual users found the tool valuable for tagging their own work</li> </ul>
The tool successfully lowered the barrier to entry for casual contributors while providing a workflow that experienced curators could integrate into their work.</p>
Community-Built Tools & Ecosystem</h3>
The success of the SDC infrastructure and CAT tool inspired the community to build additional tools:</p>

ISA Tool</strong> - A caption and tagging tool for organized campaigns</li>
AC/DC (Add to Commons/Descriptive Claims)</strong> - Batch statement addition tool</li>
QuickStatements integration</strong> - Bulk metadata editing capabilities</li> </ul>
These community-developed tools demonstrated that we had successfully created infrastructure that empowered volunteers to build solutions addressing their specific needs.</p>
Broader Impact</h3>
The Computer-Aided Tagging tool was part of a larger success story. The Structured Data on Commons project:</p>

Exceeded the target metric</strong> of 5 million files with structured metadata</li>
Secured follow-up funding</strong> from the Alfred P. Sloan Foundation for “Structured Data Across Wikimedia,” extending the work to Wikipedia itself</li>
Created reusable design patterns</strong> that other Wikimedia projects could build on</li> </ul>
The project demonstrated that complex technical infrastructure can be made accessible through user-centered design, community collaboration, and iterative development.</p>
Key Learnings</h2>
This project taught me several important lessons about designing for communities:</p>
1. Community expertise is non-negotiable.</strong></p>
The Commons community had spent years developing sophisticated practices around metadata and organization. Successful design meant respecting that expertise and building with</em> the community, not for them. The most valuable feedback came from experienced community members who understood the nuances of what made metadata useful.</p>
2. Verification is a feature, not a bug.</strong></p>
Rather than trying to make the AI perfect, I designed the interface around human verification. This turned out to be a strength: it gave the community control, built trust, and created a feedback loop that could improve the system over time. Users were willing to work with AI-assisted tools as long as they had the final say.</p>
3. Different user types need different interfaces.</strong></p>
Casual uploaders and experienced curators had different needs. Rather than designing one interface for everyone, I designed progressive disclosure that started simple but allowed power users to access more advanced options. This made the tool accessible to both groups.</p>
4. Iteration with the community is essential.</strong></p>
The most valuable insights came from testing with actual community members, not just usability testing with general users. Community members understood the context, the standards, and the workflows in ways that outsiders couldn’t. Regular community consultations weren’t just good practice, they were essential to getting the design right.</p>
5. Design is about enabling, not controlling.</strong></p>
The goal wasn’t to make the community tag images a certain way. It was to make it easier</em> for them to do what they already wanted to do. The best design got out of the way and let the community’s expertise shine through.</p>
Continuing the Work</h2>
The Computer-Aided Tagging tool was one piece of a larger vision: making human knowledge more discoverable across languages and cultures. The success of this project led to follow-up funding and new initiatives:</p>

Structured Data Across Wikimedia</strong> extended structured metadata work to Wikipedia itself</li>
Community-built tools</strong> continue to leverage the infrastructure we created</li>
New research</strong> is exploring how to scale metadata addition even further</li> </ul>

P. Moss Drouin - Research, Design

Research systems

Implementing research systems that scale</h1> </p>

The Approach</h2>

Co-designing with data

From ambiguous data to clear direction</h1>

Context & Challenge</h2>

Solution validation</h3> Validation happened in real time during research sessions. Veterans validated their own data, articulated their priorities, then</em> evaluated a mockup against those priorities. This meant feedback was grounded in their actual needs, not abstract preferences.</p> </p>

Design solutions</h3> Period of service type (active duty, reserves, etc.) and character of discharge were added to the VA.gov Profile military information section, displaying alongside branch of service and service dates.</p>

Computer-Aided Tagging: Designing for Community Trust

Implementing research systems that scale</h1>
</p>

Solution validation</h3>
Validation happened in real time during research sessions. Veterans validated their own data, articulated their priorities, then</em> evaluated a mockup against those priorities. This meant feedback was grounded in their actual needs, not abstract preferences.</p>
</p>

Design solutions</h3>
Period of service type (active duty, reserves, etc.) and character of discharge were added to the VA.gov Profile military information section, displaying alongside branch of service and service dates.</p>