CHaiN
The end of the research-to-insights pipeline is a high lift stage for projects that generate qualitative data. As sample size increases, so does required effort. I built a tool that encodes my qualitative UX research experience to handle analysis and reporting at scale while keeping human review and judgment at critical points.
I independently designed and developed CHaiN over 8 months across roughly 15 iterations. I owned the full scope: architecture, pipeline design, and export system. CHaiN is in active development with a planned roadmap of additional capabilities.
-
Sending all input files to the Gemini API in a single request posed 2 risks: request failure or vague, incomplete responses. Request failure results from exceeding token limits. Vague, incomplete responses result from the model processing too much data at once. Sequential prompting addressed both.
The full insight pipeline runs 5 stages:
- Batch Analysis: Extracts insights per file
- Cross-File Synthesis: Combines and reduces insights across files
- Thematic Grouping: Assigns a theme label to each insight
- Group Data Generation: Populates the group structure
- Executive Summary: Creates a summary of insights and recommendations
Model selection and temperature are set per stage based on cost and quality tradeoffs. Gemini Flash-lite handles analysis of individual files because a more advanced, expensive model isn't required. Gemini Flash handles synthesis and thematic grouping because these stages don't have a human review gate and quality preservation is the priority. Temperature is fixed at 0.3 for thematic grouping for deterministic results. Inconsistent theme labels would cause the grouping logic to fail downstream.
-
I used a JSON schema to define a data structure for all outputs. I quickly learned that it was not enough to specify which fields to populate in the schema when making API calls. Prompt instructions didn't guarantee compliance. To put out fires of inconsistent output, I relied on defensive programming. Until I found a better solution: filtering the schema using pipeline context.
I filtered the schema so that each stage of the pipeline used only relevant fields. This spared me from the more cumbersome, downstream cleanup. I also filtered the schema based on whether the provided research data were images or text, since input type determines which fields are relevant. Dynamic retrieval forces the model to concentrate on the correct fields, reducing the need for defensive programming and limiting each call to only the fields relevant to that stage. It also protects a user's time investment by minimizing the chance of vague or misaligned insights at the second review gate.
-
When I tested an early version of CHaiN with UX research peers, it became clear that automation had drawbacks. Full automation didn't build user comprehension and trust. Incorporating AI amplified the tool's capabilities -- and researcher skepticism. As a UX researcher familiar with the broader field's reservations and my own experience with the limitations of AI-assisted analysis, I knew I had to find an optimal human-AI balance. I placed 2 review gates where researcher input has the most downstream impact.
The first gate follows project detail extraction: a missing or unclear project objective propagates through every subsequent pipeline stage, so input here has the highest leverage of any intervention point. While standard to formally document a research plan, if and how this is done varies widely across individuals and teams. Requiring a complete and reviewed project overview was my way of enforcing a principled research practice.
The second gate follows insight generation, giving the researcher a final opportunity to revise before the pipeline commits to generating exports. This isn't just a usability consideration. It is a way to build user trust and ownership, a prerequisite for CHaiN being used at all.
-
More research data meant more insights were generated by CHaiN. But volume and insight count don't have a 1:1 relationship in real analysis. UX researchers often condense large amounts of data to a digestible number of insights and do so by aggressively trimming redundancy while capturing nuance. This is an art form. And I needed a way to represent it as code.
My goal was to specify the insight count in the cross-file synthesis stage. At first, I divided the number of insights generated by file analysis by the total number of analyzed files. However, this returned the same number regardless of how many files were analyzed. I needed a formula that was responsive to data volume.
I defined a linear reduction formula to calculate a number proportional to volume. I chose the 0.65 reduction factor to control for the saturation that happens as sample size grows. At this value, the formula cuts insight redundancy with enough strength while exercising restraint to preserve nuance. I also defined a floor of 6 so the formula never reduces below a meaningful minimum for a substantive report.
-
As I arrived at a functional version of CHaiN, I began to think of how to engineer value. I'd already invested a good amount of time designing and developing a way to structure and analyze data. To distill more value, I shifted focus to generating multiple output formats, including a Google Sheets export.
A spreadsheet export is not a very attractive format. Yet, it creates a node for 2 user journeys: (1) Building a dashboard or insights repository and (2) Re-entering CHaiN's pipeline. Researchers could update spreadsheet content and regenerate a report. Or use the same content with a different Google Slides template to change the visual design. The value is in paying for the analysis cost only once, which is meaningful, especially at scale.
Here was the catch: Translating the multiple levels (project details, insights, groups, summary) of the JSON object to the 2D shape of a spreadsheet. My solution was to use dot notation to represent hierarchy. On import, the dot-separated keys are parsed to reconstruct the original nested object.
-
The JSON object was the source of truth for report content. It was a deliberate architectural choice that governed what and how content was rendered across 3 export formats. Each format offers something unique:
- Slides Report: An expected stakeholder deliverable.
- Sheets File: Functions as both an export and import file.
- HTML Report: A portable, interactive format.
The HTML report opens the door to 2 main things:
- Compelling Presentation: Standard deliverables constrain creativity. An HTML format unlocks animated transitions that add character and polish.
- Interactivity: Elements of play, like interactivity, make information memorable. For instance, quizzes offer a new way to engage with research content.
The MVP for an HTML report was scoped to include both animated transitions and insight quizzes. These were differentiating features that made the analysis cost worth paying.
-
The tool's predecessor lived in a single Apps Script file bound to a Google Sheets file. The spreadsheet was where users needed to enter the text that would be pulled into a Google Slides report. There were several limitations here: (1) A utilitarian interface, (2) functionality bound to Google's ecosystem, and (3) maintenance friction. The 2025 rebuild reacted to these constraints.
It would have been convenient to use a Google Form as the new user interface. Instead, I opted for an HTML form, trading in extra effort in return for tool portability. I wanted flexible architecture. Building to reduce the dependency on Google's system was a way to design for future versions that might need to live outside it. In the same spirit, I adopted the Bootstrap framework. Its grid system worked across device types without ongoing upkeep, a practical choice for scaling and maintaining the codebase.
As I scaled, the need for modularity grew. I organized code into a family of Apps Script files. This made debugging and iteration easier and kept the code reusable. For instance, in a separate project, I used one of the files as a library to automate a Slides export. Frontloading the work of good architecture has paid off as I continue building.