Hola, I’m Tony™.

Banrural.

Broken systems at scale. 2025 - 2026

My role in this project.

Official title: UX Researcher

Project role: Research Lead & Product Design IC

Led internal research and core product design in collaboration with the PM, PO, designers, business teams, frontline employees, and implementation provider.

The work translated research into user profiles, process maps, SIPOC diagrams, customer information architecture, service and origination flows, system maps, wireframes, functional prototypes, test scenarios, and handoff recommendations.

Co-design sessions, employee testing, and workflow refinement carried the work through to development handoff.

During the project I had the pleasure of working alongside project leaders Leonardo R., Werner M., Diego V., and Oscar T., as well as the lead product designer Rodrigo S. and product designer Nehemias P..

Context.

5,000+ Users / 740+ Branches

Problem

Banrural risked moving its fragmented service operation into a new CRM. Research showed that many delays started with incomplete, misclassified, or misrouted tickets that Back Office had to reject and return. Adoption of the existing system was also limited by generic workflows, minimal training, restrictive permissions, and performance issues at the bank’s scale.

Solution

I led the research and helped with product design direction for Portal 360 around four essential frontline jobs: identify the customer, understand their relationship with the bank, create the right request, and track its progress.

We mapped the end-to-end service operation, co-designed the experience with frontline employees, and redesigned the request pipeline. Before committing development resources, we tested the concept across 22 agencies in 8 different regions across Guatemala.

Result

Portal 360 established a unified, bank-owned, internal user centered experience for serving customers without requiring front line employees to navigate the complexity of the bank’s underlying systems.

The new experience needed to support more than 5,000 frontline employees across 740+ branches, with the potential to expand to approximately 6,000 people in the near future. Its origination feature has already materially reduced incorrectly routed tickets and internal rework through the native CRM implementation, while the broader program has become an internal reference for product and digital-transformation work.

Understanding the operation.

The project initially came with the direct order to focus on Back Office, where delays were most visible. Through stakeholder workshops, cultural research, AS-IS and SIPOC exercises, and process mapping, we reconstructed how requests moved through teams, systems, and operational handoffs.

The research showed that many tickets arrived at Back Office already incomplete or incorrectly classified. Ambiguous definitions for complaints and claims, more than 100 categories, and multiple classification points increased the likelihood of mistakes. Rejected requests returned to frontline employees, creating repeated work and extending resolution time for the customer.

The problem extended beyond tickets. Employees consulted a legacy CRM, the core banking system, separate workflow and process tools, legacy applications, and sometimes up to 20 lists to reconstruct customer context. Information could be duplicated or outdated, while reporting depended on manual workflows and offered limited visibility into SLAs.

With the the results of my research, I recommended prioritizing Centros de Negocio, the frontline employees responsible for understanding the customer and initiating requests. Supporting their complete service workflow would address both the quality of information entering the operation and the fragmented experience behind it.

Attempting to change the software without understanding the operating model could reproduce the same failure inside a newer platform.

Defining how the bank would take control over its internal user experience.

The initial expectation was to use the new CRM platform largely out of the box. Research clarified that the broader frontline population needed a focused set of capabilities: identify a customer, understand their relationship with the bank, create a request, and follow its progress.

Technical and licensing constraints also shaped the decision to build a custom interface. The program separated into two connected tracks: the native CRM for a smaller operational group and Portal 360 for the larger frontline workforce.

Portal 360 would bring information and actions together while the CRM supported customer-relationship operations and the core banking system and other platforms remained sources of record. This approach gave the bank greater control over what employees could see and do, how the interface evolved, and which capabilities could be added over time.

The architectural direction centered on ownership, governance, modularity, and separation from the core. The portal would coordinate the employee experience without becoming another competing database.

Improving ticket creation alone would not solve the broader service problem. Frontline employees still lacked a reliable way to understand the customer before deciding what action to take.

Co-designing tools for us, by us.

With the custom-interface direction established, we worked through multiple levels of leadership and cross-functional teams to define the product’s scope, responsibilities, business requirements, and technical constraints. This connected the proposed experience to the people responsible for operating, governing, and implementing it.

I worked with business leadership and regional managers to involve frontline employees in designing the experience. Their contribution helped determine which information mattered during a customer interaction, when it should appear, how ticket states should be communicated, and which routes matched their understanding of the work.

