Editor’s note: We came across Sofía’s Milestone project after seeing how she connected research, card sorting in Useberry, design, and AI throughout one end-to-end product workflow. We invited her to share how each stage gave the next one better context, and where human judgment still mattered as more of the execution moved to AI.

Sofía Álvarez is a product designer exploring UX research, product design, and AI-assisted workflows. You can follow her on LinkedIn.

What Milestone Taught Me About AI

By Sofía Álvarez

I started this project with the idea of designing a system where every step would leave enough context for AI to carry out the next one without having to improvise.

Milestone is a personal finance app that I built entirely on my own, from end to end: research, architecture, design, code, and deployment.

At first, I was thinking a lot about how different AI tools could help me move faster. But as the project progressed, I realized that the most interesting part wasn’t simply that AI could write code.

What I was actually doing was delegating an entire chain of work. And that chain worked because each stage resolved some of the decisions for the next one, instead of passing along another open-ended question.

Cream slide reading “A finance app shaped by research,” describing Milestone as a personal finance app shaped by user research, card sorting in Useberry, informed decision-making, and AI-assisted execution, next to a phone showing Milestone’s Spanish-language home screen with an active savings goal and recent records

The problem wasn’t about features, it was emotional

Milestone started from a fairly typical hypothesis: maybe people don’t manage their finances because the apps that already exist are too complex, too cold, or simply fail to create a habit.

To find out whether that was really the case, I interviewed real users. The hypothesis wasn’t completely wrong, but the interviews showed me that the problem went much deeper.

Everyone I interviewed was already using some kind of tool to manage their finances: a banking app, a digital wallet, Excel, or even a notebook. But at some point, every one of them had gone through the same thing: they stopped tracking their expenses.

Not because they were lazy or didn’t care about their financial situation, but because keeping up with the tracking eventually became more demanding than the benefit they got from doing it.

On top of that, most apps assume a level of discipline that doesn’t really exist in everyday life. When someone comes back after a period of not tracking anything, they often find negative balances, broken streaks, or incomplete information.

There’s a lot of design around maintaining a habit, but very little around the moment when someone decides to come back. One key insight came out of those interviews and ended up guiding a big part of the project:

The user doesn’t want to control their spending, they want to feel at ease.

That insight became more important than any list of features because it became the first piece of context I used to evaluate the decisions that followed, both the ones I made myself and the ones I started delegating to AI tools.

Card sorting with real users shaped the information architecture

Milestone’s information architecture didn’t come from a sitemap I created purely based on my own judgment or from benchmarking other apps. Before defining it, I ran an open card sorting study in Useberry, where real users grouped 21 features according to how they understood the relationships between them.

I didn’t treat the results as absolute truth. Before using them as the basis for the architecture, I personally reviewed the similarity matrix and standardization grid to make sure the groupings were consistent and that I wasn’t mistaking noise for a real pattern.

Once I had confirmed those clusters, I used Claude’s MCP in Figma to generate an initial sitemap. The result was six sections: Home, Records, Savings, Learn, Profile, and Settings.

At that point, AI didn’t have to invent categories or decide for itself how the features were related. That information had already come from the people who took part in the card sorting and, before it ever reached Claude, I had already reviewed and interpreted those results myself.

Light lavender slide reading “Card sorting gave the input. Design made the call.” next to a Spanish-language similarity matrix from Useberry showing how often participants grouped Milestone’s features together

When card sorting and interview research pointed in different directions

The process, though, wasn’t as linear as it might sound. When I took that sitemap into low-fidelity wireframes, the “Learn” section started to conflict with something that had come up during the interviews.

The card sorting had grouped that functionality quite consistently. But when I spoke with users, no one had expressed a need for a section where they could sit down and study finance. What they needed was to understand what to do at the exact moment a question came up, without feeling like they had to stop and take a class. So I decided to dissolve the “Learn” section.

The tips and mini-lessons stopped being a navigation section and became contextual content instead. They now appear when you create a goal, when you record an expense, or at the moment when you need to make a decision.

I also moved “Settings” into Profile. Other functionalities that the card sorting had grouped as concepts, such as marking a fixed expense as paid, editing a record, or filtering history, turned out to make more sense as actions inside a screen rather than as separate sections.

This part was especially important to me because it reminded me that card sorting shows how people mentally group different concepts, but that doesn’t necessarily mean those groups should translate directly into the final navigation.

Interpreting the results and deciding what to do with them was still part of my job. The final architecture ended up with five sections: Home, Savings, Record, History, and Profile.

