INTRODUCTION

Welcome to my product case studies! In general, the studies highlighted, follow the process outlined in this section. For various reasons, some follow this process more strictly than others. Due to legal restrictions, I am not able to provide visuals of the entire process but I have tried to describe as best I can the thinking that went into each case study. I also provide summaries for those wanting to quickly skim through the material.

Design process generally used in each study:

• Define the problem: I, along with my team members, began by trying to clearly articulate the problem we were solving and why it mattered.
• Understand the users and context: We identified who the users were, what they were trying to accomplish, and how they currently used the product. We gathered insights through stakeholder interviews (sales, support, customer success, leadership), user analytics tools (e.g., FullStory, Canny, Sigma, Airtable), in-app surveys, and by creating journey maps.
• Conduct discovery and competitive research: We then explored how other products solve similar problems. We documented patterns, ideas, and inspiration using reference collections and mood boards, including competitive product walkthroughs and demos.
• Design low-fidelity solutions: After the discovery phase, we created sketches and wireframes that addressed key use cases. We then reviewed these wireframes with product team members and technical leads, ensuring alignment with company heuristics and design systems.

• Iterate and test: We would then validate our designs through user testing using wireframes, high-fidelity mockups, or clickable prototypes, and then we refined our mockups based on the feedback we received.
• Align with stakeholders: Once we had a clearer understanding of what was working and what wasn't in the designs, we presented refined designs to key stakeholders, incorporated their feedback, and finalized the designs for development.
• Prepare for development: Product designers on my teams frequently created JIRA tickets and documentation to guide implementation, including developer-ready design references.
• Support implementation: Throughout the development phase, we collaborated closely with developers during sprints to ensure designs were implemented as intended and the final code met the original goals.
• Product test: For bigger projects we would release the updated product to a limited group of users external to the business where usability feedback could be gathered, functionality was tested, and bugs were identified and fixed.
• Measure the results: Once code was deployed, we would measure the results through in-app surveys, analytics tools, and follow-up interviews. This was done to measure how users responded to the updated product and so we could incorporate our findings in future road map considerations.



Here are the case studies:

GoReact Library

Summary

• Problem: The existing library was confusing, inefficient, hard to organize, and lacked reliable sharing and search.
• Goal: Create an intuitive, easy-to-navigate library for storing, finding, sharing, and reusing content.
• Role: Product designer responsible for redesigning the library.
• Process: Reviewed user feedback, collaborated with product and engineering, iterated from wireframes to tested high-fidelity designs. Also, since GoReact is a progressive web application (PWA), all designs took into account desktop and mobile views.
• Outcome: A centralized, powerful library that supports easy organization, reuse, sharing, and cross-account content management.

What was the problem to be solved?

GoReact is a video assessment and feedback application that was built to help learners master skills. Along with video recording and video assessment tools, the GoReact application provides a library which serves as a central hub to manage and organize video content and learning resources. Users can store, access, reuse, and share videos across courses and assignments without re-uploading content. The old library was confusing and didn’t function efficiently. Organizing files was difficult, sharing saved media with others didn’t always work properly, and there was no search capability making it hard for users to find files. Our product team wanted to make the library easy to navigate, easy to share files with others, and a useful place to save documents which could be re-used as many times as the user desired.

What was my role on the project?

I was the product designer assigned to reimagine and redesign the library.

What was my design process?

The project started with an analysis of the old library. We looked at what was not functioning and then had to decide what we wanted the ideal library to do. We did this by looking at issues that had been submitted by users to our support team and by conversations in-house employees had with various clients. Once we had a fairly clear picture of what we wanted the library to do, I began to create wireframes that I could show the product manager responsible for the project as well as to our lead developer who could give us insight into the technical limitations of the project.

We iterated on these concepts until we felt like we had worked through the primary personas, their user journeys, and had come up with a good solution from which I could then create high fidelity mockups to test with users and to present to other key stakeholders in the business. After these presentations were completed, we again iterated on the results of our user testing and key stakeholder feedback. Once the final mockups were created our product manager could write up JIRA tickets for the developers to work on. Since GoReact is also a progressive web app that allows the developers to have a single code base for the desktop version as well as the mobile version, all designs took into account desktop and mobile views.

What was the outcome of the project?

