involveMINT
involveMINT
involveMINT

Overview
Overview
Overview
I worked in a team of seven students to create a chat-coordination feature for involveMINT, a nonprofit servicing a community barter network in Pennsylvania.
I worked in a team of seven students to create a chat-coordination feature for involveMINT, a nonprofit servicing a community barter network in Pennsylvania.
Timeline:
Oct 2025 - Feb 2026
Timeline:
Oct 2025 - Feb 2026
Role:
Product Designer
Role:
Product Designer
Team:
5 Designers
1 Product Manager
1 Design Manager
2 Stakeholders
Team:
5 Designers
1 Product Manager
1 Design Manager
2 Stakeholders
Skills:
Usability Testing
Systems Thinking
Data Synthesis & Analysis
Audience:
Small business owners in Pennsylvania
Skills:
Usability Testing
Systems Thinking
Data Synthesis & Analysis
Skills:
Usability Testing
Systems Thinking
Data Synthesis & Analysis
Audience:
Small business owners in Pennsylvania
Audience:
Small business owners in Pennsylvania
Discovery
Discovery
Competitive Analysis
Competitive Analysis
Descoping Features
Descoping Features
Solution: Order Form
Solution: Order Form
User Testing
User Testing
Final Product
Final Product
Project Limitations
Project Limitations
Reflection
Reflection
DISCOVERY
DISCOVERY
The main goal: design a solution to boost transaction conversion rates and lower decision fatigue
The main goal: design a solution to boost transaction conversion rates and lower decision fatigue
The main goal: design a solution to boost transaction conversion rates and lower decision fatigue

involveMINT aims to build a community within their user base through the use of product trades and internal credits. However, they noticed many B2B exchanges weren't being fulfilled due to the lack of communication structure; it was difficult getting from discovering a product to purchasing/exchanging because users didn't know how to start a conversation or what to do next.
Our client proposed we design messaging templates, quick action buttons, and in-chat context banners to develop the needed supporting framework.
involveMINT aims to build a community within their user base through the use of product trades and internal credits. However, they noticed many B2B exchanges weren't being fulfilled due to the lack of communication structure; it was difficult getting from discovering a product to purchasing/exchanging because users didn't know how to start a conversation or what to do next.
Our client proposed we design messaging templates, quick action buttons, and in-chat context banners to develop the needed supporting framework.
COMPETITIVE ANALYSIS
COMPETITIVE ANALYSIS
Structured communication may not mean typical chatroom-style messaging–it could look like a step-by-step form
Structured communication may not mean typical chatroom-style messaging–it could look like a step-by-step form
Structured communication may not mean typical chatroom-style messaging–it could look like a step-by-step form

In Simbi, a fellow bartering company, the uncertainty of starting and maintaining messaging threads is eliminated from the start. They effectively use CTAs like dropdowns, numerical input fields, and calendar pickers to send one, cohesive inquiry message describing what needs to be done, when, and for how much. This guidance and specificity is what involveMINT users seek.
In Simbi, a fellow bartering company, the uncertainty of starting and maintaining messaging threads is eliminated from the start. They effectively use CTAs like dropdowns, numerical input fields, and calendar pickers to send one, cohesive inquiry message describing what needs to be done, when, and for how much. This guidance and specificity is what involveMINT users seek.
DESCOPING FEATURES
DESCOPING FEATURES
Prioritizing people-first language over formal business formalities; and understanding current system capabilities
Prioritizing people-first language over formal business formalities; and understanding current system capabilities
Prioritizing people-first language over formal business formalities; and understanding current system capabilities
QUICK ACTION BUTTONS
QUICK ACTION BUTTONS

Our original scope included buttons to efficiently accept an inquiry, counter a price, or decline entirely–but we found this was too formal, hindering that sense of community involveMINT wants to emphasize.
Our original scope included buttons to efficiently accept an inquiry, counter a price, or decline entirely–but we found this was too formal, hindering that sense of community involveMINT wants to emphasize.
REACHING AN AGREEMENT THROUGH SYSTEM DETECTION
REACHING AN AGREEMENT THROUGH SYSTEM DETECTION

To complete coordination, both businesses must come to terms to unlock the "Start Transaction" button–but how does the system know both parties came to consensus? Assuming it detected agreement phrases like “Sounds good,” I created a toast pop-up where users can confirm agreement. However my client noted this isn’t within their system’s capabilities, and may also sustain pain points since there’s still a heavy reliance on back-and-forth messaging with no structure.
To complete coordination, both businesses must come to terms to unlock the "Start Transaction" button–but how does the system know both parties came to consensus? Assuming it detected agreement phrases like “Sounds good,” I created a toast pop-up where users can confirm agreement. However my client noted this isn’t within their system’s capabilities, and may also sustain pain points since there’s still a heavy reliance on back-and-forth messaging with no structure.
SOLUTION: ORDER FORM
SOLUTION: ORDER FORM
Eliminating decision fatigue by introducing step-by-step guidance and structure
Eliminating decision fatigue by introducing step-by-step guidance and structure
Eliminating decision fatigue by introducing step-by-step guidance and structure
System detection turns into system matching: both parties select their desired products/services, fulfillment methods, and availability on an Order Form and submits to involveMINT’s system. It detects overlap and crafts a finalized agreement so both parties reach the Transaction phase more efficiently.
System detection turns into system matching: both parties select their desired products/services, fulfillment methods, and availability on an Order Form and submits to involveMINT’s system. It detects overlap and crafts a finalized agreement so both parties reach the Transaction phase more efficiently.
PRODUCTS/SERVICE
PRODUCTS/SERVICE

