work resume
about

LANDY MANZANERO

A product designer and engineer inspired by connection. Building technologies that feel intuitive, inclusive, and human.

←
→
About Me

Hi, I'm Landy. I believe the best products are built with both empathy and intention.

A first-generation hispanic designer studying Electrical Engineering and Computer Sciences at UC Berkeley, passionate about creating human-centered products that make complex systems feel simple and accessible! Growing up, I learned how powerful thoughtful design can be, especially when technology becomes a bridge rather than a barrier.

My work lives at the intersection of empathy and technical problem-solving. I'm drawn to projects that prioritize real people, meaningful connection, and long-term impact.

Outside of design, you can find me at the gym, trying out new recipes in the kitchen, and getting lost in Substack essays that challenge how I think!

Landy

Creatives

Adobe Figma Notion UX Research Prototyping Wire-framing Product Strategy Storytelling Interaction Design Visual Design Design Systems Web Design

Technicals

React HTML/CSS C++ Java Python Swift Node.js Git Expo SQL AI/ML
Work
CommonWealth Bank
Anna Freud
Baro Behavior
SUR
Salamati

Choose a project from the left to open its case study.

Overview
Research
Synthesis
Personas
Ideation
Prototype
Impact

COMMONWEALTH BANK • UX REDESIGN 2025

Commonwealth Bank

Redesigning a developer-first payments portal experience.

Role

Product Designer

Timeline

August – December 2025

Team

1 PM
4 Designers

Skills

User Research
Product Strategy
Prototyping

Overview

Commonwealth Bank (CommBank) is Australia's largest financial institution, serving 17M+ customers across transaction banking services.

The Payments Team's product, PaaS (Payments-as-a-Service), is a suite of APIs that makes connecting directly with CommBank's payment infrastructure seamless and cost-effective for corporate clients.

CommBank's goal is to build a developer-first PaaS platform to drive adoption in an increasingly competitive landscape. Thus, we partnered with the Payments team to explore:

How might we, corporate payments, learn from developer-first platforms like Twilio, Stripe, and Snowflake?

Research

Competitive Analysis

We benchmarked five leading API providers to identify what defines best-in-class developer experience (DevEx). With that, we examined tools, features, and services that address common user concerns.

Competitive analysis logos

User Interviews

We spoke with 10+ engineers and developers from companies like Google, Oracle, and IBM. From those conversations, we identified key factors that drive platform adoption: what developers value in third-party systems, what builds trust, and where onboarding friction occurs.

Initial Findings

Documentation

Poor documentation leads to unnecessary trial-and-error during onboarding

Integration

APIs that plug in and test quickly are preferred; issues arise when failure points are unclear

Security

Strong security builds trust, though required steps can slow development

Customer Support

Fast, reliable responses significantly improve DevEx

Synthesis

We organized all our research data based on common patterns to uncover salient themes worth addressing further.

Affinity Mapping

Afterwards, we ran several rounds of iteration to develop the following key insights and focus areas:

Developers Prioritize

Self-Sufficient Documentation

Clear, comprehensive docs that answer questions without requiring support

External Integration Experience

Smooth handoffs between systems with clear integration paths

Use Case Flexibility

APIs that adapt to diverse implementation scenarios

Security First

Robust security without sacrificing developer experience

Smooth Hand-Off

Clear transitions between discovery, implementation, and deployment

Building User Dependency

Creating lasting value that keeps developers engaged

Personas

After synthesizing our findings, we defined two primary personas and mapped their journeys to pinpoint where trust breaks and onboarding friction appears.

User Personas

User Journey Maps

We mapped the complete journey for both personas to identify pain points and opportunities.

Ideation

Based on our research synthesis, we conducted ideation sessions to explore solutions across the key focus areas:

Prioritization

We used a 4x4 impact–effort matrix to prioritize what to build first.

High Priority Features

Personalized Onboarding

A short questionnaire that creates an adaptive guide through the portal

Interactive Testing

An embedded sandbox where developers can experiment safely

Learning Hub

A unified dashboard for tutorials, guides, and documentation

Notifications

A centralized hub for changes, updates, and news

User Flow

We mapped the complete user flow from landing page through onboarding to specific API implementation.

Prototype

We created high-fidelity prototypes of the redesigned developer portal, following the journey from first landing on the site to deep integration.

Impact

Key Takeaways

Self-Sufficient Documentation
Developers want clear, consistent, and complete documentation so they can understand how an API works quickly, integrate it smoothly, and focus on building features instead of debugging or seeking help.

Smooth Hand-Off
Consistent coding styles, naming conventions, and readable patterns minimize confusion and make large, multi-team API ecosystems easier to maintain.

External Integration Experience
Teams often struggle to integrate external APIs because poor documentation, unclear ownership, and uncertain compatibility with business or legal needs make them difficult to trust and maintain.

Use Case Flexibility
Developers value APIs that empower innovation by adapting to their products and workflows, rather than limiting creativity through rigid structures or narrow functionality.

Security First
Developers seek to find trustworthy and reliable APIs that can deal with multiple tasks simultaneously while demonstrating basic security standards like authentication, encryption, and token protocols without risking security vulnerabilities.

Developing User Trust
Developers gain confidence in APIs that demonstrate dependable performance through consistent uptime, clear rate limits, and proactive communication about changes.

Outcome

Clearer onboarding
Reduced ambiguity around “what do I do next?” through guided entry points and curated learning paths.

Stronger trust signals
Made security, reliability, and support expectations legible earlier in the journey.

Faster time-to-first-success
Enabled quicker testing and iteration via interactive documentation patterns.

Overview
Research
Synthesis
Personas
Ideation
Prototype
Impact

