top of page

Marketplace turned mobile: Applying to classes anywhere, anytime

I designed Elevate’s first ever mobile screens, bringing the Teacher Marketplace to phones for the very first time. Working closely with a PM and engineers, we scoped and shipped an MVP in just two months that transformed a desktop only experience into a responsive, mobile ready product, helping teachers apply faster and with fewer missed opportunities.

mobile2.png
Your paragraph text (43).png

Sole Product Designer

Jun - Sep 2024

Current marketplace experience

Elevate teachers build their schedules by applying to teach classes offered by different schools. The Marketplace was only available on desktop, and securing a class was first come, first served.

Teachers often felt anxious throughout the day that they were missing opportunities. Many stayed glued to their computers in fear of losing work, while others tried shrinking the site in a phone browser. But the table-based format wasn’t designed for small screens, scrolling, zooming, and misplaced buttons made the process frustrating and unreliable.

problem

Teachers choose to work at Elevate because they want flexibility and control over their schedules but the current Marketplace left them feeling stuck and anxious instead. Elevate teachers needed a simple, reliable way to browse and apply for classes on the go.

Our challenge was to design Elevate’s first-ever mobile experience in just two months, one that would be usable, scalable, and delightful no matter the screen size.

My role

Sole designer (with 1 design director, 3 engineers, 1 PM).

Scoped the MVP alongside PM and engineering to meet a tight timeline, designed responsive, card based layouts optimized for smaller screens, collaborating closely with engineers to define breakpoints and ensure feasibility, running usability tests with teachers to validate clarity, accessibility, and speed on mobile

Process

1. Scoping the MVP

With only two months to launch, I worked with our PM and engineers to define the minimum flows needed for mobile. We prioritized three essentials, browse, view details, and apply. We pushed non-critical features like advanced filters to later releases. This allowed us to move quickly towards the initial launch without blocking teachers from applying on the go.

2. Designing for Mobile First

The Marketplace was already designed with mobile in mind during the desktop redesign ([click here to see that project!]). When it came time to bring it to phones, this foundation allowed us to move quickly while still ensuring a smooth experience.

🤝 Partnering with engineering on breakpoints and APIs

I worked closely with engineers from the start to define responsive breakpoints and confirm screen sizes across devices. We also checked that the mobile layouts would work smoothly with existing APIs, preventing surprises late in development.

2.png

📲 Translating marketplace designs to mobile

I worked closely with engineers from the start to define responsive breakpoints and confirm screen sizes across devices. We also checked that the mobile layouts would work smoothly with existing APIs, preventing surprises late in development.

Frame 101.png

🖌️ Extending mobile redesign to unaddressed screens

Some flows hadn’t been addressed in the earlier desktop redesign, so they needed to be created from scratch for mobile. I designed these screens to fit smaller layouts while still following the structure of the desktop designs. This approach kept the codebase stable, ensured consistency across platforms, and gave teachers a complete end-to-end mobile experience.

3.png

3. Testing with Teachers

Even on a short timeline, I made space to validate the designs with teachers. We tested prototypes with 20 teachers, and all of them were able to find the correct class and complete an application on their phones. Their feedback confirmed that the card based layouts made browsing much clearer on small screens. Several noted that the flow felt faster and more natural than forcing desktop into a phone browser, and that because it mirrored the desktop experience, it was immediately familiar and easy to follow.

4.png

One recurring pain point was the calendar: teachers found it difficult to view selected classes alongside their current schedules. Because we were tied to a limited third party API, I couldn’t make significant changes within the project’s scope. Instead, I documented the feedback and shared it with the PM team as a future opportunity to explore alternative APIs that would better support teachers.

Impact at launch

42% of applications

submitted via mobile within the first 2 months

2.3× faster

average time to apply on mobile vs. desktop

90% completion rate

applied on mobile finished successfully

Key learnings

This project reinforced for me that communication is one of the most powerful design tools. With only two months to launch, I made it a habit to ask engineers questions early and often, even if they felt small. That openness helped us catch potential blockers before they grew and kept the team moving quickly. It showed me that collaboration isn’t just about alignment at the end, it’s about building momentum through constant dialogue.

I also learned the value of designing with a systems mindset. Because we had scoped for mobile during the earlier desktop Marketplace redesign, we didn’t need to start from scratch. That foresight cut down rework, kept the team lean, and proved how much efficiency comes from thinking ahead about scalability.

Looking forward, I see opportunities to take the experience further. Screens like success and confirmation could be elevated to feel more enterprise-grade, giving teachers software that looks as professional as the work they do. And rethinking the calendar could unlock even more value, turning what was once a pain point into a tool that helps teachers manage their schedules with confidence.

bottom of page