We organized the customer view around three questions:

Who is my customer?
What products the customer have with us?
What support interactions we had before?

These questions gave structure to identity, banking products, and service history without turning the profile into a collection of every available data point.

Co-design established the product’s information priorities and interaction logic. Employees were helping define the experience that would later be built into prototypes and taken into formal validation.

5,000 employees didn’t need every CRM capability.

They needed a focused experience that exposed the right customer information, supported accurate ticket creation, and made case progress understandable without forcing them to navigate the CRM’s underlying complexity.

Making the product tangible.

Shared, transparent and integral decisions became maps, interfaces, and functional prototypes.

I translated the co-design work into information inventories, user flows, system maps, wireframes, and functional prototypes. These artifacts connected the proposed interface to its underlying behavior: routes, states, permissions, required information, handoffs, and edge cases.

The system map gave business, product, design, and the implementation provider a shared reference. It made dependencies and unresolved decisions visible before they became gaps in detailed design or development.

Functional prototyping made the experience easier to evaluate. After auditing the CRM’s relevant interaction patterns, I built an initial AI-assisted prototype in approximately eight hours. Using fictional data and no production access, it allowed stakeholders to search for customers, inspect profiles, and create requests. The provider had estimated approximately one to two months to produce a functional prototype through its usual process.

The prototype helped secure support for further work, while the maps and detailed designs established how the product needed to behave. Together, they gave us a concrete experience to take into regional validation.

Shared, transparent and integral decisions became maps, interfaces, and functional prototypes.

Testing against operating realities.

Once the experience and prototypes were ready, we validated Portal 360 with 66 individual contributors across eight regions, including metropolitan, regional, border, and rural contexts. This broadened the evaluation beyond employees who were easiest to reach from Guatemala City.

This exercise consisted of scenario-based testing which covered customer identification, information retrieval, request creation, required documentation, company representation, and follow-up. We examined task success, interpretation of ticket states, information quality, and continuity when a request could not be completed.

The broader program exposed differences in workload, case variety, operational pace, and familiarity with digital tools. Metropolitan agencies showed more errors under heavier and more varied demand, while some regional operations appeared faster and more orderly. Dependence on Back Office remained a recurring issue across locations.

These findings identified where Portal 360 supported reliable behavior and where its terminology, states, and controls needed refinement. They also showed that familiar operating habits could persist inside a new interface.

We evaluated whether employees could maintain continuity, interpret ticket states, validate information, and complete tasks under realistic operational conditions.

Iterating and refining.

Our custom pre-SCRUM design pipeline kept a healthy, validated and approved backlog for the development team.

Following regional validation, we refined the portal and continued testing specific capabilities, including the origination module. We compared approaches that started with the customer’s intent or the banking product, examining how each affected classification and the requirements employees encountered.

The intent-first approach reduced the initial choice to approximately five options and progressively exposed relevant products and documentation. It required more deliberate configuration behind the scenes, but reduced the complexity employees faced during each interaction.

Testing also revealed a problem with incomplete requests. In one controlled scenario, none of the participants used the intended note workflow successfully. Employees instead entered filler information and submitted the ticket, expecting Back Office to reject it while the customer gathered the missing documents.

This informed a recommendation for a clearer, constrained state before formal submission, allowing employees to preserve progress without inventing information. We also recommended scenario-based training so employees could practice these decisions without creating real tickets or using customer data.

Significant outcomes.

We introduced a healthier way to build internal products: Understand what our colleagues need, design with them, and use research to guide decisions that improve how the whole bank operates.

The project delivered the design and validated direction for Portal 360: a bank-owned interface connecting customer identity, products, service history, request creation, and follow-up. It was designed for more than 5,000 frontline employees across 748 branches, with expansion toward approximately 6,000 collaborators.

At handoff, the product was moving through training and rollout. Its refined origination model had already delivered an early operational improvement through the native CRM, reducing incorrectly routed tickets and internal rework. Exact metrics remain confidential.

The program also established a more structured path from research to delivery. Shared product definitions, documented behavior, and repeated validation gave teams clearer decisions to implement and visibility beyond individual sprints. Portal 360 became an internal reference for how the bank could approach product and digital-transformation work.

Pixto.

Building an open money ecosystem. 2025 - 2026

My role in this project.

Official title: UX Researcher

Project role: Research Lead & Product Design IC

