MOSH | Team Process

Design

The design phase moved from rough structure to high-fidelity screens. This section covers wireframes, visual direction, logo work, and the Figma prototypes that guided development.

Research to Structure We translated user goals into low-fidelity wireframes and priority page flows.

Brand Alignment Moodboards and palette studies narrowed visual direction before high-fidelity design.

Prototype Validation Desktop and mobile mockups were reviewed and iterated with mentor feedback.

Wireframes

Low-fidelity structures mapped page flow, content priority, and navigation before styling decisions were finalized.

Homepage wireframe exploring search bar placement and layout options

Homepage - Search Placement Options

Mia explored where the search bar should live on the homepage, comparing a top-anchored search against an inline placement to see which felt more intuitive to users.

Homepage wireframe variant with My Items section and scrollable event feed

Homepage - My Items & Event Scroll

An alternate homepage structure put a "My Items" shelf above a scrollable event list to test whether personalized content should sit above the main feed.

Homepage wireframe showing filter controls for browsing events

Homepage - Filter Controls

A filter-forward homepage layout moved genre, date, and distance controls directly onto the home screen, so users could narrow the event feed without navigating to a dedicated search page.

Event Detail Page

The event detail wireframe mapped out the information layout before any styling decisions were made, making sure all the fields from the Ticketmaster API were accounted for.

Conversation Page

The conversation wireframe defined the message thread structure and text input placement, setting up the basic layout that would apply to both DMs and group chats.

Profile Page

The profile wireframe laid out how music preferences, past events, and social connections would be organized, giving the team a structural reference before Mia moved into high-fidelity Figma work.

1 / 6

Logo Design

The MOSH wordmark went through multiple rounds of sketching and vector refinement before landing on a letterform built directly from an audio symbol.

Sketches - Early Concepts

The first logo explorations happened on paper, with loose sketches testing letterform ideas, icon combinations, and name treatments before any digital tools were opened.

Sketches - Refined Directions

A second round of sketches pushed the strongest directions further, tightening proportions, exploring how type and symbol could relate, and narrowing toward the audio-sign concept.

Digital Explorations - Illustrator

Moving into Illustrator, Mia generated digital wordmark variants to test how different type weights and letterform modifications held up at small sizes and across light and dark backgrounds.

Audio Symbol as Letter O - Not Selected

One explored concept replaced the O in MOSH with a circular audio symbol, creating a built-in reference to sound without extra illustrative elements. This direction was considered but ultimately not chosen for the final wordmark.

Megaphone Option - Not Selected

A megaphone-based logo concept was also explored, leaning into the idea of amplification and crowd energy. Like the audio symbol direction, this option was considered during the logo process but was not selected as the final wordmark.

Logo - Color Options

With the wordmark locked, Mia tested color treatments against the brand palette across light, dark, and accent backgrounds to confirm readability in every context.

Finalized Logo

The final MOSH wordmark rendered in the shape of a speaker with orange radiating outward, combining the brand name and a core audio motif into a single icon.

1 / 7

Style Guide

The MOSH style guide codified the final color palette, typography, logo usage rules, and component decisions so design and development could stay consistent through the final build.

1 / 7

Prototype Evolution

High-fidelity prototypes translated visual direction into clickable interaction patterns, iterated across multiple rounds from initial screens to a fully revised and color-updated system.
Figma Prototype

High-fidelity Figma prototype screens showing polished MOSH UI with full color

First Hi-Fi Screens

Mia's initial high-fidelity screens applied the finalized color palette and typography to the full layout, the first time the team could see the app as a real interface.

Additional hi-fidelity Figma prototype pages showing event and discovery screens

Event & Discovery Screens

Follow-up prototype screens covered the event detail and discovery flows, giving Carter a clear reference for how the data-heavy pages should be structured and styled in React.

Figma prototype overview showing all pages in the MOSH user flow

Full User Flow Overview

A full-page prototype view laid out every screen in the MOSH flow, from home through profile, as a single scrollable reference the team used during mentor reviews and design critiques.

Figma onboarding screens showing multi-step new user flow with genre and vibe selection

Onboarding Flow

The onboarding sequence collected genre preferences and vibe settings across multiple steps before landing users on the home feed. Designed in Figma before Carter built it in React.

Updated Figma prototype screens reflecting revised color system

Color System Update

After the styleguide was finalized, Mia updated every Figma screen to match the new color system, keeping the prototype accurate for Carter's reference during the final build.

Revamped Figma prototype showing typography corrections and refined search bar component

Prototype Revamp

