Part 1 — Discovery & strategy
Designing and building Experiential One's entire platform from 0-to-1
As the only design intern at Experiential One, I designed and built the complete platform for students, advisors, and admins—creating the design system, user flows, mid-fi and hi-fi Figma frames, then implementing working Vue components that enabled user testing with partner institutions. This case study focuses on the admin program creation flow as a representative example of my end-to-end process.

[FIG 01] EXPERIENTIAL ONE PLATFORM
Overview
Experiential One is building the first successful experiential learning management tool for higher education. The platform helps institutions create, manage, and track experiential learning programs—replacing scattered spreadsheets with a centralized system.
I designed and built the entire platform—student flows for discovering and tracking opportunities, advisor flows for managing students, and admin flows for creating programs and generating reports. This case study deep-dives into the admin program creation flow as a representative example of my design and development process.
Project details
Role — Product Design Intern & Front-End Developer
Timeline — Summer 2023 (3 months)
Team structure
Design — Nikki Martinez (Founder/Designer), me (design intern)
Engineering — Michael Oelbaum, Iosefa Percival, Albin Liang, Amuel Chong, Alejandra, Ichi
Tools — Figma · Vue · GitHub · Linear · Radix UI · Shadcn
Roles and responsibilities
As the only design intern on a 2-person design team, I worked directly with founder Nikki Martinez to design and ship the entire Experiential One platform from scratch. This meant wearing both the designer and developer hats across all user types.
Design work
- Complete design system from Radix UI primitives and Shadcn tokens
- User flows for students, advisors, and admins
- Mid-fi and hi-fi Figma frames for all core flows
- Multi-role navigation, dashboards, and data visualization
Development work
- Implemented all designs in Vue front-end
- Built reusable component library from design system
- Collaborated with 6 engineers via GitHub pull requests
- Tracked work in Linear and participated in code reviews
Collaboration
- Weekly design critiques with Nikki on system-level decisions
- Daily standups with engineering team
- User interviews and testing with partner institutions
The challenge
For the admin program creation flow specifically, the challenge was designing a multi-step form that felt intuitive while capturing all necessary data: program name, duration, cohort size, approval workflows, learning objectives, and assessment criteria.
Admins needed flexibility (every institution structures programs differently) but also guardrails to ensure data quality for reporting.

[FIG 02] EARLY WIREFRAME EXPLORATIONS
Constraints
- Early-stage startup with evolving product scope and limited time per release
- No previous product or design system to inherit—everything built from scratch
- Support multiple user types with different needs in a single platform
- Shared codebase with existing Material UI patterns while building a new component approach
Success criteria
- 01 — Define a foundational design system reusable across all user types
- 02 — Design role-appropriate views that feel distinct yet cohesive
- 03 — Build working Vue demos with real validation logic for user testing
- 04 — Ship production-ready code that engineers can extend
Research & discovery
Interviewed institutional admins to understand how they currently set up experiential learning programs. Most were using a combination of spreadsheets, email chains, and manual data entry.
Identified key data points needed for program creation: program name, duration, cohort size, approval workflows, learning objectives, and assessment criteria. Admins needed flexibility for institutional differences but also guardrails to ensure data quality for reporting.

[FIG 03] RESEARCH SYNTHESIS & FLOW MAPPING
Key insights
Insight 01
Admins found long single-page forms overwhelming—breaking the flow into logical steps reduces errors and abandonment.
Insight 02
Real-time validation was critical—admins wanted to know immediately if a program name was already taken or if required fields were missing.
Insight 03
Users needed to save drafts and return later—not all program details would be finalized in one session.
Part 2 — Design & build
Design System Foundation
Because Experiential One was new, there was no legacy UI to inherit. I created a complete design system from scratch that would work across student, advisor, and admin experiences.
Workflow: Designed components in Figma with all variants documented → Built Vue components from Radix primitives → Synced design and code as edge cases emerged.
Core component library
- Navigation & layouts
- Data tables & filters
- Form inputs & validation
- Multi-step patterns
- Status indicators
- Dashboards & cards
- Modal dialogs
- Empty states

[FIG 04] DESIGN SYSTEM IN FIGMA
Admin program creation flow
“Instead of creating interactive Figma prototypes, we moved directly to implementation—shipping working code faster than linking 50+ frames with complex conditional logic.”
Step 1 — Mid-fidelity explorations: Created static Figma frames to map out the multi-step flow, field requirements, and core structure. Kept fidelity low to iterate quickly on information architecture.

[FIG 05] MID-FIDELITY FIGMA FRAMES
Step 2 — High-fidelity design: Refined screens with design system components, final copy, validation states, and visual polish. Documented all interaction states (default, focus, error, disabled, loading).

