Home/Works/Experiential One
Interaction / UX case study

Experiential One

subtitle

TypeInteraction / UX
TimelineSummer 2023 (3 mo.)
RoleProduct design intern & front-end developer
ToolsFigma, Vue, GitHub, Linear, Radix, Shadcn

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.

Experiential One platform overview — replace with exported asset.

[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.

Early wireframe explorations — replace with Figma export.

[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.

Research synthesis and flow mapping — replace with asset.

[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
Design system in Figma — replace with asset.

[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.

Mid-fidelity Figma frames — replace with asset.

[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).

High-fidelity Figma frames — replace with asset.

[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
Vue component implementation — replace with asset.

[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
Remote collaboration — replace with asset.

[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.

arrow_forward