The outcome of the project was a feature inside of GoReact that allowed users to have a central location to manage and organize their video content and learning resources. Over time the library has become one of the most powerful areas of the application where users not only store, access, reuse, and share their videos across courses and assignments without re-uploading content but are also able to create reusable templates and connect content across multiple personal and organizational accounts.

Summary

• Problem: The product failed to meet WCAG and higher-education/government accessibility requirements.
• Goal: Achieve verified accessibility compliance across the application.
• Role: UX designer leading accessibility design solutions.
• Process: Applied WCAG standards, redesigned and tested accessible interactions, and iterated through audit feedback with engineering. All designs took into account desktop and mobile views.
• Outcome: Reached compliance, established company-wide accessibility standards, and unlocked additional higher-education contracts.

GoReact Payment/License Side Panel

Summary

• Problem: Learners had no way to pay in-app, relying on manual and unscalable payment methods.
• Goal: Create a simple, reliable in-app payment flow for learners.
• Role: UX designer leading the in-app payment experience design.
• Process: Researched payment patterns, designed and tested wireframes and mockups, collaborated cross-functionally, and released incrementally with analytics. All designs took into account desktop and mobile views.
• Outcome: Launched self-serve in-app payments, reducing sales friction and enabling future licensing features.

What was the problem to be solved?

GoReact did not have a way in the application for learners to pay for the product. It was free for instructors to use but once learners were invited to the product they had to use a code given to them at a bookstore or contact an in-house team that would handle payment for use of the product. This was not a scalable situation and the business wanted to figure out how to allow learners to pay for the product as they created their accounts.

What was my role on the project?

I was the UX designer responsible for figuring out how to bring users through the in-app payment process.

What was my design process?

I first had to understand how in-app payment worked in other applications and how those concepts could translate to GoReact’s situation. After researching several different applications online and applications our business had licenses for, I then began to draw out concepts on paper and translated those to wireframes. Since I was also the product manager at the time, I had another product manager and the technical lead of the project review these wireframe concepts with me and then we began to test them with different users. This was done through interviews using Zoom and Google Meet. After about 10 interviews we had a fairly good idea of concepts that were working and concepts that were not. I iterated on the wireframes and began creating higher definition mockups to show our internal stakeholders.

With a few iterations of the higher definition mockups and after consulting with the internal stakeholders we were ready for the project to go into production. I wrote up the JIRA tickets and the work began with the developers. We withheld the feature from our users until we felt we had all of the concepts in place and we had thoroughly tested the payment form. The correct functioning of this feature was particularly important since it dealt with financial transactions. When we released the feature we did so only to a small number of users so that we could make sure all of the payment processing worked as intended. Our company had daily deployments and weekly sprints which allowed us to pivot very quickly when we released features because we could see through the use of Fullstory, an analytics application to help teams understand user behavior, and through follow up interviews, how users were interacting with the feature. When we felt the payment form consistently performed as it should with our small test group, the feature was then released to our entire user base.

What was the outcome of the project?

GoReact, the business, was thrilled to have a way for learners to sign up and pay for the product without having to contact the sales team. The ability for users to pay for the application as they used it paved the way for implementing licensing through the application as well. 

Summary

• Problem: The team lacked a direct way to understand user sentiment and feedback at scale.
• Goal: Capture real-time, in-app user feedback with minimal disruption.
• Role: Product designer responsible for survey design, categorization, and analytics integration.
• Process: Designed a simple modal, defined feedback topics, tuned survey cadence, and connected responses to Airtable, Sigma, Slack, and Fullstory. All designs took into account desktop and mobile views.
• Outcome: Delivered continuous, actionable user insights that informed faster and better product decisions.

What was the problem to be solved?

The product team at GoReact was finding it difficult to know how our users felt about the product and what ideas they might have to improve it. We used another application called Fullstory to gain insight into our users' journeys through GoReact and we had users communicating with our support team through Zendesk but we still didn’t have a good way for the product team to directly communicate how our users felt about the product. We decided the best way to allow our users to communicate how they felt, was to display a modal with an in-app rating scale and an open ended question asking our users how we could improve our product.

What was my role on the project?