My duty was to connect existing studies with ongoing discovery to map users’ financial routines and define Pixto’s core money-management experience.

The work covered research synthesis, journey mapping, co-design, and validation across onboarding, cash-in, balance and activity, transfers, cash-out, and card management. It also contributed to second-release planning for gamification and SaaS provider evaluation.

I had the pleasure of doing this alongside a team I really valued: Carlos A. led the project, Julissa R. was PO, Sergio R. was PM, Lucia R. brought payments PO expertise, and Julio O. as Lead Product Designer. Julio was also a close friend, which made working together especially meaningful.

Context.

2,000 Pilot users

One test region in Guatemala

Problem

Pixto is a digital wallet and reloadable card being tested in one region of Guatemala. Research showed that people still relied on cash, notebooks, and informal networks, making a dependable money-management foundation more urgent than adding new features.

The evidence combined an attitudinal study with 700+ participants, 300+ survey responses, around 50 interviews, and fieldwork with about 100 shopkeepers. These participants informed the product direction but were not necessarily active Pixto users.

Solution

As UX Researcher, I connected these studies with ongoing discovery to help define and validate Pixto’s core money-management experience: onboarding, cash-in, balance and activity, transfers, card activation and controls, and cash-out.

We examined how people understood each step, where they needed confirmation, and what information gave them confidence and control. This created a coherent foundation for the wallet while business teams continued exploring savings, merchant payments, POS, and gamification.

Result

The proposed money-management foundation was approved and used to guide development of Pixto’s core features.

My work connected research to practical product decisions around onboarding, transaction visibility, card use, and access to money—and gave the team a clearer structure for evaluating future capabilities, including gamification and provider options.

Establishing what Pixto should become.

The project began with an existing product and several interpretations of its future. Before prioritizing features, we needed to agree on the financial problem Pixto would help people solve.

Pixto could help someone receive money, pay without cash, set funds aside, or accept payments in a small business. Internally, those possibilities were sometimes expressed as different product identities: wallet, prepaid card, remittance service, financial-education tool, or financial-inclusion platform.

Each direction implied different priorities. A remittance-led experience would organize itself around receiving funds. A merchant product would need to address acceptance, commissions, and access to working capital. A savings proposition would need to help people protect money from everyday spending.

The initiative work made these differences visible.

My contribution was to help connect the broader ambitions to a common foundation: people needed to bring money into Pixto, understand it, use it, and retrieve it with confidence.

That gave us a basis for sequencing the product while more specialized opportunities continued to develop.

Turning a broad research base into product direction.

The evidence base included an attitudinal study with 700+ field interviews, a separate unbanked-user study with around 50 interviews and 300+ surveys, and research with about 100 shopkeepers over three days.

Additional payments and savings research included two focus groups of around a dozen participants each, more than a dozen interviews, and a handful of business interviews. These studies addressed different populations and questions, providing complementary perspectives on the product opportunity.

In the unbanked-user study, close to nine in ten reported always using cash, while more than 80% said they would or might try Pixto. However, only about half expressed some or substantial trust in storing money on a phone. That distinction mattered. Interest suggested an opportunity, but confidence depended on understanding how the product worked and what would happen if something went wrong.

I synthesized findings through user needs, pain points, profiles, and journey mapping. Mapping the financial day helped connect the evidence to situations such as receiving income, paying obligations, separating household and business funds, and organizing what remained. Evidence revealed that even without hidden costs, available mobile POS, and multiple digital solutions, the public preferred a cash-based ecosystem.

People already had systems for these tasks. Notebooks, envelopes, memory, and informal savings arrangements provided familiar ways to manage money. The opportunity was to support those needs with better visibility, access, and traceability.

Translating findings into product priorities.

The core experience needed to support a complete money-management cycle. The research helped distinguish what people valued from the individual features used to deliver it.

In the unbanked-user study, about a third selected storing money as the most valuable capability, just over a quarter selected paying, and fewer than one in five selected receiving money. Having a card and sending money each accounted for less than one in ten, while remittances accounted for only a few percent.

These findings supported a broader discussion about the wallet’s purpose. The card was a way to use money. Transfers were part of receiving and moving funds. Cash access remained important to confidence in the overall experience.

My central recommendation was to prioritize the connected foundations: onboarding, cash-in, transfers, balance visibility, card activation and management, and cash-out.

