Product designer ( ux ui) - Mexico City
Currently shaping the music streaming experience at Claro Música for 10M+ users across LATAM.
I designed Claro Música's native interface for Android Automotive OS: an independent dashboard app where every decision affects real safety.
I designed Claro Música's native interface for the vehicle dashboard. No phone, no mirroring. An independent app where every design decision has real safety implications.
Claro Música already existed in Android Auto, where the app is mirrored from the phone. This project was different: bringing Claro Música to Android Automotive OS, integrated into the vehicle's native system with Google Automotive Services.
The app was mirrored from the phone. No vehicle-specific design. No native system integration.
Running on the vehicle OS. The phone may not be present. Session and state live in the car.
That meant designing 11 screens from scratch for a context where the user has hands on the wheel and eyes on the road.
Before sketching a single screen, I needed to understand what it actually means to interact with a dashboard while driving. This was a fundamentally different user context than anything in the existing Claro Música product.
Problem statement: Claro Música users in vehicles need to control their music experience with minimal visual attention — but the existing Android Auto app was a phone mirror with no safety-aware design, making distraction-free use impossible.
From the research, three core design principles emerged. These were not aspirational — they were constraints that overruled any stakeholder request that conflicted with them.
Each major design challenge had multiple viable approaches. I explored them through sketches and low-fidelity flows before converging on a direction.
Option 1 — Email + password: Direct port from mobile. Rejected because it requires the full keyboard at the dashboard, creating a dangerous interaction at setup.
Option 2 — Auto-login from linked phone: Simpler technically, but breaks the independence premise of AAOS — the phone may not be present.
Option 3 — QR + 6-digit numeric code: Chosen. Zero keyboard on the dashboard. The numeric pad was already validated as a low-distraction pattern in Claro Música's Smart TV experience.
Option 1 — Replicate mobile density: Marketing's initial ask. Multiple content types, high information density per screen. Rejected because it violated the 2-second rule — too many visual decisions per glance.
Option 2 — Paginated carousels with strict limits: Chosen. Four carousel rows, maximum 8 items per row. Each row answers a single intent (recents, personalized, top, new). The cognitive cost per glance drops to one decision.
Option 1 — Free scroll: Development's preference for consistency with mobile and lower implementation complexity.
Option 2 — Fixed pagination: Chosen. Vehicle motion creates micro-vibrations that increase accidental swipe activation on free scroll. Pagination makes each navigation gesture intentional and discrete.
Remote usability testing simulated driving conditions. Completion time was used as a proxy for cognitive load — shorter means less visual attention required.
| Task | Scenario | Average time | Result |
|---|---|---|---|
| T1 | Play content from history | ~3.1s | Below the 5s threshold ✓ |
| T2 | Find and play by genre | ~5.4s | Only case above threshold — led to prioritizing carousels over search |
| T3 | Play downloaded content offline | ~4.1s | Below the threshold ✓ |
T2's result directly influenced the final home architecture: search was deprioritized visually in favor of personalized carousels, which served genre-based browsing faster through pre-curated rows.
The user enters through QR login, lands on a home screen with paginated carousels, and navigates without losing playback control thanks to the persistent miniplayer.
In automotive, design decisions carry safety implications that most digital products don't. That created real friction — and required evidence, not opinions, to resolve.
Stakeholder position: Backend team preferred a direct email + password adaptation. Lower development effort, consistent with existing auth infrastructure.
Design position: Any login that requires a full keyboard at the dashboard is a safety hazard. The interaction is too complex for a stationary vehicle setup moment, let alone motion.
Resolution: QR + 6-digit code. I referenced the Smart TV implementation already live — same team had already built the backend for it. Cost: additional QR generation endpoint. Benefit: zero keyboard interaction on the dashboard.
Stakeholder position: Development pushed for free scroll — consistent with mobile, lower implementation effort, easier maintenance.
Design position: Vehicle vibration creates accidental scroll activations. Free scroll in motion is unpredictable and increases misclick rate.
Resolution: Maze test with both patterns. 25% misclick on free scroll vs. 7% on fixed pagination. Data closed the debate without needing organizational authority.
Stakeholder position: Marketing wanted to replicate mobile density — more content visible, more discovery, more engagement signals.
Design position: High density on a dashboard violates the 2-second rule. More content per view means more decisions per glance, which means more time with eyes off the road.
Resolution: 4 carousel rows, max 8 items per row. Each row serves one intent. The constraint was framed as a feature — curated content performs better than dense content in low-attention contexts.
Stakeholder position: Product proposed showing empty states without explicit redirection — simpler to build, acceptable UX by mobile standards.
Design position: In a car, a dead end is worse than on mobile — the user cannot easily recover without significant attention. Every empty state needs a clear path forward.
Resolution: Three visual states designed (available, downloading, offline ready) with consistent redirection to Downloads from any empty section. Cost: 3 additional state variants per section. Benefit: no dead ends in any network condition.
Designing for automotive is not adapting mobile with larger buttons: it is a paradigm where safety and context are primary constraints. Every screen decision carries a weight that doesn't exist in other digital products.
The strongest decisions were closed with data. Intuition identified the problem, but test evidence resolved debates with stakeholders — removing the need for organizational authority to settle design disagreements.
For the next iteration, the clearest opportunity is to deepen Google Assistant voice commands to reduce visual interaction to near zero for the most frequent actions.
I redesigned Claro Música's premium subscription landing into a mobile-first flow that reduced friction across 18 LATAM markets.
How I transformed a confusing, desktop-oriented sales page into a mobile-first subscription flow that increased conversion across 18 LATAM markets.
Before proposing any solution, I needed to understand the real friction — not assume it. The data painted a clear picture of a product misaligned with how its users actually arrived.
Problem statement: Mobile users arriving at the Claro Música subscription page cannot understand the plan difference or trust the trial offer — because the page forces parallel decisions in a single view designed for desktop, causing drop-off before any commitment.
Two root causes emerged from the research:
Showing multiple plans side-by-side requires active comparison. On mobile, this creates hesitation — users stall rather than decide.
Inconsistent trial messaging ("1 month" vs "1 week") created the perception of hidden conditions, triggering abandonment before phone validation.
I ran a short ideation phase with PM and one developer to explore architecturally different solutions before prototyping. The goal was to find a structure that reduced cognitive load at the decision moment.
Improve hierarchy, typography, and CTA weight on the existing single-page structure. Faster to build, no structural changes needed.
Why discarded: The problem was the parallel decision model itself, not the visual execution. Polishing the layout would not solve the hesitation pattern confirmed in recordings.
Each plan gets its own full screen. The user selects a tab and sees one plan in full context — pricing, benefits, trial terms — without visual competition from other options.
Why chosen: Eliminates the comparison paralysis. Each screen does one thing. Sequential commitment replaces parallel selection.
A guided flow that asks one question at a time: number of users → duration preference → plan. Reduces cognitive load per step.
Why discarded: Adds steps for users who already know what they want. High re-entry friction for users comparing plans. Also requires more backend logic to reconstruct intent across steps.
I worked in short divergence-convergence loops with PM and engineering. Each round had a specific hypothesis to test, not just general usability validation.
The Family plan had the highest relative increase (+51%), likely because the tab architecture made it a visible, first-class option instead of a secondary choice buried below the fold.
The goal was qualified conversion, not maximum conversion. Some constraints improved billing reliability and fraud control in ways that mattered more than marginal drop-off reduction.
Stakeholder position: PM and some stakeholders pushed to remove SMS verification to reduce abandonment at that step. Email-only or one-click sign-up would be simpler.
Design + Business position: Activation depended on validating Claro/Telcel line ownership for carrier billing. Removing SMS would break the billing model, not just simplify the flow.
Cost accepted: ~3% more abandonment vs. an email-only path.
Mitigation: Clear copy, countdown timer, and phone number prefill for returning users reduced anxiety without removing the verification step.
Stakeholder position: Regional teams in other LATAM countries wanted simultaneous rollout to capture results across markets at once.
Design position: Trust patterns and onboarding expectations differ by country. Launching everywhere at once meant no ability to react to market-specific friction before it affected large volumes.
Resolution: Mexico-first with phased expansion. Country-level monitoring and local copy adjustments before each market went live.
Constraint: Tight delivery timeline made comprehensive connectivity testing impractical in early rounds.
Cost accepted: Potential degraded experience in lower-bandwidth regions during initial rollout.
Mitigation: Progressive enhancement plan defined before launch — lighter assets, lazy-loading, and critical CSS prioritization — to be applied before broader LATAM expansion.
This project reinforced that conversion problems are often architectural, not visual. On mobile, parallel choices create hesitation; sequential choices create momentum. The fix wasn't better design — it was a different structure.
If I repeated the project, I would involve the customer support team earlier. Billing-related tickets turned out to be the fastest signal for trust-copy decisions — information that was available but not in the design process.
I designed a management tool for Felpuditos MX that centralizes quoting, order tracking, customer management, and financial configuration.
I designed a tool from scratch for Felpuditos MX, centralizing quoting, order follow-up, customer management, and financial setup into one cohesive system.
The founders of Felpuditos were also the end users. That gave me direct access to their actual work — not a description of it. I conducted shadowing sessions observing their full daily operation from order intake to delivery.
Problem statement: Felpuditos cannot scale beyond 3-4 orders per day because every administrative task — quoting, order tracking, financial calculation — is manual, fragile, and scattered across disconnected tools.
| Problem | Business impact |
|---|---|
| Manual price calculation | 40+ fragile formulas. Cost updates took 30-40 min. Frequent errors. |
| Orders across 3 channels | Lost details, duplicates, no status visibility. |
| No real margin visibility | Revenue tracked, profit unknown. VAT and fees unaccounted per order. |
| Unstructured design files | 20-40 min per order to prepare production guide. |
| No customer history | No recurrence tracking, no preference data. |
| Opaque profit split | 52/48 partner agreement manually calculated, unauditable. |
Before committing to a custom tool, I explored three approaches with the founders to understand what level of solution actually fit their context and technical capacity.
Use Notion databases or Airtable to centralize orders and calculate prices with formulas.
Why discarded: Pricing logic was too complex for formula-based tools without breaking under cost updates. The founders also needed a quote output they could share with customers immediately — neither tool handled that without heavy customization that would break with any update.
Rebuild the spreadsheet with cleaner structure, protected cells, and a single input sheet.
Why discarded: Excel had already proven its fragility — the problem wasn't the formulas, it was the interface model. A redesigned spreadsheet would still require training, still break on unexpected inputs, and still offer no order tracking or customer history.
A purpose-built internal tool with a persistent sidebar navigation and five modules: Calculator, Orders, Inventory, Customers, and Settings.
Why chosen: The only solution that could handle real-time chained pricing, order history, customer data, and configurable financial parameters in a single place — without requiring technical knowledge to maintain.
Within the custom app, the calculator module architecture also had two directions: a single-screen dense layout vs. a three-column layout that made inputs, variables, and cost breakdown visible simultaneously. The three-column approach was chosen because transparency in the calculation was itself a feature — the founders needed to verify results, not just trust them.
Because the founders were the users, testing was embedded in the design process — not a formal validation round at the end. I ran two iteration cycles with working prototypes before the final build.
| Area | Before | After |
|---|---|---|
| Quote speed | ~5 min | ~30 sec |
| Daily quote capacity | 3–4 | 10+ |
| Calculation errors | 2–3 per week | 0 in 71 orders |
| Production guide prep | 20–40 min/order | Seconds |
| Customer records | 0 structured | 14 with full history |
The bottleneck moved from quoting to actual production capacity — which is the right problem to have.
Working directly with end users who are also stakeholders creates a specific tension: their immediate preferences don't always align with what the product needs to scale.
Founders' position: They wanted to keep receiving orders through WhatsApp — it was their relationship channel with customers, and asking customers to use a new tool was a risk they weren't willing to take at launch.
Design position: A system where orders arrive outside the tool means the tool never has complete data, and order history is always partial.
Resolution: The V1 tool was designed for internal use only — the founders manually enter orders received through any channel. WhatsApp was not replaced, only decoupled from the operational record. The public-facing quote tool was scoped to V2, when customer behavior data would support the change.
Founders' position: Initially preferred a simpler interface — just show the final price. The breakdown felt like unnecessary complexity.
Design position: The breakdown was the only way to build trust in the system. If a number looked wrong and they couldn't audit it, they'd default back to Excel.
Resolution: Full breakdown kept, presented in a collapsible section so it doesn't dominate the interface but is always accessible. After iteration 1, the founders actively used the breakdown to catch a misconfigured material cost in Settings — which validated the decision.
Founders' position: Wanted inventory tracking included in V1 — material stock was a real pain point.
Design position: Building inventory before the core quoting and order modules were validated would split attention and delay the highest-leverage features.
Resolution: Inventory was scoped to V2 with a placeholder in the sidebar navigation so the founders could see where it would live. Shipping the rest first meant the tool was in production 3 weeks earlier than if inventory had been included.
Felpuditos wasn't a nice app for a small business. It was a system that moved the operational bottleneck from administration to actual production capacity.
The most important design decision wasn't a UI pattern — it was choosing a custom tool over adapting existing software. That choice made everything else possible.
Continuous field research surfaced opportunities that an initial interview would have missed entirely — especially the visual production guide bottleneck, which turned out to be as costly as the pricing problem.
Hi. I'm a UX/UI designer based in Mexico City, and I've spent the last 3.5 years at Claro Música designing for one of the largest streaming platforms in the region. I like building digital products where business goals and user goals don't have to compete.
I work pragmatically: I'd rather have an ugly prototype tested with 5 people than a flawless Figma file nobody validated. I'm especially interested in subscription and conversion flows, where a strong UX pattern can change the quarter's results.
Outside of work, I spend time with my girlfriend, play Valorant with friends, and usually keep my Steam Deck nearby for an indie game or a backlog run.
