Architect turned Product StrategistDesignerTechnologistLead Strategist Strategist A visionary designer, augmented by AI to build and solve.

My Work

• 

  • Product strategy
  • Workflow design
  • SaaS

  Data Import at Scale

  Lead Product Designer

  Designed for Scale:

  How I transformed a bottleneck in data import into an adaptive workflow, helping users get to the product’s core value, compliance analysis, 24× faster.

  • B2B SaaS
  • Role: Lead Product Designer
  • Duration: 6 months
  • Partners: Technical Product Manager, Solution Architect, R&D, Program Manager, Design System, Technical Writer

  • B2B SaaS
  • Role: Lead Product Designer
  • Duration: 6 months
  • Partners: Technical Product Manager, Solution Architect, R&D, Program Manager, Design System, Technical Writer

  01 The real bottleneck wasn't analysis. It was getting to it.

  100 data files. 2 hours later. And still no analysis and insights.

  The product helped technical users analyze data for compliance, but getting that data into the system was a major hurdle.

  You’ve got 100 related data files, ready for analysis?

  1. 01

     Select 1 data file Choose a single data file to import.
  2. 02

     Configure the data Manually map columns or apply an existing configuration to speed up import. The configuration control sat outside the main workflow and was often overlooked.
  3. 03

     Import as a standalone dataset Each file is imported as a separate dataset, even when the files belong to the same dataset.

  010202

  Repeat 100x

  The same workflow should be repeated for each data file, before analysis can begin. Importing 100 files could take well over 2 hours.

  Some customers built custom scripts to batch-import files, adding engineering effort and risking schema mismatches.

  ---

  The strategic call: Fix the data import bottleneck, before adding another analysis feature.

  Customers had more than 10 feature requests competed for attention beyond the existing roadmap, with a compressed release timeline.

  I worked cross-functionally to weigh customer impact, product priorities, technical feasibility, and release constraints. I advocated for prioritizing data import, and we aligned on it as the highest-impact opportunity because it was blocking users from reaching the product’s core value: compliance analysis.

  How might we get users from large datasets to meaningful analysis faster and with less manual work?

  02 The system needed a reference file. Did the user?

  Technical constraints: Schema detection complexity and limited engineering capacity.

  Users needed to import a group of data files as one dataset or append data to a compatible existing dataset. Engineering however needed a reference file to establish the expected data structure and due to the backlogs were looking into quick fixes.

  I partnered directly with Solution Architect and R&D to understand the underlying dependencies and explore what we could deliver within the release timeline.

  ---

  First direction: A pragmatic compromise, multi-file import built around a reference file for schema detection.

  1. 01

     Select a reference file Choose one file as reference to establish the expected data schema for the import.

     

  2. 02

     Choose create or append Manually decide whether to create a new dataset or add files to an existing one.

     

  3. 03

     Select a configuration or dataset Manually choose the target. And the system evaluates schema compatibility and displays a compatibility percentage.

     

  4. 04

     Add more compatible files to import Select additional files that match the reference schema to import along with the reference file.

     

  5. 05

     Resolve schema mismatches and complete the import If files don't match the expected schema, resolve discrepancies before proceeding. This step will be skipped when no mismatches are found. Files are imported together as a new dataset or appended to an existing dataset.

     

  ---

  The turning point: The system's constraint was becoming the user's task.

  To test the direction despite limited access to external users, I proposed and facilitated two internal workshops with 20+ participants, supplemented by feedback from two internal customer proxies and one key customer.

  Two issues stood out:

  • The reference-file step felt disconnected from the goal. Users wanted to import a group of files, not figure out why they had to start with one.
  • Users valued the flexibility to create or append datasets, but navigating often many configurations and existing datasets felt difficult to choose the right path and configuration.

  The lesson wasn't to remove the technical safeguards. It was to stop making users responsible for managing them.

  03 Move the complexity into the system, not the user's task.

  Keep the safeguards, rethink who does the work: Start with the user’s goal; let the system handle the rules

  I brought the findings back to R&D and explored alternatives with Engineering. We shifted from a reference-file-first interaction to a multi-file workflow that handled compatibility and dataset decisions within the system.

  

  ---

  Redesigned workflow: A dynamic, branching flow that starts with multi-file upload and adapts to the selected files, available configurations, and user choices.

  1. 01

     Select multiple file Users start with the complete group they want to import.

     

  2. 02

     Automatically validate and recommend The system checks schema compatibility, identifies a suitable configuration, and guides users toward creating a new dataset or appending to an existing one.

     

  3. 03

     Resolve only when needed If schema mismatches exist, the workflow surfaces them and guides resolution. If files are compatible, users skip the extra step.

     

  4. 04

     Import organized data Files are imported together as a new dataset or appended to an existing dataset. Related files are grouped into a dataset ready for compliance analysis.

     

  04 One workflow improvement. A pattern the product suite could reuse.

  Designing beyond the feature meant thinking beyond one screen.

  The new workflow introduced branching decisions that could apply to other complex experiences across the product suite.

  I partnered with the Design System and GUI teams to establish a reusable UI pattern for those decision points. The pattern was incorporated into the design system and adopted across multiple applications.

  • 
  • 

  That extended the work from solving one import problem to improving how the wizards in broader product suite handled complex scenarios.

  05 The outcome

  Less file management. More time for analysis and insight.

  1. 01

     24× faster imports: Reduced import time from over 2 hours to 5 minutes.
  2. 02

     Removed the need for customers to build custom solutions for batch imports.
  3. 03

     Enabled users to group and append related datasets leading to data organization and more accurate analysis
  4. 04

     The improvement contributed to retaining high-value customers and acquiring new enterprise customers.

  The bigger shift

  Users came to the product to analyze data for compliance—not to spend their time importing and managing hundreds of files. I helped move that complexity out of their way, while preserving the technical safeguards that made the analysis reliable.