I helped map, validate, and co-design these foundations with the team. The approach was approved and used to guide key features while the business continued defining payment platforms, POS capabilities, and gamification.

This gave the research a direct role in sequencing the product: establish the essential experience, then evaluate how additional capabilities extended its value.

Evaluating onboarding and product comprehension.

The unbanked-user study found that more than four in five were unfamiliar with reloadable cards. Product terminology therefore needed explanation rather than being treated as shared knowledge.

Onboarding evaluation exposed related issues. “Virtual prepaid card” did not consistently communicate what someone was receiving, where it could be used, or how it differed from a physical card. Some users associated the concept with mobile-wallet functionality, making clearer expectations necessary.

Successful onboarding meant understanding what to do next and being ready to use the product.

The experience also emphasized sending and receiving money while giving purchasing capabilities less visibility. Account creation and card activation introduced separate moments of effort, creating a gap between registration and readiness to use the product.

I contributed testing and interface feedback around these transitions. Recommendations included explaining card choices before selection, connecting registration and card readiness more clearly, and supporting users who needed to resume incomplete steps.

Merchant registration required a more specific response. Informal operators could enter a formal-business path and encounter fields they could not complete. The appropriate improvement was to clarify the choice and its requirements while preserving the information needed for each business type.

Supporting different levels of confidence.

The attitudinal study identified four profiles: Early Adopter, Late Majority, Resistant, and Confident Controller.

These helped the team examine differences beyond age or location. Some people were comfortable exploring independently. Others needed a demonstration, explicit confirmation, or detailed records before they felt confident completing an operation.

I used the profiles and broader research to inform co-design, interface feedback, and testing. The focus was on where the experience needed to provide guidance, show costs, clarify transaction states, or offer a route to help.

The physical context also mattered. Familiar locations and trusted people could help users become comfortable with digital services. For some, assistance during the first operation was part of learning to use the product independently.

The same financial task could require different kinds of reassurance as confidence was not a fixed user characteristic. It could change with the task, the amount of money, and the clarity of the outcome. My research supported an experience that could remain efficient for confident users while making help and verification available when needed.

Defining our vendor focus.

Merchant research expanded the problem beyond the person sending money. Shopkeepers needed to understand commissions, access to their funds, transaction confirmation, and the effect of unreliable connectivity. Some worried about exposing a personal phone number. Others were interested in digital payments but hesitant about formalization or committing money to an unfamiliar service.

These findings helped distinguish consumer money management from merchant acceptance. A successful payment experience needed to make sense to the person receiving the payment as well as the person making it.

I contributed research and product discussions around these needs while the business continued defining payment-platform and POS capabilities. This kept merchant requirements visible without treating every commercial opportunity as part of the immediate wallet scope.

For a rural merchant, accepting payments introduced a different set of decisions and cost stigmas. A payment feature also has to make sense for their margins, working capital, and daily operation.

Defining meaningful financial engagement.

A gamification feature was part of the requirements for the second release, the priority was to introduce engagement mechanisms that supported the core product purpose.

My work for this new feature focused on understanding which behaviors the product should encourage and how those behaviors would benefit users.

In the unbanked-user study, nearly half selected extra money and about a third selected discounts as incentives to try the product. These findings described potential attraction, but they did not establish sustained use or a lasting financial benefit.

The brief connected engagement to useful progress, including saving and retaining money. It recognized that valuable behavior could occur without frequent interaction: keeping funds available for a goal should not require unnecessary transactions or daily app visits.

I contributed to the direction and requirements, including boundaries against intrusive mechanics, competitive rankings, pressure to spend, and dependence on daily connectivity.

This gave the team criteria for evaluating proposed engagement features. The question was whether a mechanic supported the product’s financial purpose and remained appropriate for the audience’s circumstances.

Outcomes:
Research applied to product development.

The proposed money-management foundation was approved and used to guide key feature work while later payment, POS, and gamification capabilities continued to be defined.

My contribution connected the research to practical decisions: which needs belonged at the center of the product, how onboarding should explain card usage, where users needed guidance or verification, and how merchant requirements differed from consumer behavior.

The work also provided a clearer basis for future additions. Gamification and provider proposals could be evaluated against an established financial purpose, while new capabilities could build around the core experience.

At this stage, the demonstrated outcome was an approved direction applied to feature development, supported by research synthesis, mapping, co-design, and evaluation. Adoption and retention would need to be measured as the product expanded.