There were also decisions about what not to build yet. The savings simulator and contextual tips made it into the product, while the achievements and badges system that I had originally imagined as a separate gamification section was reduced, for now, to an animation that appears when someone completes a goal. The rest was left for a later stage.

That wasn’t because the research had ruled out gamification. It was simply a scope decision. I preferred not to build more than necessary before knowing whether the core of the product actually worked.

From a validated screen to a living product

Once the architecture was clearer, I mapped the complete flow in Figma, from the first interaction through to sustained use.

Instead of immediately taking the entire product to high fidelity, I decided to prioritize one flow, Savings Goals, and build a real component system around it.

I documented 61 variants on top of the Material Design 3 UI Kit, adapting it to Milestone’s branding because I wanted the product to have its own identity and not end up looking like just another banking app.

Moving from designed screens to a working product involved a very deliberate prompt engineering process. I translated each Figma screen into instructions that Claude Code could execute without too much ambiguity, and I built the full application in Flutter and Firebase. By that point, many of the important decisions had already been made.

The research had defined the problem. The card sorting had provided evidence for the architecture. The wireframes had helped me interpret that information. And the component system had established how to translate it into the interface.

Claude Code didn’t have to decide what a “savings goal” meant to a user or how the information should be organized. Those decisions had already been resolved.

There was also one part of the process that I like talking about because it shows that the development wasn’t nearly as neat as it can sound when you tell the story after everything is finished.

To get a clickable prototype that I could test, I actually did things slightly backwards compared with the usual process. Instead of prototyping in Figma first and coding afterward, I took the code I had already developed in Flutter and used Claude’s MCP to bring it back into Figma as a prototype.

Before showing it to users, I ran my own UAT and found a broken icon that, if it had appeared during the test, probably would have hurt the credibility of the prototype.

What testing found, and why nine deployments is the number that matters

Then it was time to put the product in front of real users. I combined moderated sessions with an unmoderated prototype test, and that’s when the finding that mattered most to me in the entire project appeared:

A $20,000 savings goal was being marked as “completed” when the person had only saved $5,000.

This was a data integrity bug, not just a visual issue. If it had reached production, the app would have been telling someone they had reached a goal that they were actually still far from achieving. And that touched directly on one of the problems that had come up during the research: trust.

If a finance app can’t correctly tell you how much you’ve saved, it becomes very difficult to trust the rest of the information it shows you. From that point on, AI started taking on a different role from the one it had played during architecture or design.

Each testing finding became a specific instruction for Claude Code, which implemented the corresponding fix. Then I would go back and verify the result. There were nine real iterations, and before publishing each one, I checked the project with flutter analyze and flutter build web.

Again, the point wasn’t that AI somehow knew on its own what was wrong. The testing had turned an open-ended problem into a concrete problem that it could solve. Nine deployments later, the app is still running.

Light green slide reading “Testing turned findings into the next iteration,” noting that the most important findings came from putting the product in front of real users, next to a phone showing Milestone’s October budget screen at 72% used with spending categories

The decision was never AI’s

After going through this entire process, I think the thing that stayed with me most isn’t really about any specific tool. It’s about where the decision-making actually happened. At no point did I need AI to guess.

Card sorting allowed me to take part of the architecture out of my own head and ground it in what real users had expressed. The research, in turn, forced me to reinterpret that architecture when it came into conflict with what people actually needed.

The design turned those decisions into concrete screens and components, and the testing uncovered a problem that, if it had reached production, would have damaged the exact trust I was trying to build.

The agency was in all of those decisions: what to take from the card sorting and what to reinterpret, what to build first and what to leave for later, what information to give the AI, and when to give it.

AI was able to take on an increasingly large part of the execution because there were fewer ambiguous decisions left for it to resolve. That’s why, after Milestone, I started thinking about working with agents a little differently.

For me, an agent doesn’t replace the designer’s judgment. The interesting part isn’t simply that we can now do more things with AI. It’s that we have to learn to decide which things are worth delegating, what context each decision needs, and which decisions still belong to us.

From the Useberry team

What stood out to us in Sofía’s process was how research continued to shape the work even as AI took on more of the execution. Card sorting helped inform the architecture, Sofía’s interpretation of the research changed it, and later testing turned another open problem into something concrete that could be acted on. It’s a useful example of how AI can move faster when the decisions around it have better context.

Thanks to Sofía Álvarez for sharing the Milestone process with us. If you want to explore the research methods behind a similar workflow, you can learn more about card sorting with Useberry or see how prototype testing in Useberry can help bring real user behavior into product decisions before development goes too far.