Shortly after I started at Gemini as the first UX hire, I jumped into a new initiative to create a native mobile version of our web offerings. Before I had joined, Gemini was working with an external agency to build an MVP—initially I would be an internal resource as I onboarded fully. The agency had a few screens, and key “hero flows”, but not much foundation as far as information architecture or interaction design. One of the first things I did was to establish the transition from pitching concepts to designing for function by stepping back from the screens and focusing on the system we were building.

At this stage, I partnered with our new product manager and one of our front end developers to scope out the project using the IA document as our foundation. We then defined the requirements for key flows that hadn’t been addressed by the agency, starting with the buy flow experience. The initial deadline for this project was Thanksgiving, which meant working quickly and iteratively with the aim of providing functional chunks so that the agency developers could move forward without being blocked.

One of the biggest hurdles to clear was how to manage our onboarding process and Plaid integration. Plaid’s API would allow us to make the purchasing flow more seamless, but it also helped us with our comprehensive Know Your Customer/ Anti-money laundering checks. Since Gemini is a regulated Trust company in a generally mistrusted space, our risk and compliance standards are equivalent to that of a bank. However, uploading an ID to use our mobile app provided a lot of friction. Our Product Manager proposed the concept of a tiered onboarding structure to limit sign up friction while still limiting our exposure to risk.

Luckily, once the UX foundations, onboarding flows, and app wireframes were in a good place, we had another two more designers start at Gemini. Our visual designers established the new mobile design system, and I worked closely with the agency around any additional documentation and deliverables we would need to iterate.

At this time, I was also managing our internal product backlog, creating scripts for user testing, and creating comprehensive documentation (down to the specific page elements and mixpanel event types) for our developers to implement mixpanel tracking.

Unfortunately it became clear we weren’t going to make our Thanksgiving deadline. In order to launch a functional MVP as quickly as possible, we brought everything in house working nights and some weekends to get this done.

Although we wouldn’t be implementing the pay functionality at that time, I saw this as an opportunity to establish a mobile product strategy. I created a deck explaining what a strategy might look like, and why it makes sense for mobile, now. To collaborate with product managers and mobile development partners, I outlined how a User Experience Strategy consists of four components:

1. Business Strategy

2. Value Innovation

3. Validated User Research

4. Great UX

Before moving forward with new features, we were at a point where it would benefit us greatly to establish an extensible structure in order to evolve without having to rebuild. I explained that a two-track process would allow us to move forward in a low-risk way, while exploring innovative, valuable vision states.

While we were in the process of defining the business strategy for our mobile platform and ramping up ux research to define value innovation, we had a validated backlog to leverage in the short term. This primarily consisted of updating the architecture and usability issues based on previous internal testing and user experience backlog:

• Split between creation and management for alerts and recurring buys is confusing

• More info for cryptoverse, how the market weight is determined, what the lines mean, what you actually get

• Users want to go to "my portfolio" to view and act on (withdraw) their balances

• Tool tip on buying power (what it is, how to increase, etc) needed

• People are generally confused and overwhelmed by "my account", expect it to be administrative only

• Currency specific transaction history, or an easier way to review

• Chart interaction, and comparison with past

This shorter term iterative approach would also gave our visual design team designated time to explore an updated look and feel of the mobile app.

After mobile v2 and a few other initiatives, Flexa came up again as a product initiative. Before the mobile v2 launch, I had worked closely with our creative director to translate our dashboard concept sketches into a functional testing ground for this new product. I wanted to find a way to incorporate “pay” while exploring user insights and other experience enhancements. Still, the biggest question for me was around the use case. As a user, why use Gemini pay? The real advantage is for the massively reduced transaction fees for merchants. One of the goals was to figure out how to design with potential use cases in mind.

Fast forward to January and Gemini Pay is back on!

I walked our new PM and visual designer through the previous iterations and requirements, outlining reasons why specific decisions were made. However, the business requirement of getting something in the app to test was no longer relevant, and following the “use, manage, grow” framework, we collectively decided to add it to the bottom navigation.

One of the advantages of waiting to integrate Flexa was that we could then look at the data from their Spedn app and get a better sense of user behavior. One of the insights we found was that users rarely use more than one currency for purchases. With that knowledge, and in order to simplify the notion of account vs. currency vs. merchant limits, I suggested we pull out the currency selection and clearly detail what is “Available to spend”, whether an account balance limit, or a limit based on how much the user could spend weekly.

Following some visual explorations, I quickly mocked up the updated screens leveraging our mobile components and ensuring visual consistency.