Role: Sole & Founding Lead Product Designer, designed entire platform, managed strategizing with business side/stakeholders and building hand-in-hand with the engineering team. This project was a big step in responsibility for me, learned a ton in every aspect of creating a product from scratch.

Duration: 2 Years (October 2021 - August 2023)

Grapes provides a cross-border payment solution in a highly secure, compliant and low-cost pathway. Canadian users can utilize Grapes to leverage instant settlements and payment facilitations directly to their bank accounts or digital wallets without 3rd party intermediaries, extraneous FX and on/off ramp costs. Grapes is growing to be the preeminent cross-border payment solution for Canadians and businesses all across Canada, partnering with leading businesses in the industry and already transacting multiple millions for customers through the Grapes Finance platform.

Back in November 2021. Stablecorp, a sister company to Mavennet approached us with an idea and PRD to bring a new solution for Canadians and businesses to relocate and transfer their fiat dollars from traditional banking methods. At the start, Grapes’ core mission was to provide Canadian customers (individuals, merchants and other partners) with a platform (the Grapes platform) to swap their fiat (CAD/USD dollars) into QCAD (Canadian Stablecoin) which allowed these customers to quickly link to an array of other partner platforms and use cases.

This project was something completely new to the Canadian fintech space. Nothing had ever been done like this at the time, closest being Circle (Creators of USDC, the American Stablecoin).

To begin, we (PM, Design Lead (me) & Lead Developer) had a few meetings to first align our objectives, milestones, process and estimated timelines for the project. On the design side I broke out the timeline into the following:

Keep in mind, the objectives to these timelines never go the way anyone estimates too. It’s just something we try to project to happen but in reality, a project always has its ups and downs throughout the entire process.

I wanted to spend the better half of our timeline to conduct research to get an understanding of the product, business model, market and complete a series of interviews with the stakeholders/awaiting customers to gain insight on what they are looking for from this product. This was an important step, it helped pave the way to our design thinking and strategy, reduced questions we had and redundancy of iterations throughout the project.

To establish these findings, I setup a document where I displayed the data we were able to gather through quantitative surveys, interviews done with stakeholders/potential users of interest and a competitive analysis between the similar products (ones that were in the finance niche) to understand the industry standards and so we can gain valuable data to reflect over.

Throughout all this research I was able to discover a ton which lead us to have a great starting point and opportunity areas on where we can establish our product.

Now that we had defined what needed to be done, we had our foundation. From here I broke down the information and built user stories to layout what the most necessary features we would need for a soft launch. Through that process, I was able to build out user flows as well on how each epic should flow when a user is interacting with them.

After showcasing this to the stakeholders and PM, making iterations and filling other requirements needed till the approved, we got the greenlight to start building & designing.

I started off with brainstorming and sketching, which transitioned into lo-fi wireframes. The goal was to create 1-2 low-fi wireframes of the user flows every sprint, then connect with Stakeholders/PM, review and reiterate if needed and finalize the wireframe. Though some sprints would fall into others due to unseen circumstances, this process made the workflow as efficient as possible to stay on track with our timelines.

While this was happening, I was also communicating with the developers so they are able to start building the product infrastructure by using our user flows and stories.

When designing the product the main goal was simple, we wanted to buildout a product for our users to interact with as if they were using any other financial product. I didn’t want to change that feeling because given the complications actually behind each flow, the last thing we would want is the user to feel lost or confused, this application should feel like second nature.

We achieved this using the competitive analysis data we had previously gathered and looking into the goods we learned from and pain points we can improve with our product.

Behind the scenes, I was also building out the design system to place layover our product. This included items such as; typography systems, colour systems, spacing/grids, accessibility standards, documentations, models, tooltips, etc. (Design tokens came in the future due time constraints)

Once all the wireframes were done, I began creating a finalized prototype file for each flow for our stakeholders, potential users and others to test, then to find and nit pick every issue in the flow possible. By doing it this way, we’re able to catch onto to issues early and fix them quickly rather than during development where fixing an issue can take 50-60% more time vs addressing the issue on the Figma prototype.

More in-detail on how we approached user testing in the next paragraph.

For testing, I created a Figma file with each user story prototype on its own page. Given the timeframe and small user tester pool (Stakeholders didn’t feel comfortable using outsourced user testing without NDAs, this would’ve taken time we didn’t have) We tested with 1 stakeholder + 3 employees and 2-3 potential trusted customers. I created multiple user-flow/task scripts and gave them to each individual randomized.

I then would sit in a recorded call with the user sharing their screens as they went through each tasks, doing this helped us document where each user felt lost, view where their curser naturally moved too, and gather other information on how we can improve our product. After every testing round we would discuss and layout the found issues and give each one a severity rating. By doing this we were able to prioritize which issues would need the highest attention to be fixed and which were also feasible with our timeframe.

After each round, we would re-test with a different pool of user testers (internally) where we made substantial improvements and continued doing so till the product was flowing as perfect as we can get it too.

Final steps! Here I try to make the developers lives as easy as possible and to not cause any blockers or hiccups for them due to neglect from a designer to hand off incorrectly, I come from a software background so I have a soft spot for developers (I understand the frustrations!!!)

I provide the developers with the following;

Grapes is passed beta and now a public product used by clients and businesses all around Canada, they continue to raise more funding and innovate the product to meet customers needs everyday. Grapes is the pioneer to stablecoins in Canada, transacting multiple millions in CAD/USD dollar every year. Supporting all its users, Grapes is now looking to extend its platform to other countries and stablecoins around the world!

As I’m typing this Grapes is now on as we like to call it, on Version v1.2. and on-going to v1.3 updates. Since the original launch we have added several more features and the product continue to grow everyday. We still build with our principle process, continues to work like a charm. None of this would be possible with an amazing hard working supportive team behind it all, Stablecorp & Mavennet!

Want to see how we built Grapes Vineyard (Design System)? click here