Initially, I thought only Buyers would submit an Order Form, but in order to engage in system matching both parties need their own–hence why the Seller POV iterations start in V2. Throughout revisions, I reduced the number of required inputs, primarily relying on the system to prepopulate information based on earlier userflow steps (i.e sending an Inquiry populates product/service name) making the Order Form completion seamless.
Initially, I thought only Buyers would submit an Order Form, but in order to engage in system matching both parties need their own–hence why the Seller POV iterations start in V2. Throughout revisions, I reduced the number of required inputs, primarily relying on the system to prepopulate information based on earlier userflow steps (i.e sending an Inquiry populates product/service name) making the Order Form completion seamless.
FULFILLMENT METHOD
FULFILLMENT METHOD

I updated this section title multiple times as “Delivery” and “Exchange Method” clashed with the provided options. Similarly, the option names changed to ensure they’re explicit, mutually exclusive, and follow how involveMINT currently handles fulfillments.
I updated this section title multiple times as “Delivery” and “Exchange Method” clashed with the provided options. Similarly, the option names changed to ensure they’re explicit, mutually exclusive, and follow how involveMINT currently handles fulfillments.
AVAILABILITY
AVAILABILITY

V1 and V2 fail to support system matching, and still rely on both parties to confirm a specific timeframe through messaging. I transitioned to using a calendar and time picker in V3 for more direct manipulation and structure; I also updated the time picker in V4 to account for gaps within time ranges and reduce vertical scroll.
V1 and V2 fail to support system matching, and still rely on both parties to confirm a specific timeframe through messaging. I transitioned to using a calendar and time picker in V3 for more direct manipulation and structure; I also updated the time picker in V4 to account for gaps within time ranges and reduce vertical scroll.
SAVING PREFERENCES FOR FUTURE ORDERS
SAVING PREFERENCES FOR FUTURE ORDERS

My client noted these Order Forms double as an incentive for users to save their "Fulfillment Method” and “Availability” preferences to their profile, so that future forms can be prepopulated with this information. Thus I added these screens right before users submit the forms for matching.
My client noted these Order Forms double as an incentive for users to save their "Fulfillment Method” and “Availability” preferences to their profile, so that future forms can be prepopulated with this information. Thus I added these screens right before users submit the forms for matching.
USER TESTING
USER TESTING
Tab switching and ambiguous CTAs stumped users when filling out the Availability Picker
Tab switching and ambiguous CTAs stumped users when filling out the Availability Picker
Tab switching and ambiguous CTAs stumped users when filling out the Availability Picker
We conducted one round of online usability tests via Usertesting.com with five US business owners experienced with barter/credit platforms.
We conducted one round of online usability tests via Usertesting.com with five US business owners experienced with barter/credit platforms.

In V2, users found tab switching unclear, leading to frustration because they were unable to add a time range. Moreover, for users to confirm this time range, I intended for them to press the black checkmark–however all five users overlooked this. So in V3, I eliminated the tabs and added a larger “Save” button for better CTA communication.
I also updated the “Date” tab, originally holding the calendar picker, to “Days” with clickable pills. This transition from specific dates to general windows allows the system to easily save availability preferences and prepopulate future Order Forms.
In V2, users found tab switching unclear, leading to frustration because they were unable to add a time range. Moreover, for users to confirm this time range, I intended for them to press the black checkmark–however all five users overlooked this. So in V3, I eliminated the tabs and added a larger “Save” button for better CTA communication.
I also updated the “Date” tab, originally holding the calendar picker, to “Days” with clickable pills. This transition from specific dates to general windows allows the system to easily save availability preferences and prepopulate future Order Forms.
FINAL PRODUCT
FINAL PRODUCT
An example where a Buyer fills out their Order Form, submits it to the system for matching, and successfully reaches the transaction phase
An example where a Buyer fills out their Order Form, submits it to the system for matching, and successfully reaches the transaction phase
An example where a Buyer fills out their Order Form, submits it to the system for matching, and successfully reaches the transaction phase

PROJECT LIMITATIONS
PROJECT LIMITATIONS
Designing foundational frames for alternative scenarios and use cases
Designing foundational frames for alternative scenarios and use cases
Designing foundational frames for alternative scenarios and use cases

Given time constraints, I focused solely on one case scenario: In-Person (Storefront) for the Fulfillment Method, and an idealistic overlap match with no disagreements. While I chose to prioritize building out one, concise flow rather than flushing all edge cases out, I created base designs for alternative scenarios like different Fulfillment Methods, match failure, and smart chat templates for future designers to further develop.
Given time constraints, I focused solely on one case scenario: In-Person (Storefront) for the Fulfillment Method, and an idealistic overlap match with no disagreements. While I chose to prioritize building out one, concise flow rather than flushing all edge cases out, I created base designs for alternative scenarios like different Fulfillment Methods, match failure, and smart chat templates for future designers to further develop.
REFLECTION
REFLECTION
This was definitely one of the more complex product design projects I’ve worked on!
This was definitely one of the more complex product design projects I’ve worked on!
This was definitely one of the more complex product design projects I’ve worked on!
There were so many system logistics, edge cases, and conditionals to think about. Prior to this, I would only focus on surface level complications like cosmetics or aesthetics but this pressed me to really think about how my designs will translate on the backend. It was difficult, but rewarding in the sense that I was pushed out of my comfort zone and learned a lot. I definitely have a heightened level of respect for those who design and develop market-focused products--it's truly no easy feat!
There were so many system logistics, edge cases, and conditionals to think about. Prior to this, I would only focus on surface level complications like cosmetics or aesthetics but this pressed me to really think about how my designs will translate on the backend. It was difficult, but rewarding in the sense that I was pushed out of my comfort zone and learned a lot. I definitely have a heightened level of respect for those who design and develop market-focused products--it's truly no easy feat!




