Experiential One

The Platform

What is Experiential One?

[FIG 01] EXPERIENTIAL ONE PLATFORM

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.

The Problem

What needed to be solved

For the admin program creation flow, 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.

Constraints

What shaped the approach

• 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

Research & Product Direction

Comparables, insights, and success criteria

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

To frame product positioning, I reviewed adjacent platforms students and institutions already use. The key pattern: tools exist for either opportunity discovery or HR workflow processing, but not for end-to-end internship process tracking.

My Role

What I owned across design and engineering

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 System

Building the visual foundation from scratch

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 Flow

Designing the core creation experience

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

Implementation & Workflow

From Figma to shippable code

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.

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

How design shipped through engineering

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

Validation

Stakeholder testing and what changed

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

Notes came from live reviews with career-service and employer-relations stakeholders:

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.

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.

Results & Learnings

What shipped and what I learned

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 reusable component patterns that engineers continue to use and extend.

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.

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

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.