Design leadership that never
left the craft — I lead the team
and I still do the work.

✦ Overview

A system that existed in name only.

I led this project for around three months at Ravn, partnering with MyFitnessPal's internal design team. The goal was to assess, restructure, and rebuild their design system while improving Figma organisation and overall design operations. My role covered the full scope — from defining structure and aligning teams to execution and ensuring long-term adoption.

✦ The problem

Low trust. High debt. Designers going rogue.

MyFitnessPal had an existing design system — but it wasn't functioning as one. Multiple libraries with no clear source of truth, deprecated components still in active use, and rampant detachments and local overrides. Tokens were inconsistent across colors, typography, and spacing. Design and development libraries weren't aligned. And critically: designers had stopped trusting the system, so they'd started building their own solutions instead.

✦ Audit & diagnosis

Five layers. One picture of the real state of things.

I started with a full audit across Figma organisation (teams, projects, file hierarchy, naming), design libraries (components, deprecated assets, documentation), design tokens (colors, typography, spacing, shadows), the live product UI (visual inconsistencies), and design-development alignment across iOS and Android. The data confirmed what designers already felt: the system was not trusted, not scalable, and not aligned.

✦ Strategy

Adoption over perfection.

Before touching a single component, I defined guiding principles: single source of truth, consistency over flexibility, alignment with development from day one, documentation as part of the system — not an afterthought, and adoption over perfection. A design system only works if people trust and use it. That framing shaped every decision that followed.

✦ What I built

Every decision had a reason. Here's the thinking.

Library consolidation. Four libraries — two active, one in progress, one POC floating outside the official structure — meant designers never knew which one to trust. I consolidated everything into a single main library for tokens and components, with a dedicated icon library kept separate. The separation wasn't arbitrary: icon files are large and slow to load, and keeping them isolated meant the main library stayed fast and focused. Scalable naming was aligned with development token logic so both sides were speaking the same language from day one.

Token architecture. The existing colors were a mess — names ranging from brand to premium to specific names like "protein," with similar hex values appearing under different names. I introduced a two-layer token structure: primitives (base values like blue/100, grey/500) and semantic tokens that described purpose, not appearance (color/content/brand/default). This naming schema — type → role → prominence — made tokens intuitive for both designers and developers. Light/dark mode was built into the semantic layer, not bolted on later. I exported everything as JSON via the Design Tokens plugin, feeding directly into the dev team's automation pipeline that generated platform-specific code for iOS and Android.

Typography. MFP supports both iOS and Android, each with different font families. Instead of maintaining separate files per platform, I set up modes within the typography token system — switching between iOS and Android styles without duplicating work. Each text style was built from five tokens: font family, weight, size, line height, and letter spacing. The naming schema followed the same type → role → weight logic as colors, so the system felt unified even across platforms.

Sizing & spacing. Values were being implemented differently throughout the codebase — no shared scale, no shared logic. I introduced t-shirt sizing (xxxs through xxl) across padding, spacing, and corner radius. The reasoning: shared scale means consistent rhythm. If sm = 8px everywhere — padding, spacing, radius — designers and developers can reason about layouts without constantly checking specs.

Components. I audited components from three sources — product files, the previous system library, and NUI 2.0 foundations. Rather than picking one and migrating, I rebuilt based on the most accessible and stable version of each component, using semantic tokens throughout for full theme support. All components were given a Vita prefix (e.g. VitaButton) to avoid conflicts with native iOS and Android element names — a practical decision made in collaboration with developers early on. Each component was documented with anatomy, light/dark states, boolean properties, motion behaviour, usage rules, and content guidelines.

Icons. 213 icons, many duplicated, inconsistently named, and scattered across the codebase. I cut this to ~100 standardised assets in a dedicated library. The decision to separate icons wasn't just about load time — it also allowed the icon set to evolve independently of the component library, with its own contribution and review process.

✦ DesignOps & Figma organisation

Structure is a design problem too.

I also rebuilt how teams and files were organised in Figma. I simplified the team structure, removed unnecessary layers, and introduced a standard file template used across all squads — covering cover/context, README, changelog, handoff, sandbox, testing, research, live tracking, local components, and drafts. This meant consistent onboarding, faster navigation, and less time lost to "where is that file?"

✦ Accessibility

Not a checklist. Built into the system.