Research gave the team a clearer basis for deciding what Pixto should do, how it should explain itself, and where it needed to earn trust.

Osigu.

Connecting clinical care to the work required to get it paid. 2023 - 2025

My role in this project.

Official title: Brand and Product Designer

Project role: Product Design Lead & Research Lead

Led Product design across RCM, Servinte 2.0, Audit, and Cash Out modules. Mapped existing patient data intake and RCM operations, then translated claim-package management, evidence review, audit, corrections, clinical workflows, and payment coordination into product flows and interfaces.

The work contributed to a configurable product foundation that could support different institutional requirements while keeping the broader healthcare revenue cycle connected.

The product strategy, roadmap, and platform proposal I developed became part of the company’s Series B narrative and helped secure more than $20 million in funding.

Context.

10,500+ users / 35+ hospitals

$688M+ in transactions processed

Problem

Healthcare claims crossed clinical, administrative, and financial teams, but the evidence they needed was scattered across legacy systems, scanned documents, spreadsheets, messaging apps, and paper records. Teams had to reconstruct the claim, reconcile charges against contractual rules, and coordinate corrections across organizations. A dispute over one item could send the entire package back through the process.

Solution

I helped design a connected product structure for claim packages, clinical evidence, financial details, audit findings, corrections, approvals, and payment. After acquiring Servinte, Osigu prioritized RCM to address the immediate business need, then expanded into clinical documentation with Servinte 2.0 and payment coordination with Cash Out. The design accounted for the staff handling daily documentation and processing, as well as the clinicians making care decisions.

Result

Osigu shipped connected capabilities spanning clinical documentation, claim preparation, audit, correction, approval, and payment coordination. Reusable components and configurable rules supported different institutions without splitting the platform into separate products.

The product strategy and platform proposal I developed helped make the case for Osigu’s $25 million Series B.

Identifying each individual module operator.

Physicians were important stakeholders, but research showed that they were not always the people performing most of the daily interaction with the software.

Claims analysts, nurses, head nurses, clinical secretaries, and administrative staff frequently entered information, assembled supporting documents, and managed the operational workflow. Designing around an idealized physician persona would have overlooked much of this work.

I used those observations to redirect the experience toward the people operating the system. They needed clear instructions, readable information, efficient navigation, and a reliable connection between clinical evidence and financial records.

This influenced both the claims products and the clinical platform. The priority was to help different roles complete their responsibilities without assuming that everyone shared the same clinical knowledge, technical training, or authority to make decisions.

Clinical authority and software operation are often separate jobs.
Servinte’s legacy software brought all the bells and whistles to every single user at all times.

Structuring our Revenue Cycle Management solution.

In the South American operations we worked with, teams relied on Servinte for clinical workflows and OnBase for revenue cycle management. Improving claim preparation and monitoring was the immediate business priority, so we began with Osigu’s RCM while supporting its connection to existing clinical systems.

I examined the legacy workflows across OnBase and Servinte to understand how teams assembled claim packages, located supporting evidence, and tracked outstanding work. That understanding informed interfaces for finding packages, reviewing their contents and documentation, and identifying the next required action.

The design focused on making individual cases easier to manage within large claim packages. I simplified navigation between case information, supporting documents, correspondence, and actions, reducing the complex routes employees followed in the previous tools while preserving visibility into the broader package.

The product also needed to accommodate institutional differences. Agreements, documentation requirements, and operating procedures varied across organizations. I worked toward a configurable foundation that kept the core experience consistent while allowing those requirements to change without creating a separate interface for every client.

Understanding existing RCM operations helped us identify user needs, map their workflows, and pinpoint where the process broke down.

RCM became the first product we built driven by the business priority of improving claim preparation and management.

Co-designing our external audit module.

Claim review required auditors to reconcile billed items, agreed costs, and supporting clinical documents. In the workflows we examined, a discrepancy in one item could hold up an entire package, making it important to locate the issue, understand its context, and communicate the correction clearly.

I designed the audit experience around individual items and their supporting evidence. Reviewers could examine charges alongside documentation, record findings, and follow corrections without losing the context of the larger claim. The interface brought the information needed for a decision together while keeping the review history visible.