[FIG 06] HIGH-FIDELITY FIGMA FRAMES
Step 3 — Building in Vue: Instead of creating interactive Figma prototypes, I moved directly to implementation. Collaborated with engineers to build the working flow in Vue, which became the demo for user testing.
Why skip prototyping?
- Faster to build real code than link 50+ Figma frames with complex logic
- Needed actual form validation and state management for realistic testing
- Engineers could iterate on working code immediately
- Startup velocity—ship to learn, not perfect before launch
Implementing in Vue
After creating hi-fi Figma designs, I implemented the entire platform in Vue—including the program creation flow showcased here. Worked closely with the engineering team via GitHub and Linear.
Workflow
- 01 — Pulled tasks from Linear board
- 02 — Created feature branches in GitHub
- 03 — Built components matching Figma specs
- 04 — Submitted pull requests for engineer review
- 05 — Iterated based on code review feedback
- 06 — Merged to main branch for testing
Real-time design decisions
Since I was implementing my own designs, I could make adjustments when code revealed constraints:
- Simplified a 7-step flow to 5 steps due to state management complexity
- Adjusted validation timing based on API response patterns
- Modified layouts when data structures didn’t match initial assumptions
- Unified patterns across student/advisor/admin views for consistency

[FIG 07] VUE COMPONENT IMPLEMENTATION
Team collaboration
Working with Nikki (founder/designer)
As the only design intern, I had direct access to Nikki for strategic decisions:
- Weekly design critiques of Figma work across all user types
- Validating component patterns and system-level decisions
- Strategic alignment on feature prioritization
Working with engineers
Collaborated daily with the 6-person engineering team:
- Stand-ups to align on progress and blockers
- Pairing sessions to solve tricky implementation problems
- Code reviews (both giving and receiving feedback)
- GitHub discussions on technical tradeoffs

[FIG 08] REMOTE COLLABORATION
Part 3 — Enabling validation
Enabling user testing
I wasn’t directly involved in the user testing sessions themselves, but my role was to initialize the flows and set up the foundation that made testing possible.
The working demo allowed testers to:
- Experience actual form validation and error states
- Navigate through a multi-step flow with real state persistence
- Test edge cases that wouldn’t appear in static prototypes
- Provide feedback on actual interaction patterns, not hypothetical ones
Key learning: Building working demos instead of Figma prototypes meant user testing revealed real technical constraints early—helping the team make better product decisions before full production development.
Handoff & iteration
After user testing, the engineering team continued building on the foundation I’d established. Because I’d already implemented the core components and patterns in Vue, the transition was seamless. For dev handoffs, I redlined specs and Figma—calling out spacing, states, and edge cases so implementation stayed aligned with design intent.
The demos became production code—engineers extended my work rather than rebuilding from scratch. Redlining plus working code in the repo kept feedback concrete: less ambiguity in tickets, faster fixes when something drifted. That tight loop between design and implementation outpaced typical one-way design-to-dev handoffs.
Part 4 — Impact & learnings
Outcomes & impact
Metrics
- 3 — User types designed for
- 50+ — Reusable components
- 100% — Demos became production
Key achievements
- Shipped complete platform with student, advisor, and admin flows
- Created comprehensive design system used across all user types
- Enabled user testing with partner institutions via working demos
- Contributed production code via GitHub PRs using professional engineering workflows
- Established component patterns that engineers continue to use and extend
Reflection
Hybrid designer/developer on a multi-role platform
Being both designer and developer forced me to think about feasibility constantly. I couldn’t design something beautiful and throw it over the wall—I had to build it myself. This constraint actually improved my design decisions because I was always considering implementation complexity.
Designing for multiple user types (students, advisors, admins) taught me to think systematically. Each role needed tailored experiences, but they all had to feel like part of the same product. The design system was critical for maintaining this cohesion while allowing role-specific customization.
Small startup team dynamics
As the only design intern working with Nikki, I had significant ownership over the entire platform. This was empowering (real impact, direct founder access, high responsibility) but also challenging (less day-to-day design mentorship, more self-direction required). Using professional engineering workflows like GitHub and Linear taught me to communicate design decisions in technical terms and ship incrementally.
When to code vs. when to prototype
This hybrid approach taught me when to prototype vs. when to code. For simple flows, Figma prototypes are perfect. For complex, stateful interactions (like multi-step forms with validation), building the real thing is often faster and more valuable.
Benefits
- Real constraints surface earlier
- Engineers work with actual code
- Faster iteration cycles
Challenges
- Harder to test multiple directions
- Changes require code edits
- Need both skill sets
What I'd improve
- More structured user research: A more formal research phase with recorded sessions and structured synthesis would have revealed deeper insights about how the different user types interact with the platform.
- Earlier accessibility testing: While we used Radix UI primitives (which have good accessibility defaults), we should have tested with screen readers and keyboard navigation earlier in the process.
- Better documentation: The fast pace meant some design decisions weren’t documented well. Future teams would benefit from more thorough rationale for system-level patterns and component variants.
Final thoughts
This internship taught me that shipping is learning. By building working demos instead of just designing screens, I learned more about product design in 3 months than I could have from Figma alone—especially when designing for multiple user types with different needs.
Being the only design intern on a startup team meant high responsibility and autonomy. I had to identify problems across the entire platform, propose solutions that worked for all user types, design them, build them, and validate them with real institutions.
The platform I initialized—from design system through student, advisor, and admin flows—became the foundation for user testing and eventually production. It proved that sometimes the fastest path from 0-to-1 design to validation is through code.