I conducted a focused accessibility audit using APCA, WCAG 2.2, Apple HIG, and Material Design guidelines. Findings: 14 components failed minimum touch target requirements, 15 text styles failed contrast requirements. All failures were fixed before delivery — components were updated, contrast and luminance rules were defined, and a full accessibility kit was delivered alongside the system, including annotation components for screen reader behaviour, accessible naming, and interaction patterns. Accessibility wasn't a phase. It was part of the build.

✦ Collaboration

Weekly pairing, daily async updates, a dev-design Guild.

The collaboration structure was as intentional as the system itself. I ran weekly pairing sessions with MFP's design system designer, twice-weekly full design team meetings for system-wide alignment, and a dev-design Guild for technical decisions. On the Ravn side, I managed a dedicated Slack channel for structured design update announcements, with daily status updates forwarded to MFP to keep progress visible. All decisions were shared, reviewed, and documented — no surprises at handoff.

The result: MFP loved the work enough to keep the team for the next phase, expanding into their mobile app — impacting millions of users' daily health journeys.

✦ Impact

"When can we use this?" — the best question we could've heard.

The project consolidated multiple fragmented libraries into a single trusted system — reducing inconsistency across product and teams, and improving design-development alignment. Detachments dropped. Designers stopped building their own solutions. Dev handoff got faster and cleaner. But the signal that mattered most came from the room: after presenting to 200+ people at MFP's Engineering All Hands, the first reaction was asking when they could start using it.

The engagement was extended. The system is now being integrated into MFP's mobile app — a product used by millions of people every day.

✦ Recognition

What the team said.

"HUGE Shoutout to Carol for stepping up and giving a fantastic presentation in the MyFitnessPal Engineering All Hands. You knocked it out of the park. We got the best compliment we could possibly get which is 'when can we use this?'"

— Brandon, Ravn

"This team streamlined MyFitnessPal's design-to-code workflow and delivered redesigned components with Code Connect, eliminating designer-developer miscommunication. MFP loved the work so much they want us to stick around for the next phase. They're now part of something that genuinely impacts millions of people's daily lives and health journeys."

— Mario Mejía, Ravn

✦ Key learnings

The system is only as good as the trust people put in it.

Collaboration with development is critical from the start — not at handoff. Structure and documentation matter as much as components. Metrics like detachment counts reveal real system health in ways that audits alone don't. And accessibility should be embedded from the beginning, not retrofitted later.

✦ Overview

I didn't walk into this role cold.

From September 2025, I was already working as a Lead Product Designer at Ravn, part of the Design Council — a small group responsible for shaping how the design org operated. That experience gave me a clear view of what was missing before I was ever responsible for fixing it.

In January 2026, I assumed the highest position in the design org. Some of the people I'd been working alongside as peers became my direct reports overnight. That transition — peer to manager — is one of the most complex dynamics in leadership, and navigating it with honesty and care has been part of the work from day one.

✦ The problem

20 designers. Almost no shared infrastructure.

The level matrix existed but was largely undocumented, borrowed heavily from engineering frameworks, and had no design-specific competencies. Engineers level up on technical depth and code output. Designers level up on craft, communication, influence, and systems thinking. A framework that can't articulate that difference can't support designer growth.

The role structure had the same problem. Reporting lines were unclear. Role names didn't reflect actual responsibilities. Team members didn't know who their lead was accountable to, or what each leadership role was actually responsible for. Some roles had responsibilities that had never been documented at all.

Documentation was equally fragmented — scattered across Notion, Outline, and a Mission Board, with no single place where the team's structure, people, projects, and health data lived together. For a team of 20, none of this is minor. It's a retention risk, a motivation problem, and a leadership credibility issue.

✦ What I built — and why

Engineering frameworks keep showing up as the starting point. My job is to translate them for design.

Role restructure & org chart. The Head of Technology had created role documentation based on engineering — a reasonable starting point, but design and engineering are fundamentally different. I took that documentation and translated it entirely for design, solo. New role names and titles, responsibilities defined from scratch, documentation created and fixed across the board, org chart reorganized so reporting lines are clear and accessible to the whole team. Every designer can now open the org chart and immediately understand who does what, who reports to whom, and why.