A full prototype pass corrected font rendering, made the search bar consistent with the rest of the icon system, and aligned spacing across pages to close the gap between Figma and the live build.

1 / 6

Development

Development turned the approved designs into a working app. This section covers React component work, feature implementation, and backend integration.

Component Foundation Reusable React components accelerated implementation across events, messaging, and profiles.

End-to-End Features Core user journeys were connected from interface actions to backend data updates.

Service Integration Authentication, database operations, and APIs were unified into stable release workflows.

Stack Decisions

Every technology choice was made to reduce boilerplate and keep the team focused on product rather than infrastructure.

React + Next.js — React gave us a component model that mapped cleanly onto a feature-rich social app: reusable cards, modals, and feed layouts could be built once and composed everywhere. We chose Next.js on top of React for its file-based routing, which meant Carter could stand up new pages quickly without wiring a separate router, and the framework's deployment story on Vercel made continuous delivery straightforward throughout the semester.

Convex — MOSH needed real-time data: group chats that update without a refresh, RSVP counts that change as users tap, and a feed that stays current. Convex gave us reactive queries out of the box, so components subscribed to data and re-rendered automatically whenever the backend changed. It also handled the database schema, serverless functions, and file storage in one platform, which meant Cooper could ship backend capabilities without standing up a separate API server or managing a database connection layer.

Clerk — Authentication is one of the hardest parts of any app to get right and one of the easiest to get wrong. We offloaded it entirely to Clerk, which gave us sign-up, sign-in, session management, and user identity out of the box with a few lines of configuration. Clerk's built-in integration with Convex meant Cooper could scope every backend query to the authenticated user without building any auth middleware from scratch.

React Prototypes

Reusable components and route-based layouts were built first to validate responsiveness and interaction behavior before deep data integration.

React prototype of the MOSH home page before CSS styling

Home Page Prototype

The first React home page focused on component scaffolding and routing, kept unstyled so Carter could verify that state, props, and navigation behavior were correct before any designs were applied.

React prototype of the event detail view showing data layout before styling

Event View Prototype

The event detail prototype confirmed that the backend data structure mapped cleanly to the component hierarchy before any visual design was applied.

React prototype of the chat interface showing message thread structure

Chat Prototype

The chat prototype established how message threads would render and update, building the real-time Convex subscription against a bare component before any UI polish started.

React prototype of the messages tab showing conversation list view

Messages Tab Prototype

The messages tab prototype laid out the conversation list view, confirming that DMs and group chats could share a single inbox before the design system was applied.

Profile Prototype

The profile prototype defined the data-to-component mapping for music preferences, vibe, interests, and group memberships, giving Cooper a clear list of which fields the backend needed to expose before the styled version was built.

1 / 5

Feature Buildout

After prototyping, complete user journeys were implemented end-to-end, progressing from component scaffolding to live backend integration and final polish before deployment.

React app showing routing-complete pages including events, messages, and group pages

Routing Complete - All Pages Live

All major pages were in place, including groups, messages, and search, with routing fully connected across the app. Components were built against placeholder data at this stage, with backend integration beginning in the following sprint.

Additional React pages including search and group views with navigation intact

Search & Groups Pages

Search and group pages were coded into the frontend alongside usability testing so the team could run real users through navigation tasks before live data was connected.

React app page showing styled components mid-integration with Figma design system

Mid-Integration - Design System Applied

Carter started applying Figma's visual system to the React components, working through the UI page by page to bring the app in line with the approved designs.

Create group page before image upload was implemented, showing the form with a placeholder

Create Group - Pre-Image Upload

An earlier state of the create group flow before image upload was wired up. The form worked for name, description, genre, and tags, with group image support added in a later sprint.

Final app screenshots after end-of-semester polish and bug fixes

Final Polish & Bug Fixes

The last sprint addressed RSVP button behavior, phone-specific layout issues, and group image upload edge cases, closing the gap between the Figma design and the live build.

1 / 5

Backend Systems

Convex and Clerk supported data and authentication layers while API integrations enabled personalized and real-time experiences.

Convex schema file defining typed tables for events, users, artists, and groups

Data Schema

Cooper's Convex schema defined every table and field type upfront, covering events, users, artists, venues, and groups, giving Carter and Mia a clear data contract to build against from the start.

Backend Functions

The Convex functions doc listed every query and mutation available to the frontend. Carter used it to wire components and Cooper used it to track which backend capabilities still needed to be built.

Convex dashboard showing the events table populated with real concert data

Events Data in Convex

