Navigating Ambiguity, Building Systems, and Designing for Trust

This project pushed me to balance vision and pragmatism—working with early-stage ambiguity, limited resources, and a new AI-driven paradigm. As a founding designer, I had to build not only the product but also the design culture, systems, and methods that guided it.

🤖 AI Integration & Human-Centered Balance

When you’re designing an AI coach, trust becomes the real design problem.

The AI had to feel intelligent but not intrusive—empathetic but credible. Early prototypes leaned too “techy,” making users question authenticity.

What I Did:

• Used AI for early-stage ideation and divergent UI flows, but relied on human sense-making for final design quality.

• Crafted transparent microcopy (“why this was suggested”) to humanize AI outputs.

• Created explainable feedback loops where the user could correct or guide the AI, reinforcing agency.

• Validated tone and behavior through qualitative usability tests to ensure the system felt like a partner, not a manager.

What I Learned

AI design is less about automation and more about relationship design — shaping trust, tone, and control in every interaction.

🎨 Systematizing Design in Chaos

TAIWA started without a design system or established conventions. Every new screen required rethinking patterns, components, and structure. This chaos forced me to balance creative speed with long-term consistency.

What I Did

• Established an early design language- typography, grid, color, and motion principles- that scaled across mobile and web.

• Built component libraries in Figma for repeatability (inputs, tabs, dashboard modules).

• Documented component behavior and states in Notion, enabling engineers to replicate intent without misinterpretation.

• Prioritized usability over visual novelty- ensuring the system could evolve without breaking patterns.

What I Learned

A design system isn’t a luxury in startups- it’s a survival tool. It allowed us to ship faster, onboard engineers faster, and make our product feel cohesive even before it was fully.

🧩 Working Cross-Functionally in a Lean Team

As the only designer, I often played the role of PM, researcher, and design advocate.

There were no precedents, no QA gates, and sometimes no shared language between design and engineering.

What I Did

• Implemented weekly async design reviews in Notion to ensure alignment despite time zones.

• Created handoff documentation that included interaction notes, edge cases, and rationale, not just visuals.

• Used low-code prototypes to help engineers visualize intent before committing to dev cycles.

• Fostered collaboration by treating every stakeholder- from engineer to coach advisor- as a design partner.

What I Learned

Influence in small teams is about clarity, communication, and follow-through.

💡 Key Learnings

AI as a Design Partner

AI speeds up ideation, but only if you design guardrails that keep human judgment central. The designer’s role becomes director and creator.

Prioritization Under Constraints

I learned to ship lean versions of features that teach us something, rather than perfect solutions that teach us nothing.

Designing for Trust

Doesn't matter whether it’s AI or human coaching; users give trust only when systems are transparent, consistent, and kind.

📈 Continuous Improvement

After the core TAIWA product launch, I continued refining patterns and usability based on feedback.

• Introduced contextual micro-interactions that reduced onboarding friction.

• Standardized layout and spacing rules across dashboards for faster scanning.

• Advocated for data storytelling- turning analytics into narrative rather than charts.

“Working on TAIWA taught me that real innovation is about making complex systems feel human.”