For every idea I had AI explore it first, then decided: drop it, steer it, or build it. Then I critiqued what got built and went again.

They had the same problems I did: recipes cluttering their phones, and not being able to find the exact recipe they cooked before. They find it helpful to keep everything in one place and come back to the exact version they made.

I was the lead designer on the merge. A lot of the job was getting everyone to one shared version of the experience. I worked closely with product, front-end and back-end engineering, legal and content design, and I led the usability testing on both the content and the UI.

I also redesigned every action flow for scheduled transactions so they work the same way as predicted ones.

Putting both in one list raised a new problem: telling them apart. A predicted charge is our best guess, and it might not happen at all. A scheduled transfer is something the customer set up and knows will happen. If they looked identical, we’d be claiming more certainty than we had.

So every row got a small icon, a star for predicted and a calendar for scheduled. An info sheet explains the difference in plain language, including what the list doesn’t cover yet.

I tested the content and the UI with customers. Two findings led to changes.

Once both lived in one list, it didn’t make sense for them to behave differently when you tapped them. I redesigned every action flow for scheduled transactions around the patterns we already used for predicted charges: the same details page, the same card, and actions in the same place.

When a customer taps Cancel service, what we can do depends on the merchant:

• Direct: cancel through an API. We end the service for the customer.
• Assisted: submit a request. Minna Technologies contacts the merchant on their behalf.
• Guided: show how to cancel, with clear steps to cancel with the merchant.
• Always available: Block Charges as the fallback.

Goal: be useful in every case, even when we can’t finish the cancellation ourselves.

There were suggestions to put both Block charges and Cancel service on the merchant details page. As a design team, we pushed back. The two actions sound alike, and customers would have no easy way to choose one over the other.

Many merchants were eligible for both actions, some for only one, and some for neither. So we recommended one clear path, set by what the merchant supports, and took it through usability testing to check that customers understood it:

• Cancel and block both available: the customer cancels. While the cancellation is pending, we block charges in the back end, so they aren’t charged while we wait to hear back from the merchant.
• Only cancel available: the customer cancels.
• Only block available: the customer blocks charges.
• Neither available: I designed a flow with a cancel guide, since many merchants hide how to cancel, and a Contact merchant button.

In every round of testing, the Contact merchant button was a nice surprise for customers, because a merchant’s phone number is hard to find.

I tested the four directions with customers on UserTesting.com. I wasn’t asking which looked best; I was checking whether people understood three things:

• Could they recognize that the subscription price had changed?
• Could they tell that the change was based on a previous transaction?
• Could they connect that change to what they might see in an upcoming charge?

The direction that won was the one where people could see the past charge that had gone up and connect it to the next one.

Alongside the in-app work, I designed email templates for different types of spend insights, so we could test which ones customers engaged with most before bringing them into the app. They covered insights like:

• the merchants you spend the most at
• the categories you spent the most on last month
• your average spend last month compared with the month before, and other timeframes

The test emails went to a group of customers, and showed us that this month compared with last month was the timeframe they found most useful.

The way it’s built, spot a change, explain it where the customer will look, and send the same message by email, became the template for the insights that came after it. The email tests also gave the team a way to try an insight with customers before building it into the app.