The events table populated with real Ticketmaster concert data, the first real data milestone. Seeing actual shows in the database confirmed the API import pipeline was working.

Convex dashboard showing artists imported and linked to event records

Artist Data Import

Artist records were imported and linked to their corresponding event entries in Convex, completing the data model that drove the event detail page's lineup section.

Convex dashboard showing venue records with location and address data

Venue Data

Venue records captured location, address, and capacity data from the Ticketmaster import, giving the event detail page the location info it needed.

Convex function code for getUpcomingShows showing query logic and return shape

getUpcomingShows Function

The getUpcomingShows query was one of the most-used backend functions, filtering and sorting events by date to keep the home feed showing current concerts.

1 / 6

Final Product

MOSH launched at mosh-social.com as a deployed social app for concert-goers. These screenshots show the live app across its core features.

Event Discovery Real Ticketmaster data powers the home feed, event cards, and RSVP flow.

Social Features Real-time messaging, group creation, and friend connections built on Convex.

Personalization Profiles reflect genre preferences, concert vibe, and group memberships.

Events, Messaging & Groups

Events, messaging, and groups running on live backend data.

MOSH home and events feed showing live concert data from the Ticketmaster API

Home & Events Feed

The home feed and events tab pulling live concert data from the Ticketmaster-powered backend, the first time the app showed real shows instead of placeholder content.

Event Card

The event card showed the key details for a show: name, date, venue, and a one-tap RSVP, designed to be readable in a feed without extra noise.

People going section and event feed posts showing social activity around a concert

Social Activity - People Going

The "people going" section showed which friends and group members had RSVPed to the same event, making it easy to coordinate around shows.

MOSH DMs page showing all active conversations in a unified list

DMs - All Conversations

The DMs page listed every active conversation in one place, both direct messages and group chats, with real-time unread indicators.

Group Chat

Group chat messages delivered instantly to every member. Convex real-time subscriptions pushed new messages to all connected clients without any polling or page refresh needed.

Create Group

The create group form collected name, description, genre, and tags, the same fields the search ranking system used to match users to groups, so new groups showed up in search right away.

Group page from a regular member's perspective showing feed and join controls

Group Page - Member View

Regular group members saw the group feed, shared events, and the member list, a simpler view than the admin version focused on what matters once you've already joined.

Manage group page showing admin controls for member requests and group settings

Manage Group - Admin Controls

Group admins had a management page where they could accept member requests, update group details, and control who could invite others, a role-based view that reused most of the same components as the member view.

Second manage group page view showing additional admin settings and member list management

Manage Group - Member List

A second admin view showed the full member list with options to remove members and manage pending invites.

Message Request Component

Before a DM thread opened, recipients saw a message request so they could accept or decline contact from people outside their friend network.

1 / 10

Profiles, Search & Onboarding

User profiles, search, and onboarding flow for the MOSH app.

Onboarding screen for selecting favorite artists to seed music preferences

Onboarding - Favorite Artists

Users selected their favorite artists during onboarding, seeding the taste profile used for search ranking and group recommendations from day one.

Onboarding screen for selecting hobbies and interests beyond music

Onboarding - Hobbies & Interests

Beyond music taste, onboarding captured broader hobbies and interests so the profile reflected more than genre preference and helped users find others with common interests.

Onboarding screen for picking concert show vibe preferences

Onboarding - Show Vibe

The show vibe picker asked new users how they like to experience concerts, front row energy, laid-back observer, mosh pit, and more, to help match them with other users who go to shows the same way.

Settings & Profile Editing

The settings page let users update their name, username, location, music preferences, concert vibe, and interests. Changes fed directly into search ranking and home feed recommendations.

Other User's Profile

Viewing another user's profile showed their public preferences and shared group memberships so you could get a sense of someone before sending a friend request.

MOSH search results showing matched users and groups based on query

Search - People & Groups

Searching for people and groups returned results ranked by compatibility score, with the backend weighing genre overlap, shared tags, and mutual connections.

Event Search

With a query filled in, the event search returned real concerts filtered from the Ticketmaster-populated database so users could find specific shows by name, artist, or genre.

1 / 7

App Renders

High-fidelity renders showing the final MOSH UI across key screens.

Home Screen

Event Page

Messages

Profile Tab

1 / 4

Demo Video

A walkthrough of the full MOSH experience.

Testing

User testing ran throughout the project, not just at the end. Usability sessions and structured QA cycles happened in parallel with design and development, and findings fed directly back into both.

Usability Rounds Real users completed scenario-based tasks during design and development, not just at the end.

Feedback Loop Findings were prioritized and mapped directly to design and development action items.