Career tracks & leveling system. I built two separate tracks: IC and leadership — because a great senior designer and a great design lead are excellent at fundamentally different things and shouldn't be forced onto the same path. Each level has design-specific competencies: craft, communication, influence, systems thinking. Every designer now has a clear answer to three questions: where am I, what's expected of me, and what does the next step actually look like?

1:1 structure. I introduced a rotating theme model — alternating between growth, feedback, workload, and wellbeing conversations. If every 1:1 defaults to delivery status, you never create space for the conversations that actually move people forward. The consistency has been one of the most visible changes the team has noticed.

Hiring process. Before: disorganized, no upfront access to resumes or portfolios, no clear interview sequence. I restructured it into a defined pipeline — resumes and portfolios reviewed upfront, HR screen, product or design lead interview, then a tech interview with the Design Tech Lead. Assessments are now role-specific and tied directly to the leveling framework. I've already used it to hire trainees for the current PDTP cohort and one senior designer this year.

Design Perception Survey & Impact Dashboard. Leadership was making decisions about design investment without real data. I launched both to change that — giving me and leadership visibility into how design is perceived across the org and what it's actually delivering, beyond output.

✦ Product Design Training Program (PDTP)

A 6-month pipeline from trainee to client-ready designer.

The PDTP existed before me — but this cohort is mine. I interviewed and hired the trainees, improved the curriculum based on previous cohorts, added new content and challenges, and structured the full program.

The program runs in two phases. The first 3 months cover 3 modules of 4 weeks each — UX, UI, and Design Systems — with weekly design challenges evaluated by me throughout. I oversee the mentors, moderate office hours (where team members run workshops for trainees), evaluate challenges, answer questions, approve hours weekly, and track progress.

The second phase (months 4–6) moves trainees into internal projects where they work alongside designers, developers, and other team members — testing how they collaborate cross-functionally in a real environment. Trainees who perform well graduate and move to client projects, with supervision from senior designers.

The goal: a deliberate, structured path from trainee to client-ready designer that doesn't rely on informal mentorship and luck.

✦ Monthly team workshops

Bringing the whole team together — not just the pods.

With the team split across pods, designers can feel disconnected from each other. I'm building a monthly workshop program from scratch — a moment where the full design team comes together to learn, collaborate, and align, regardless of which pod they're in.

I'm defining the agenda for each session myself. The first workshop is focused on AI tools for design — specifically Figma MCP and how to use AI to improve product design work. It will be led by a team member who has been experimenting heavily with these tools. The goal is practical: help every designer on the team understand how AI can enhance their process, not replace it.

✦ The Shire — design ops platform

If you're fixing how a team operates, build the tool that runs it.

With documentation scattered across Notion, Outline, and a Mission Board, I built a centralized management platform using Claude Code — a full-stack internal tool built with Next.js, TypeScript, and PostgreSQL. It brings clients and projects, pod structure, trainee tracking, team health data, and people management into one place. It's live and continuously improving based on real usage. The name is intentional: home base, where everything and everyone is accounted for.

✦ The hard part

The things that don't make the highlight reel.

The peer-to-manager transition meant navigating relationships with real history — people I'd worked alongside as equals, who now had me in a position of authority over their growth and performance. Earning trust in that new dynamic takes time and intentionality, and there's no shortcut.

There were performance situations that required direct, difficult conversations — including a formal performance improvement process for one team member. That's part of what leading a team actually means.

The engineering-to-design translation also required making the case — to HR, to leadership, to the team — that design needs its own language for growth. That case isn't made once. It's made continuously.

✦ Early results

Culture came first. Structure is what's being built now.

The first design team health survey is in progress — 6 responses so far, more incoming. The gap between culture scores (all 5.0) and career clarity (3.5) tells the story exactly as it is: psychological safety and team culture are solid. The structural work — levels, tracks, roles, progression — is what's being embedded now.

✦ What's still in progress

Three months in. The foundation is real.

The career framework is built but not fully rolled out. The role restructure is documented but still being embedded. The PDTP is mid-program. The monthly workshops are being planned. The Shire is live but evolving. The survey is still collecting responses. The next phase is making all of it stick.

✦ Key learnings

Culture moves faster than structure.

You can build psychological safety in weeks. Career clarity takes longer — it requires alignment across the org, documentation that holds up, and trust that the framework is real and not just a slide deck.

