I introduced lightweight weekly rituals (planning sessions, task reviews, and monthly retrospectives), creating a predictable rhythm that helped the team stay aligned, protect focus, and surface blockers early. I also rotate facilitation formats so retros stay useful, not repetitive.

I designed an 8-stage UX workflow and connected it to shared Notion boards for tasks, projects, and sprint planning, giving the team a clearer view of priorities, progress, and ownership.

I documented a set of product principles and collaborative workflows for Figma, research, and design-system contributions, helping designers work more consistently and onboard faster.

We introduced regular product reviews and structured usability testing across live product flows, creating a stronger feedback loop between design, PMs, engineers, and users.

Before planning sessions, I generated lightweight summaries of blocked tasks, recurring bottlenecks, and workload patterns from our Notion boards. This helped the team align faster on priorities and spend less time interpreting project status manually.

I used AI to help with the heavier documentation side of product work: drafting feature specs, organizing epics, writing tickets, and structuring requirements before team discussions. It helped reduce repetitive work and made it easier to keep projects documented without turning documentation itself into a bottleneck.

I used AI to organize and connect insights across usability tests, interviews, meeting notes, and sprint discussions. This made it easier to keep user context visible throughout delivery instead of treating discovery as a separate phase.

AI also helped summarize long discussions, organize scattered information, and make async updates easier to consume across time zones and disciplines, reducing the amount of coordination overhead required from the team.

I upload user interview recordings to Dovetail. The platform generates a transcript of each conversation, which becomes the working base for analysis instead of starting from scattered notes.

Inside each interview I mark key moments, tag findings, and cluster themes. Dovetail lets me connect insights into boards and keep persona profiles updated as research evolves.

Beyond Dovetail’s built-in tools, I use custom agents to compare interviews, personas, and past findings. That helps me cross information in ways I might not have thought to do manually, and surface insights that are easy to miss at first read.

The goal is research the team can actually use: insight boards, tagged evidence, and synthesis that supports planning, design decisions, and stakeholder conversations without losing the original context.

Our components, variants, and tokens live in a shared Figma library. This is where design defines how the UI should look and behave before anything gets built.

Claude Code is an AI coding agent that can work inside the codebase. I use it to read design system context from Figma and help generate or update component code, prop definitions, and documentation structure in a way that stays closer to the source design.

Storybook is a component catalog for developers. Each component gets documented with its states, props, and usage examples so engineers can browse, test, and implement without guessing how design intended it to work.

The flow is: design in Figma, translate structure and tokens with Claude Code, publish to Storybook. That closes the gap between what designers maintain and what developers ship, especially as the system scales.

Figma Make helps me generate and iterate on UI directions quickly inside Figma. It’s useful for opening up alternatives when I want to compare layouts or interaction patterns without building everything from scratch.

When a direction looks promising, I use Claude Code to move into more functional prototypes: flows, states, and behavior that are harder to communicate with static screens alone.

The point isn’t speed for its own sake. It’s having enough options on the table, early enough, to make better product decisions together before the team invests in full build-out.

Define what success looks like for the flow or feature: complete a booking, finish onboarding, adopt a new capability. The metric should reflect that outcome, not a generic usability score collected out of habit.

FullStory shows where users drop off or show frustration. Session replay explains why: confusing copy, a broken control, slow load time, or a layout that looks clickable but is not.

I use FullStory Conversions to estimate which frustration signals correlate with lost completions, so the team fixes what affects the funnel most instead of chasing isolated clicks.

After a design change, I compare the same funnel and signals over time to confirm conversion, friction, and error rates moved in the right direction.

Build a funnel in FullStory for the flow you care about (e.g. start checkout → confirm payment). FullStory calculates:

Conversion rate = users who completed the funnel ÷ users who started the funnel

Review step-by-step drop-off and median time to convert to see which step is slow or losing the most users.

FullStory logs a rage click when someone clicks or taps rapidly in the same area, usually a sign of frustration. Open the rage click report to see a rank-ordered list of elements, then watch sessions to understand what users expected to happen.

A dead click is a click on something that looks interactive but does not respond. In Conversions, compare users who had dead clicks on a step vs. those who did not. FullStory surfaces conversion impact: the share of users with the signal who dropped out compared to users without it.

Search for the Console Error event filter or build a Dimensionality card grouped by error text. This quantifies how many sessions hit the same JavaScript error and on which pages, then replay those sessions to show engineering exactly what broke in context.

In FullStory Conversions, select a funnel and let the tool analyze frustration signals (rage clicks, dead clicks, network errors, slow pages). It ranks signals by estimated lost conversions so the team can ask: if we fix this element or step, how many more users might complete the flow?

Metrics tell us where to look; replay tells us what to do. I share short clips with PM and engineering when a signal is ambiguous, so design decisions stay grounded in observed behavior rather than dashboard averages alone.

Urban drivers who move through dense cities like Montevideo: commuters, students, delivery workers, and professionals who park on the street often and need fast decisions while driving.

Finding parking consumes time, creates stress, worsens traffic, and adds constant uncertainty. Most apps show static maps, lack real-time context, or ask for too much interaction when the user is already distracted behind the wheel.

Build a collaborative layer where drivers share availability in seconds: report a spot, search nearby zones, save where they parked, and walk back to the car later. The goal is not just to show places, but to reduce anxiety and lost time.

Each screen should answer what the user needs right now. Avoid long forms, deep navigation, and decisions that do not belong in a driving context.

Real-time availability works when reporting is faster than the problem it solves. The product wins when helping others takes almost no effort.

A restrained visual system — light backgrounds, simple icons, generous spacing — keeps attention on the map and the next action, not on the interface itself.

Design for fingers, one-handed use, quick scanning, and incomplete input. That is what makes Hay Lugar usable while moving through the city, not just on a desk.