Final QA Checks Pre-delivery reviews verified consistency, reliability, and presentation readiness.

Usability Testing Rounds

Participants completed key user tasks while the team captured friction points in discoverability, interaction speed, and navigation clarity.

Experience Map

The team mapped a concert-goer's full journey from first hearing about a show through the post-event experience, identifying emotional highs, friction points, and where MOSH could add value.

User persona for Aidan, built from a real usability interview participant

User Persona - Aidan

Aidan's persona was built from a real interview participant, capturing his concert habits, frustrations with existing apps, and goals in his own words to keep the team grounded in a real user throughout design decisions.

User persona for Connor, built from a real usability interview participant

User Persona - Connor

Connor's persona showed a different type of concert-goer, with different discovery habits and social motivations that pushed the team to design for a wider range of users than one persona alone would have covered.

1 / 3

Round 1 - Wireframe A/B Testing & In-Person Interviews

Mia distributed a Google Form to gather early feedback on wireframe layout options across the home, event, DM, and profile pages. The most-liked layouts were used as the baseline for the first Figma prototype. She then conducted 10 in-person usability sessions, watching participants work through the prototype with minimal instruction. Key findings:

Users understood the core concept (concert-focused social app) but felt slightly unsure where to start.
Navigation was mostly clear, but labels and icons needed improvement, particularly around Community vs. Groups.
Most users expected to click an event card first and then message or coordinate from there.
A simple onboarding flow was flagged as missing, users wanted a "start here" moment.

Round 2 - Hi-Fi Prototype Video Interviews

Two structured video interviews were conducted with the high-fidelity Figma prototype. Both participants were in their mid-20s and had recently moved to a new city, matching the target audience. Key feedback from each:

Connor: Liked the event marking (Interested/Going) and group chat features. Noted that clicking a group from "My Items" should go to the DMs rather than the group profile. Found the + button for creating a new group unclear. Wanted a ticket link on the event page.
Aidan: Liked the public/private visibility for "People Going." Wanted photo albums tied to events. Suggested separating groups you administer from groups you're just a member of. Found the home page search functionality unclear at first glance.

Round 3 - Broader Usability Survey

A third round used a structured form and captured responses from a larger group of participants. The pattern was consistent: users understood the general concept but needed more clarity about what to do first and what each section was for. The biggest friction points were not missing features but clarity gaps in labeling, navigation, and information hierarchy. What worked well: event pages were easy to scan, the combination of DMs and group chat was a consistent positive, and the core concept of meeting people at the same show resonated strongly.

Mentor Reviews

Four structured sessions were scheduled across the semester with outside reviewers covering frontend development, professional design, branding, and UX. Each session produced direct, actionable feedback that was folded into the next sprint.

Peter Rosenthal

Frontend/web development instructor at ATLAS. Reviewed the Figma prototype with the full team.

Peter noted that the Groups section on the home page wasn't visually prominent enough to draw users in. He flagged that clickable elements in the profile (groups, friends) didn't clearly communicate that they were interactive. The search component was described as too dense for mobile, and he suggested a collapsed search bar that expands on tap. His overall read was positive: solid foundation, features were well thought through, and the web app direction made sense.

Cade Dannels

Head developer at The Colorado Floor Company. Reviewed the prototype with Mia.

Cade responded positively to the "Groups Going" feature, calling it a strong differentiator for the target audience (young adults new to a city looking to meet people). He wanted more color on the event detail page and suggested filtering by venue and location since the prototype was heavily Red Rocks-centric. He also echoed Peter's note that the groups and friends sections on the profile needed clearer affordances to show they were tappable.

Joel Swanson

Branding and visual identity instructor at ATLAS. Reviewed early logo sketches and the Figma prototype with Mia.

Joel's main branding guidance was to lean into the word MOSH itself, work with rounded letterforms to match its softer sound, and consider a circular motif referencing the pit. He advised removing black outlines from the prototype UI, being more consistent with angles across components, and going bolder with the color palette. He also recommended a branding packet of around 7 pages covering lockups and usage examples.

Brittney Urich VanHorssen

UX design professor at ATLAS. Reviewed UX design and branding with Mia.

Brittney's primary feedback was that the color palette had too many colors and advised consolidating to shades of a single color with orange as the accent. She flagged several component-level issues: the nav bar needed labels, tags should be outlined rather than filled, icons needed to be a consistent size from a single icon set, and a four-column grid should be applied in Figma to tighten layout consistency. She also noted that profile tags should be reversed and that the settings page styling needed adjustment.