AI-assisted checks introduced another layer of scrutiny, surfacing discrepancies that required attention. That also created an initial bottleneck: employees who struggled with detailed review needed more support to interpret and resolve findings. Surfacing more issues increased the need for clear explanations and actionable next steps.

The additional visibility also raised questions about the conduct of contributors within client organizations. Reviewers needed to investigate whether discrepancies reflected documentation errors, misunderstood requirements, or potential misconduct. The interface had to support that investigation without presenting an automated flag as a conclusion.

Futureproofing patient data intake.

Claim quality began at the point of care. Improving data intake meant redesigning how patient information was documented before errors reached the claims process.

Following the Servinte acquisition, Osigu needed to modernize an aging clinical product while establishing a stronger connection between clinical documentation and revenue cycle management.

The legacy experience carried accumulated product debt and lacked usable documentation and user flows. Improving individual screens would not, by itself, establish a coherent foundation for the broader product.

I helped make the case for rebuilding the experience and led product design for Servinte 2.0. The direction was a lightweight, modular clinical platform that could support Colombian requirements while remaining adaptable to additional organizations and markets. The goal was a modular clinical suite with documented flows and reusable design assets.

The design centered on the operational staff documenting care, managing records, and preparing information for subsequent processes. Clinical events and supporting documents needed to remain useful beyond the moment they were entered.

When institutions used the connected clinical suite, that information could continue into claim assembly. This extended the design upstream: the quality and availability of clinical documentation directly affected the administrative work required to submit and review a claim.

Making the platform easier to scale.

We paired deeper user understanding with a modular design foundation, allowing the product to adapt without fragmenting.

As the platform evolved, the existing component foundation increasingly constrained consistency and implementation. I advocated for adopting a mature design system rather than continuing to extend aging custom components.

Later iterations moved toward a PrimeVue component foundation. This provided a more consistent basis for recurring interactions such as tables, forms, dialogs, notifications, and review states.

Business configuration mattered just as much as visual consistency. Healthcare agreements could contain exceptions and combinations that applied only to particular institutions or circumstances. Those differences needed to influence product behavior without making the interface unpredictable.

My work connected reusable interaction patterns with these variable rules, working with engineering through handoff and iteration. The objective was to preserve a recognizable experience even when the underlying requirements changed.

Outcome:
Connected healthcare operations.

The most important design decisions were never cosmetic. They came from understanding who actually operated the software, keeping clinical and financial evidence connected to consequential decisions, and building a foundation that could adapt across institutions without fragmenting the experience.

My work contributed to shipped products across a connected medical suite, from patient care with Servinte 2.0, to detailed audits with the dedicated module, connecting activities that had previously depended on separate tools, document repositories, and institutional handoffs.

The resulting experience brought clinical documentation, claim preparation, item-level review, corrections, approval, and payment coordination into a more coherent product suite.

The work also created a more reusable foundation for regional expansion:

A configurable RCM product.
An integrated audit experience.
A modernized, gadget friendly, clinical suite.
Connected payment operations.
An scalable clinical ecosystem.

HSBC.

Building smart money for the modern adult. 2023 - 2025

My role in this project.

Official title: Product Designer

Project role: Product Design Lead

As an outsourced Product Designer, I directly owned the product design direction of Login, Home, Card Management, and Transfers experiences within a dedicated Scrum cell.

Flow mapping with the PO and Innovation Lead, combined with rapid testing alongside UXR and marketing, shaped the product direction and interaction details.

Deliverables included feature flows, interface designs, interaction states, and high-fidelity prototypes.

Context.

Product concept & investment case

Case

HSBC commissioned YA as a conceptual mobile financial product for young adults in Mexico, testing whether capabilities explored across its international Global Money product work could serve a distinct audience under a separate brand.

The opportunity was not just to offer payments, cards, transfers, rewards, and POS access; the experience had to make those capabilities feel clear and useful in daily life, as younger customers began adopting mobile-first banking. The potential audience of up to 10 million was an illustrative market scenario, not an HSBC forecast or customer count.

Solution

As a dedicated Product Designer, I worked with a cross-functional Scrum cell and owned the Home, Card Management, and Transfers experiences. Quick research and design tests showed that people were willing to take an extra step when it made a choice clearer, so we favored focused decisions over dense, multi-option screens.

I shaped Home around a quick read of the customer’s money, made card information and controls easier to find—including emerging NFC security concerns and designed transfers to make the recipient, amount, and outcome clear.