I was the product designer responsible for designing the in-app survey and worked closely with one of our product managers to integrate the survey responses with Airtable, a cloud-based spreadsheet/database and Sigma, a cloud-based business intelligence and analytics platform that could help us visualize the data through charts and graphs. I was also responsible for generating a list of topics that we could use to categorize the user responses being generated from our open ended question. These topics would allow us to see which areas of the application users were struggling with and give us a searchable database that we could filter to see all responses related to a specific topic.

What was my design process?

Since the modal was a relatively simple part of our application, the design of it followed other modal patterns in our product and didn’t require major UI design work. Where most of the product design work was focused, was thinking through how to categorize the open ended responses we would get from the question we were asking. We wanted the question to allow for a wide range of responses so we could capture the sentiment of the user in a particular moment. We weren’t trying to capture a net promoter score, we were trying to gauge how the user felt in the moment and give the user an opportunity to share ideas they might have on how to improve the product. We decided the best way to categorize the open ended responses was to allow the modal to appear in the product and collect several hundred responses. The modal appeared once the user entered the feedback panel of our product after a certain number of times. We didn’t want the modal to appear too many times so it annoyed the user but we also didn’t want it to appear too few times so that we would miss out on how the user felt about the product at a particular time.

We would adjust the cadence as we started getting feedback and we eventually landed on a particular cadence that seemed to give us the quantity of data we were wanting but not be too annoying to the user. Initially I would manually categorize the data but we eventually had enough topics that we could instruct an AI assistant in Airtable to look for the topics for us. Topics that came up that didn’t fit what we already had were not labeled by the AI and gave us a chance to review them and either manually assign a category or create a new category. We also spot checked the AI’s categorization just to make sure it was categorizing the responses correctly. We had to adjust the prompt we gave the AI a few times to get it to function as we wanted but eventually it was categorizing the open responses in a fairly accurate manner. The data gathered in Airtable was also fed to Sigma, a visualization tool, which allowed us to see through a series of charts the percentage of users whose responses fell into a specific category. The categories with the highest percentage and the lowest number of stars were the ones we mostly focused on to determine which areas of the application needed the product team’s attention. We also fed this data to a Slack channel which would alert us when a new open ended response was given in the application. This channel also captured the Fullstory link so in the moment the response came in, we could immediately replay the user journey and experience that had been captured by Fullstory. This would allow us to immediately see what the user was struggling with and therefore allow us to create JIRA tickets in a timely manner to fix the problem if we determined the problem was something we could fix quickly.

What was the outcome of the project?

This project gave us incredible insight into the day to day sentiments and experiences of our users. Granted it was only looking at users who were courageous enough to leave us a response but this was at least better than only communicating with users who allowed us to interview them or test them. It greatly increased the pool of users we were hearing from in a way that was relatively non-intrusive and could be done when it was convenient for the user. 

Summary

• Problem: RainFocus needed client-ready visuals to explore embedded attendee data experiences.
• Goal: Design modular, customizable attendee pages for event managers.
• Role: Designer translating sales and leadership concepts into high-fidelity visuals.
• Process: Collaborated on concepts and created mockups in Illustrator and Photoshop.
• Outcome: Supported successful pitches that led to ongoing work with Oracle and Cisco.

Summary

• Problem: Event managers lacked a flexible way to create and share structured event information.
• Goal: Design a tool to build custom collections and embed them via HTML/JavaScript.
• Role: UX designer defining and designing the collection tool for internal service teams.
• Process: Collaborated cross-functionally, iterated through sketches and wireframes, and delivered high-fidelity desktop designs in Adobe XD.
• Outcome: Provided a complete design for development; final results were not observed due to timing.

Summary

• Problem: The service team relied on developers to create forms, catalogs, and registration pages.
• Goal: Enable the team to build embeddable forms and pages without developer support.
• Role: UX designer designing the widget builder tool.
• Process: Iterated with service, product, and engineering teams and produced high-fidelity designs in Adobe Muse.
• Outcome: Enabled a WYSIWYG form builder that significantly sped up page and catalog creation.

Summary

• Problem: Exhibitors had no way to order lead retrieval devices or preset questions.
• Goal: Create a simple, efficient device and question ordering flow.
• Role: Lead UX designer partnering with the lead retrieval manager.
• Process: Designed wireframes from first principles, gathered service-team feedback, and delivered a high-fidelity prototype.
• Outcome: Enabled streamlined ordering and established lead retrieval as a key RainFocus service.