In brief
You’ll have a product experience you can defend with evidence, ship with fewer open questions, and improve without breaking the parts that already work.
You reached out because the product has grown messy over a few releases and the same screens keep driving support tickets, or because you’re heading into a launch and the flows need to hold up under real use. You’ll finish with tested user flows, a UI that maps to your components, and a handoff your engineers can build without guessing. If you’d like to move ahead, we’ll book a start date and line up the first working session.
We start by finding where people get stuck, using your analytics, support patterns, and short sessions with real users. Then we rebuild the flow and navigation so the “happy path” is obvious and edge cases are handled on purpose. We design in Figma with components from day one, so what looks tidy in design stays buildable in code.
A bit about us
We’re a nine-person UI/UX team based in Oaxaca, Mexico, and we spend most of our time inside products that are already live. We got into this work the practical way: sitting with support teams, watching users struggle through the same step, then fixing the flow and seeing the ticket volume drop. We still work that way, with a bias toward what can be tested, built, and measured.
Teams pick us when they want design decisions tied to proof, not taste. We bring research into the same room as UI, so the screens match what users try to do and what engineering can ship. We’ll work with your existing design system when it’s doing its job, and we’ll clean it up when it’s creating workarounds, one component and token at a time.
Meet the team
You’ll work with a small core group day to day, and the rest of our team backs them up for reviews and coverage.
Team
Mariana López, UX lead. Mariana leads the UX work, runs the flow decisions, and keeps every screen tied back to the user tasks you need to improve.
Diego Hernández, UI designer. Diego owns UI design in Figma, taking the approved flow into high-fidelity screens that map cleanly to real components.
Valeria Cruz, User researcher. Valeria plans and runs interviews and usability tests, then turns what people did and said into findings your team can act on.
Santiago Reyes, Design systems designer. Santiago keeps the design system healthy, so new screens reuse the right parts and the library stays stable as you ship.
Recent work
Here’s a snapshot of the kind of ui/ux design we do when a product needs to ship cleaner flows without losing momentum.
Portfolio
Checkout flow redesign. We rebuilt the checkout steps around the decisions users actually make, removed repeated fields, and added clear recovery for failed payments. Support and engineering got one shared map of states, errors, and success conditions.
Navigation and IA rebuild. We restructured the main navigation around top tasks, renamed sections using the language users used in sessions, and rewired deep links so features were findable from more than one entry point.
Design system cleanup. We audited the component library, merged duplicates, defined spacing and type tokens, and documented when to use each pattern. Engineers got fewer one-off screens and more reuse across the app.
“They brought evidence to every decision and made handoff easy for engineering.”
Product manager, a growing SaaS product
How this runs
We keep the work tight and visible: short cycles, shared decisions, and no “big reveal” at the end. You’ll see the flow change first, then the screens, and you’ll always know what we’re testing and why.
1. Audit and map Days 1-4 We review the current flow, IA, and key screens against heuristics and your product goals. We look at analytics and support patterns to pick the highest-impact paths. You’ll get a working map of the current states, where people drop, and what we’re going to test first. 2. Test and decide Week 2 Valeria runs usability sessions with target users and we capture where they hesitate, misread labels, or abandon tasks. We synthesize findings into a short set of decisions: what we keep, what we change, and what we leave for later. You’ll join a readout to agree the direction. 3. Design and iterate Weeks 3-4 We rebuild the chosen flows in wireframes and an interactive prototype, then move into high-fidelity UI. Diego designs with components in mind, and Santiago aligns patterns and tokens so the library stays coherent. You’ll review in Figma with comments anchored to specific screens. 4. Handoff and support Week 5 We prepare the build-ready Figma files, define states and edge cases, and walk your developers through the flow and components. We stay available for implementation questions, because most surprises appear once code meets real data. You’ll leave with clear acceptance criteria for the build.
Product UX audit report
A written audit of your key flows, navigation, and screens, with prioritized issues and the specific usability or business risk each one creates.
RESEARCH PLAN AND SCRIPT
A test plan you can share internally, plus discussion guides and tasks written in plain language so sessions stay consistent across participants.
USABILITY TEST FINDINGS READOUT
A slide deck that shows what users did, where they got stuck, and what changed in the design because of it, with clips or notes where relevant.
User flows and IA map
A flow map and information architecture you can point to in stakeholder and engineering conversations, including key states, errors, and alternate paths.
FIGMA WIREFRAMES AND PROTOTYPE
Wireframes and an interactive prototype that matches the approved flow, so your team can validate the structure before polishing UI.
HIGH-FIDELITY UI AND SYSTEM UPDATES
Responsive web and mobile screens in Figma, plus updated components and tokens where needed, with accessibility notes attached to the patterns that matter.
Pricing
Pick the tier that matches how much needs to change. Each one covers the same 5-week run, with more depth in testing and design system work as you move up.
Priced items
Get started
If you want us to hold time for this, the next step is simple and we’ll keep it moving.
1. Sign this proposal to book the work. 2. Pay the 25% booking deposit invoice. 3. Join the kickoff call and share access to the product, analytics, and support history.
Signature
Fee summary
Payment
To book the work, the first invoice for 25% is due when the proposal is signed. The remaining 75% is invoiced when we hand over the finished work. Invoices are payable within 14 days.
Schedule. We’ll hold the start date once the proposal is signed and the booking invoice is paid. If feedback or materials arrive late, we’ll shift the timeline to match the next available working days.
Your input. You’ll assign one person to collect feedback and approvals. We’ll need product access, any existing research, and analytics and support ticket themes in Week 1 so the audit and test plan reflect reality.
Developer support. We’ll ask for one technical check-in during Weeks 2 to 4 to confirm what can ship and what needs a different approach. We’re not asking for build time, just answers to unblock design.
Changes to scope
If the work expands beyond the outputs listed in this proposal, we’ll write the change down first with the added cost and time. We’ll start the extra work after you approve it in writing.
Reviews and revisions. Each stage comes with review rounds as part of the schedule. We’ll iterate inside the agreed flows, screens, and system updates. New sections, new products, or parallel redesigns count as a scope change.
Handoff. Handoff is in Figma: final frames, components and styles, interaction notes, and a walkthrough call. If engineering needs clarification during the first build pass, we’ll answer questions for up to two weeks after handoff.
Ownership. Once the final invoice is paid, you own the final UX and UI work we deliver for your product. We keep the right to show selected screens and outcomes in our portfolio unless you ask for confidentiality in writing.