• 

  • Product strategy
  • Design-in-code
  • 0 to 1

  Matching Tool

  Product Lead

  Fair and explainable by Design:

  How I turned a manual matching process into a rule-based engine that cut processing time by ~98%, and am leading its evolution into a platform with a dedicated team.

  

  • Internal Tool
  • Role: Product Lead
  • Duration: August 2026–present
  • Partners: HCI program executive, 4 UX designers, 2 UX researchers and 1 engineer

  • Internal Tool
  • Role: Product Lead
  • Duration: August 2026–present
  • Partners: HCI program executive, 4 UX designers, 2 UX researchers and 1 engineer

  The first mentor-matching cycle ran on the new engine and took ~98% less time than the manual process with over 95% alignment. Every match came with a score and a plain-English explanation, giving faculty a consistent starting point they could review, adjust, and approve.

  Status: Mentor-matching engine live; re-assign and re-run feature, capstone-matching and platform development underway

  01 The real problem wasn't matching. It was making matching repeatable.

  Two flagship programs. One process built around individual judgment.

  An HCI master's program relied on faculty to manually match people across two initiatives:

  1. 01

     Mentor Coalition: Pairing industry mentors with students based on their interests, expertise, and experience.
  2. 02

     Capstone: Assigning student teams to industry-sponsored projects based on preferences and project needs.

  Faculty brought valuable expertise to these decisions but reviewing intake forms and evaluating candidates took significant faculty time, time that could also go toward teaching, mentoring, and industry engagement. Without a shared method, decisions could also vary in how they were made and explained.

  As the program grew, three problems became harder to ignore:

  • Time: Matching required significant manual effort every cycle.
  • Consistency: Different faculty members could interpret the same information differently.
  • Explainability: There was no structured approach to show why a particular match had been made.

  ---

  The product opportunity

  Through a program-wide research, I saw an opportunity to build on faculty's expertise with a more efficient and consistent process. I framed the goal around supporting faculty judgment, not replacing it.

  How might we give faculty a consistent, explainable first draft of matches they can trust, adjust, and approve, without taking them out of the decision?

  That principle became the foundation for the matching engine: systematize the repeatable work, make the reasoning visible, and keep faculty in control.

  02 Start with the right problem, not the biggest platform.

  Prove the matching method before expanding the experience.

  The two programs shared a need for a more defined structure for matching, but their underlying problems were different. Mentor matching involved pairs, continuity, and mentor availability. Capstone matching involved teams, team composition, and project requirements.

  Building both at once would have increased complexity before the core approach had been proven.

  I wrote the product requirements document and phased roadmap, then aligned with program leadership on a sequence that delivered value early while leaving room to expand.

  1. Phase 1: Mentor matching engine: live

  2. Phase 2: Capstone matching engine: next

  3. Phase 3: Refinements after testing

  4. Phase 4: Self-service Platform: Authentication, direct intakes, privacy, and security.

  ---

  The trade-off: deliver value without creating avoidable risk.

  With the academic year's main mentor-matching round approaching, I deliberately kept the first release focused on the engine.

  I worked with faculty to define the rules, tested the engine with mock data, and collected structured student and mentor information through Google Forms. I then deployed it as a private, lightweight Streamlit app that accepted the existing intake data and returned scored, explainable matches.

  This avoided delaying the matching cycle for authentication, new data-collection flows, or a larger application build. It also reduced adoption friction while giving the matching approach a real-world test.

  I raised privacy and security considerations early so they could shape the platform roadmap rather than become late-stage blockers.

  03 The rules were the product.

  Turn expert judgment into a system people can inspect.

  The hardest part wasn't writing the code. It was making implicit decisions explicit.

  Faculty had developed practical ways to handle continuity, student priorities, mentor capacity, and experience levels. I worked with program executives to translate that expertise into a documented ruleset defining how the engine should make decisions—and in what order.

  The rules addressed questions such as:

  1. 01

     Continuity: Should existing pairs who want to continue stay together?
  2. 02

     Fair access: Should every mentee receive a mentor before anyone receives a second?
  3. 03

     Priority: Which students need to be placed first?
  4. 04

     Fit: How should shared interests and expertise affect a match?
  5. 05

     Transparency: Can faculty understand why the engine recommended a particular pair?

  I made scoring weights configurable so the program could tune priorities without changing the underlying logic.

  The documented ruleset became the source of truth. Changes could be discussed and tested against explicit criteria rather than relying on memory or undocumented assumptions.

  ---

  Why this mattered

  The rules were not merely implementation details. They defined the product's behavior, its boundaries, and the basis on which faculty could trust its recommendations.

  The key design decision was to make the logic understandable before making the interface more sophisticated.

  04 Iterate with mock data against the rules, not assumptions.

  Each round of testing made the engine more precise.

  I tested successive versions against mock data, using the results to refine scoring, account for program-specific requirements, and challenge assumptions about fairness. Each iteration helped close the gap between the initial rules and the realities of the matching process.

  Iteration	What changed	Why it mattered
  1. First draft	Eight rules agreed with program executives, scoring shared interests and experience	Put faculty judgment in writing for the first time
  2. Ranked inputs	Three ranked choices per person instead of one list; shared top choices score highest	A shared top priority now counts for more than a shared afterthought
  3. Clustering and taxonomy tuning	Related categories earn partial credit; clusters tuned after reviewing results	Weights and clusters were settings, so this was a config change, not a rebuild
  4. Program realities	New rules for year priority, pod groups and second mentors	Testing surfaced rules the first draft had missed
  5. Validation flags	Data checked before and after matching; each issue flagged as a blocker or a warning	Bad inputs get fixed by a person, not guessed by the tool

  6. Testing also exposed a more subtle issue.

  When multiple candidates received the same score, the engine used identifier order to break ties. That looked deterministic and neutral. But the order of identifiers had no meaningful relationship to match quality.

  The problem became more consequential in later rounds, when fewer mentor slots remained and multiple candidates were tied.

  The decision: deterministic does not automatically mean fair.

  I replaced the identifier-based tie-break with a three-step method:

  1. 01

     Compare match scores.
  2. 02

     Prioritize the person with fewer good alternatives.
  3. 03

     Use a fixed calculation unique to each pair to resolve remaining ties consistently.

  ---

  Make every result explainable.

  Each match includes a score and a plain-English reason, for example, shared interest in UX Research and a similar experience level.

  The engine also flags incomplete or contradictory inputs for human review. It doesn't silently treat a blank answer as a negative response or guess what a person meant.

  The result is a fully deterministic, inspectable process that faculty can check and override.

  I deliberately kept matching rule-based rather than using AI to make assignment decisions. With limited cohort history and no reliable outcome dataset, a learned model wasn't justified. AI could still assist with narrower tasks, such as suggesting a category for an “Other” response, with a person reviewing the suggestion.

  The principle: automate the repeatable work, expose the reasoning, and keep people accountable for the decision.

  05 Validate the engine in a real matching cycle .

  A strong first draft, with faculty still in control.

  The first live cycle put the engine to the test with real student and mentor data.

  More than 95% of the matches aligned with faculty expectations, and faculty made manual adjustments to two specific cases.

  The result validated the core matching approach: the engine could produce a useful, explainable first draft without requiring faculty to build every assignment manually.

  It also clarified the boundary between automation and human judgment. The engine could apply the agreed-upon rules consistently, but faculty sometimes knew something the intake forms couldn't capture—for example, when a particular pair should or shouldn't be matched.

  That wasn't a reason to make the initial engine more complicated. It was evidence for what the next iteration needed to support.

  ---

  The next iteration: pin and rerun.

  In the first release, faculty had to make adjustments in the exported spreadsheet. That took decisions outside the tool and separated them from the explanations and record of how the assignments were produced.

  I'm planning a pin-and-rerun capability to bring those decisions into the matching workflow:

  1. 01

     Pin or block a pair Assign two people together or prevent a match, with a reason recorded.
  2. 02

     Rerun the remaining assignments: Apply the same matching rules around those constraints.
  3. 03

     See what changed: Show which assignments moved after the rerun.
  4. 04

     Preserve the record: Keep faculty adjustments and their rationale alongside the matching results.

  This builds on existing engine behavior rather than requiring a redesign. The goal is to preserve consistency while giving faculty a way to account for context the data doesn't capture.

  06 Turn a proven engine into a platform around what the programs share.

  One platform. A separate module for each program.

  When it was time to plan capstone matching, the easiest option would have been to bolt it onto the existing mentor engine.

  I chose not to.

  The two programs shared foundational capabilities, but their rules were different enough that combining them into one tangled workflow could make the working mentor process harder to maintain.

  Starting from scratch would waste what had already been built.

  So I defined a modular direction: a shared core, with program-specific matching logic kept separate.

  Each program retains its own rules and constraints. Mentor matching can account for continuity and mentor capacity; capstone matching can handle team size, skill coverage, and project requirements.

  The goal is to reuse the right things without forcing fundamentally different problems into the same logic.

  Capstone matching is the next major expansion, with self-service intake planned for a later phase once privacy and security requirements are addressed.

  07 Lead the transition from a one-person MVP to a platform with dedicated team.

  From building the first version to enabling a team to evolve it.

  I built the first matching engine and faculty-facing app myself using Python, Streamlit, and Claude Code. That helped me move quickly from requirements to a working implementation and test the rules against concrete examples.

  As the project moved beyond the initial engine, I brought four UX designers, two UX researchers, and one engineer into the work and took on responsibility for leading the platform's evolution.

  ---

  I focused on three things:

  1. 01

     Architecture: Keep the matching engine self-contained, so the interface can evolve without changing the core matching logic.
  2. 02

     Team alignment: Onboard the team to the problem, documented rules, and reasoning behind key decisions.
  3. 03

     Product direction: Translate program priorities into a phased roadmap, making trade-offs visible to stakeholders.

  My role evolved from building the product to leading the system around it: the team, the roadmap, the rules, and the decisions that let it scale.

  08 The first phase delivered. The platform is still evolving.

  A measurable result, and a foundation for what comes next.

  The mentor-matching engine ran in a real matching cycle, giving the project an outcome beyond prototype validation.

  1. 01

     ~98% less time spent matching The first real cycle took ~98% less time than the manual process.
  2. 02

     Over 95% alignment The first live cycle's matches aligned with faculty expectations at a rate above 95%; faculty manually adjusted two edge cases.
  3. 03

     Explainable recommendations Every match includes a score and a plain-English reason that faculty can review.
  4. 04

     Fairer, repeatable decisions Removed identifier-order tie-breaking and documented the logic so results can be tested consistently.
  5. 05

     A foundation for the next phase A validated mentor engine, a defined platform direction, and a team to continue the work.

  ---

  What's next

  The next stage is to extend the approach to capstone assignments, complete the platform's new front end, and introduce self-service intake when privacy and security requirements are met.

  Over time, post-cycle satisfaction feedback can help the program evaluate whether the matches are working well and inform future adjustments to scoring weights.

  Those are future milestones, not outcomes I claim for the current phase.

  ---

  The mentor matching engine is the first proof point. The larger goal is a platform that helps the program make consistent, explainable matching decisions for both flagship programs: mentor coalition and capstone, and supports the relationships that continue long after a match is made.
• Coming soon

  Lab Management

  Lead Product Designer
• Coming soon

  Trip Planning | Booking

  Founding Designer
• Coming soon

  Walk-sharing Delivery

  Founding Designer
• Coming soon

  Story of My Website

  Web Designer | Developer