Result

The work produced a tested concept defining how YA’s core financial features could work together for young adults in urban Mexico. It gave HSBC a concrete product direction to discuss with digital-transformation leaders as the team sought support for development. YA remained a conceptual exercise; it was not launched by the project’s December 2024 deadline.

Turning an open brief into a strong product structure.

YA’s brief was to explore a wallet-like experience for young adults. The project had not entered development, giving us considerable freedom to propose interactions without working around an existing implementation.

That freedom still required structure. We began with FigJam boards, where I helped the Product Owner and innovation leader map capabilities, task sequences, and connections between features.

The map covered personal and business experiences, along with account creation, recovery, verification, and service handoffs. It gave the team a shared view of the proposition while providing context for each designer’s work.

For my modules, it clarified how Home connected to accounts and actions, how card management exposed more detailed controls, and how transfers progressed from destination selection to confirmation.

Designing for the financial future users imagined.

The studies available to us showed that potential users were thinking about remote work and migration. USD appeared as a stable reference for how they imagined earning and managing money.

I used that evidence to advocate for a currency switcher. It brought a specific audience need into the product discussion and gave us a reason to make currency part of the main experience. The instant currency switcher reflected where users wanted their lives to go, as well as where they were today.

On Home, I placed currency alongside the selected account and prominent balance. Recent activity followed, connecting the overview to individual transactions. Direct actions then provided routes into transfers, withdrawals, services, and accounts.

The proposal gave the team something concrete to evaluate: how a wallet for young adults in Mexico could acknowledge financial ambitions beyond local spending.

Letting feedback challenge the shortest flow.

Research and marketing ran quick tests as we developed the concept. A recurring pattern in the feedback was that participants were willing to make an extra click if they understood what they were doing.

Focused screens offering two clear options were often better received than screens combining several choices. That gave us a practical reason to preserve separate decision points.

In Transfers, the experience distinguished YA/HSBC destinations from other banks before moving into recipient selection and payment preparation. Beneficiary names appeared alongside account identifiers and, where relevant, bank information.

This mattered when the same person had more than one saved account. The interface needed to help customers identify the correct destination, then retain that selection while they chose the amount and funding account.

The trade-off was explicit: additional steps could be worthwhile when they made a financial decision easier to follow.

Keeping financial context close to the action.

Transfer preparation brought the selected recipient, amount, and funding-account choice into the same view. The account selector displayed balances and currencies so customers could inspect their options without leaving the task.

This applied the same principle used on Home: show enough context to understand a choice before acting on it. An account number identified an option; its balance and currency helped explain what choosing it meant.

The product map specified verification and confirmation before success. Transaction-detail views then provided a record with the amount, date, reference, and recipient information, alongside download and share actions. Together, these designs connected preparation with the customer’s later need to find and explain a transaction.

The source, destination, amount, and currency needed to remain connected. Financial information needed to stay close to the decision it supported.

Card management security came as a strict requirement.

I separated credit and debit cards in the overview and used masked identifiers to distinguish individual cards. Detailed views connected recent activity with payment information and relevant dates.

The design let customers move from recognizing a card to understanding its financial position, inspecting transactions, or making a payment. Blocking and configuration introduced further decisions with their own states and explanatory information.

Card management was particularly important for customers navigating busy urban environments. Contactless payments made card use more convenient, while highlighting the need for accessible security controls. I brought card status, recent transactions, and blocking into the same experience so customers could review activity and act quickly if something looked wrong.

The quick-test feedback reinforced the value of giving these actions enough space. A focused step could help communicate what the customer was changing and which card would be affected.

My responsibility was to turn those requirements into a coherent management experience, with a clear relationship between card information and available actions.

Ya was a concept built to support an investment decision.

The team presented YA to digital transformation leaders as part of an effort to secure C-suite support and development funding.

I contributed the design of Home, Card Management, and Transfers, helped map the wider experience, and advocated for currency switching based on the audience evidence available to us. Feedback from quick tests shaped the decision to retain focused steps where participants valued clarity over fewer clicks.

The initiative ended by December 2024 before development began. The work concluded at the concept stage, with mapped journeys and detailed designs that made the proposed product available for leadership evaluation.

The experience strengthened my ability to work within an exploratory team: question the brief, bring evidence into a design discussion, and revise interactions when feedback challenged an initial assumption.