The peer-to-manager transition taught me that authority doesn't transfer automatically. It has to be re-earned in a new context, with the same people, under different rules. That's uncomfortable. It's also the most important thing I've learned about leadership so far.

And the engineering-to-design translation is not a one-time project. It's an ongoing argument that design needs its own language, its own standards, and its own infrastructure. Building the proof is what this role is about.

✦ The context

Trade finance runs on spreadsheets, emails, and trust. None of that scales.

Fishtail is a provider of trade finance solutions, leveraging technology to enhance efficiency and transparency in global trade. I was the lead product designer for the borrower side, working alongside other designers and product managers to redesign how borrowers and trade finance managers interact with the platform.

✦ The problem

Manual processes, fragmented systems, zero visibility.

The trade finance industry was plagued by inefficient manual processes, lack of transparency, and fragmented systems. Trade finance managers and borrowers had no single source of truth — decisions were made across spreadsheets, emails, and paper documentation, leading to delays, errors, and eroded trust between stakeholders.

✦ Research

Shadowing the people doing the work, not just asking them about it.

I conducted both quantitative and qualitative research — surveys to understand frequency and severity of pain points, and interviews with trade finance managers and borrowers. I also used shadowing to observe real workflows in action, which revealed gaps that interviews alone wouldn't have surfaced. The manual, multi-system reality was worse than anyone had documented.

✦ Key findings

Four pain points, one platform to fix them.

Excessive manual workflows caused delays and errors. Lack of transparency at each step broke trust between banks and clients. Fragmented systems created confusion and inefficiency. Poor data management made it impossible to make informed decisions quickly.

✦ Design decisions

Clear information, visible progress, less friction.

Based on research findings, I focused on five core principles: display all important information clearly and simply; always show the latest trade status with key dates visible; make document review and verification easy for managers; simplify the financing request process end-to-end; and make risk assessment visible within each trade's details.

Given the complexity of both user groups' workflows, I iterated through several design options before arriving at the final flow.

✦ Prototyping & testing

"We don't need to write multiple emails anymore — it's one click."

Usability testing with both trade finance managers and borrowers validated the direction. Users were happy that the solution minimised spreadsheets and made searching for specific information fast. They appreciated the onboarding step indicator that showed progress and estimated time. Managers loved that information gathering was consolidated into one platform action instead of a chain of emails.

✦ Handoff

Phased delivery, pixel-perfect implementation.

Due to a tight timeline, handoff was phased by complexity. I worked closely with developers and the product manager to define the delivery order for each phase. Designs were fully documented with specifications, and I ran regular reviews and UI checks after each development delivery to ensure quality.

✦ The context

A marketplace that became a bank. Not everyone got the memo.

Méliuz is a startup that offers a shopping experience integrated with users' financial lives. Originally a cashback and coupons marketplace, in 2021 the company redesigned their entire app to integrate marketplace with financial services. I was the lead product designer for the payments squad, leading this and other projects alongside product managers, other squads, and developers.

✦ The problem

Users had money in the app. They couldn't spend it.

Méliuz faced a critical friction point: users couldn't use their Méliuz account balance to make purchases at checkout. This forced them to transfer funds to other banks first, breaking the experience and abandoning carts. The payment process didn't align with user expectations — leading to frustration and lost conversions.

✦ Research

The data made the case before a single pixel was designed.

I analysed data from financial services research to understand user motivations and behaviours. Key findings: 60.3% of users make online purchases frequently, 46% use online services like delivery, travel and education, and 44.9% consider cashback a deciding factor for purchases. This confirmed that a seamless, integrated payment experience wasn't a nice-to-have — it was expected.

✦ Design decisions

Fewer steps. Cashback always visible. No dead ends.

I simplified navigation, redesigned checkout components for consistency, and ensured cashback was always visible throughout the flow. I reduced the number of steps to complete a purchase, made it possible to add or edit payment methods mid-checkout without losing progress, and added the ability to deposit money into the account during a transaction.

✦ Results

Shipped June 2022. Measured for 3 months.

The new checkout launched in June 2022. Over three months of tracking, the results were clear.

✦ Handoff

Documented, reviewed, pixel-perfect.

Designs were fully documented with all specifications for development. I held regular meetings to review flows and address developer questions, and conducted UI reviews after each delivery to ensure quality implementation.