ANNA FREUD • PROJECT 2025

Anna Freud

Designing a clearer discovery experience for mental health resources with an AI-assisted workflow.

Role

Product Designer

Timeline

January–May 2025

Team

1 PM
4 Designers

Skills

Research
UX Strategy
Prototyping

Overview

How might we provide young people and their families easier access to trusted information about mental health?

The Anna Freud Centre provides resources supporting child and family mental health. This project focused on reducing friction in discovery and helping users feel confident they’re finding trustworthy, accurate guidance.

Research

Secondary Research

We reviewed patterns and constraints around mental health information seeking, especially trust, accuracy, and sensitive user needs. We looked at platforms like earkick, Reach RX, and Sonar.

Survey

Objective

Understand barriers to accessing mental health resources.

Target Demographics

Ages 12–17, 18–22, 23–30, 30+.

Participants

Parents, kids, and young adults.

Interviews

Methods

Survey respondents who opted in for an interview.

Testing Process

15–20 minute interviews.

Procedure

Participants were given background context, then prompted to answer a set of qualitative questions.

Themes We Focused On

Parent confidence + addressing support needs, trust & perception of AI, and barriers to accessing mental health resources.

Interview Goals

Understand pain points in current experiences, identify indicators of trust and accessibility, and assess perception of AI in health care.

Usability Tests

Goals

Evaluate effectiveness of resource design, understand navigational preferences, and analyze usage habits.

Method

Prompt interviewees to answer a standardized set of questions to understand design and navigation flow preferences.

Tested On

Resources suggested by survey responses.

Testing Duration 10–15 minutes

Before Testing

A small set of questions to understand usage habits of familiar resources.

During Testing

While screen-sharing, users walk through and answer questions for a new resource.

Post Testing

Questions about the experience of navigating the new resource.

Synthesis

We worked to understand users through affinity mapping, connecting themes across clusters to identify the strongest signals.

Key Insights

Across the research, three things mattered most: personalized guidance, trustworthy sources, and accurate information.

Preferred Features for Online Resources

Users want quick ways to narrow and find relevant information without information overload.

Visual & Functional Elements

Clarity comes from scannable layouts, simple language, and obvious next steps.

Resource Utilization & Challenges

Search is often fragmented across many places; switching costs reduce follow-through.

Mental Health Needs

Support needs vary. Users look for reassurance, guidance, and credible routes to help.

Perception of AI in Mental Health Resources

AI is accepted when it’s transparent, grounded in trusted sources, and not “diagnosing”.

Comfort with AI in Seeking Mental Health Support

Comfort increases when the user stays in control and can verify sources.

Primary Support Network

Parents/caregivers and peers influence what resources feel safe to try.

Frequency & Comfort in Mental Health Discussions

Language should reduce stigma and make it easier to start the conversation.

Personas

We captured two core personas, Karly and James, representing different levels of familiarity and support needs.

Ideation

We translated insights into opportunity statements and explored solutions that improved clarity without sacrificing trust.

How Might We

We reframed the problem into actionable “How might we” prompts that balanced sensitivity, clarity, and trust.

Brainstorming

Prototype

We prototyped an “Ask Anna” experience that supports browsing, saving, and returning to curated resources without overwhelming users.

Impact

Lowered the barrier to discovery

Multiple entry points for “I don’t know what to search”.

Increased repeatability

Collections + save flows support returning users.

Maintained trust

Content remains grounded in curated resources rather than open-ended answers.

Overview
Tech Stack
Scope
Architecture
What I Learned

BARO • BEHAVIOR INTERVENTION PLATFORM

BARO

Role

Engineering Lead / Full-Stack Developer

Timeline

October 2025 – December 2025

Team

6 engineers (led & mentored)

Skills

Full-Stack · Auth · Supabase · Leadership

I led development of a user-centered web platform that helps teachers onboard students, structure intervention workflows, and securely manage behavior-support data.

Overview

BARO is a web platform designed to support K–12 educators with evidence-based behavior interventions for individual students. The product separates teacher and student experiences, enables secure access, and creates a structured onboarding flow to collect student info and map behavioral needs into a decision-tree foundation for intervention recommendations.

Tech Stack

React TypeScript JavaScript Supabase PostgreSQL Google OAuth GitHub

What I Built (Scope)

My implementation covered Milestone 1, Milestone 2, and partial Milestone 3.

Milestone 1 — Teacher + Student Account Creation and Login

Delivered:

  • Teacher account creation and login (email/password and Google OAuth)
  • Secure authentication flows
  • Student login mechanism using unique codes generated after teacher setup
  • Foundation for adding a student to a class using a class code

Milestone 2 — Teacher + Student Dashboard Structure

Delivered:

  • Teacher and student dashboard foundations
  • Sidebar navigation structure with major sections and tabs
  • Base routing for role-based dashboards (Teacher lands on Prep with student cards; Student sees welcome message and lands on Prep)

Milestone 3 (Partial) — Teacher Prep Tab Pages

Contributed:

  • Backend/data foundations to support teacher-led student onboarding steps
  • Early integration points for behavior categorization and behavior prioritization workflow
  • Data modeling considerations for storing behavior-tree selections

Architecture (High-Level)

Frontend

Web application with role-based routing and dashboard experiences.

Backend

Supabase (PostgreSQL) used for teacher login information, student login codes, and behavior tree data storage.

Authentication

Google OAuth for teacher login; secure session handling; role-based access control patterns.

What I Learned

  • Building authentication and data modeling early determines the reliability of the entire product
  • Technical leadership is as much about clarity and systems as it is about shipping code
  • Translating domain logic (behavior interventions) into structured data requires tight iteration with stakeholders