Assume Chat
Web App
0 -> 1
Reducing Social Friction in a Campus Chat Platform
Project Overview
AssumeChat is a responsive web platform designed to facilitate real-time, spontaneous conversations exclusively among verified college students. Inspired by the serendipity of platforms like Omegle, the product aims to go further — building a space that is campus exclusive, safety-conscious, and anchored in a distinctive social mechanic: assumption-based interaction.
Timeline & Goal
2 months to design a full product — onboarding, connection, and post-chat flows.
My Role
Solo UI/UX Designer. I was responsible for the complete design process: competitive research, stakeholder alignment, user flows, wireframing, iterative prototyping, and the final high-fidelity design system across approximately 50 screens.
The Problem
AssumeChat existed as an idea without an experience. The product had no design system, no coherent flows, and its most distinctive feature — the assumption mechanic was invisible.
The Solution
An experience that is verified, spontaneous, and designed around curiosity
Translated a strong product concept into a cohesive, trustworthy experience that could communicate AssumeChat's unique value from the very first screen.
Verified trust
.edu email verification establishes safety and campus exclusivity from the very first step.
Assumption-driven identity
The unique "assume and burst" mechanic gives users a way to present themselves, challenge perceptions, and deepen connections post-chat.
Guided spontaneity
Structured onboarding, waiting room modes, and icebreaker prompts reduce friction without eliminating serendipity.
Guest Access
New users can trial up to 3 chats anonymously before signing up, lowering the barrier to entry while a behaviour-based gate ensures only verified, well-rated users continue.
Deep Dive - Process, Thinking & Decisions
The Process
Three phases, three reviews, one evolving product
The design process followed three broad phases across 2 months, each centred around a major stakeholder review and a defined set of deliverables. Throughout, I worked as the sole designer in close collaboration with the project lead and the development team.
Understanding Requirements and Research
Concept Development
Mapping Flows and Ideation
Iterative Prototyping and Reviews
Design System
Final Changes and Design
UX Research
Finding the gap no existing platform had filled. Initial stakeholder meetings established three non-negotiable product pillars:
The platform must feel exclusive to college students.
Spontaneity should be preserved without sacrificing safety.
Profile-based assumption guessing would be a central mechanic
One early conversation shaped a key direction. Stakeholders initially envisioned a lighter onboarding — a quick sign-up and straight to chat. I advocated for a more personalised approach that would capture student interests, academic context, and matching preferences. My thinking was that without a little context about each user, the platform couldn't deliver on its promise of meaningful, relevant connections — more intentional data upfront would lead to better matches and a stronger first experience. The stakeholders were open to this, and the richer onboarding became a core part of the design.
Competitive Audit
To identify the design opportunity clearly, I conducted a structured audit of five platforms: Omegle, Yubo, Quack, Discord, and Reddit.
Platform
Key Observation
Omegle / Yubo
High spontaneity, no identity verification — safety gap
Quack
College-verified but lacks serendipitous discovery
Discord / Reddit
Community depth, but require prior intent to join
AssumeChat opportunity
Verified + spontaneous + campus-exclusive — not yet done
The audit confirmed a clear gap: most platforms offered either verification or spontaneity, but rarely both. AssumeChat had the opportunity to occupy a distinct position — safe enough to trust, open enough to surprise.
Concept Development
Translating the core mechanic into a visual language
With the product pillars and competitive landscape defined, I moved into concept development — translating the core mechanic into a visual and interaction language.
The Assumption Mechanic — Cards vs. Web
Stakeholders had a strong instinct for an infinite canvas, inspired by platforms like play.soot.com — a web of circles connected by lines, representing relationships and assumptions spatially. I explored and prototyped this direction, and through that process, I felt a card-based approach in a rectangular format would serve the mechanic better. My reasoning:
Rectangles provide significantly more space for text, which is central to the assumption mechanic.
The card format is cleaner, more legible, and scales better across screen sizes.
Cards align with the platform's aesthetic direction — bold, structured, purposeful.
They are more accessible, especially for users on mobile or smaller viewports.
After walking through the reasoning together, the stakeholders were on board with the card direction. The infinite canvas exploration was genuinely valuable — it clarified what the mechanic needed, and the final assumption card design is stronger for having gone through that process.
Onboarding Personality
The onboarding had to achieve two things simultaneously: make the experience feel personal and fun for students, and clearly communicate data usage and platform safety. The design balanced these through warm, student-facing copy, transparent consent language, and progressive disclosure — not overwhelming users upfront, but building trust step by step.
Ideation and Mapping Flows
Ideating and Mapping three flows that would carry the entire experience
Two features were explored during ideation but did not make the final cut:
The ability for other users to rate or like individual assumptions
The option to upload media as social proof when bursting an assumption.
Both were compelling ideas, but the added interaction steps created friction that outweighed the value at this stage of the product.
One interaction pattern I reconsidered was how users would multitask during a chat. Stakeholders envisioned a dropdown that users could open while in conversation to explore the waiting room — games, profiles, Reels — without leaving the chat.
In practice though, requiring users to repeatedly open a dropdown created unnecessary friction, and more importantly, risked them missing messages or losing the thread of a conversation mid-flow. I proposed a minimise option instead — a persistent mini screen anchored to the bottom left, showing the live chat or video call while users freely explored the rest of the product. It's a pattern people already understand intuitively from video calls and streaming, and it kept the conversation present without demanding attention.
Onboarding Flow
Landing page with clear Login / Sign Up CTAs
Email verification (.edu gating)
Academic context capture (institution, interests, matching preferences)
Sample chat preview to set expectations before first connection
Connection and Chat Flow
Waiting room: hub between interactions — Reels, Mini Games, Assumer, Uni Space, Profile
Auto-pairing based on verified email + light preference filters
Icebreaker prompts + partial profile glimpse to initiate conversation
Chat screen with emoji/sticker support, typing indicators, exit/report options
Post-chat: Rate the conversation, write assumptions, choose to connect or move on
Profile and Assumption Flow
Dynamic profile creation with interest prompts and assumption seeds
Burst Assumptions: users can journal and challenge assumptions made about them
Close Friends: direct access outside the waiting room queue
Iterative Prototyping and Refinement
What the last round of feedback shaped before launch
Guest Flow
New users can access up to 3 chats anonymously before being required to register. If they receive strong ratings, they are invited to sign up and continue. If they are reported or rated poorly, access is blocked and sign-up with a verified university email becomes mandatory. This expands the top-of-funnel while preserving community quality
Camera & Mic Auto-On
Users enter chat with camera and microphone on by default, with the option to mute only after matching. This decision reinforces authenticity — users show up as themselves — and reduces the risk of bad-faith participation
Hybrid Chat Modes
Experimental split-screen formats combining chat with Reels or Mini Games were introduced to reduce the awkward silence problem. These formats give users a shared experience to react to, lowering the barrier to conversation.
Metrics
What success looks like for AssumeChat
Guest-to-signup conversion
Behaviour-gated — strong ratings trigger the invite, poor behaviour triggers the block
Chat-to-connection rate
A meaningful rate means the experience delivered enough to want to continue outside the queue
Waiting room engagement
Reels, mini games, and the assumer exist to fill the gap between chats without users leaving the product. Dwell time in the waiting room, and return rate after a session ends, are the proxies here.
Reported or blocked users per session
Low report rate = the trust mechanisms are working, not just present
Design System
Building a consistent visual language across 50 screens
A foundational design system was built to maintain consistency across the ~50 screens. It was my first complete industry project, and while the system served the product well at this stage, it's also something I'd approach with more depth and structure today.
Typography
A single typeface family was used throughout, selected for legibility at small sizes on responsive web and for its contemporary, student-appropriate personality.
Colour
The palette was designed to communicate energy and curiosity while maintaining sufficient contrast for accessibility. A primary brand colour was used consistently across CTAs, highlights, and interactive states.
Iconography
A consistent icon set was selected to support navigation and feature affordances across the waiting room, chat, and profile flows.
Components
Reusable components were built in Figma for cards, buttons, input fields, chat bubbles, assumption blocks, and navigation elements. These were applied consistently across all three iteration cycles.
Final Design
Three rounds of iteration, each one adding new scope.
Onboarding
Focused on the entry experience: landing page, email verification, academic intake, and the waiting room. Wireframes were presented and reviewed with stakeholders. The personalised onboarding structure was agreed upon here.
Connection and Chat
Expanded the prototype to cover the full connection flow — from waiting room to auto-pairing, chat, assumption writing, and post-chat options. The infinite canvas concept for assumptions was prototyped and evaluated in this phase, ultimately leading to the card-based redesign.
Final Changes and Guest Flow
Final additions based on a third stakeholder review:
Camera and mic auto-on by default upon match: to encourage authenticity and reduce the ability to misrepresent.
Hybrid chat modes: experimental formats combining chat with Games or Reels for added engagement.
Guest / A/B flow: anonymous users could trial up to 3 chats without signing up. Strong ratings prompted registration; poor behaviour resulted in a block requiring verified sign-up.
The guest flow was a stakeholder-initiated idea. My contribution was determining the specific screens, logic, and transitions that made it function coherently within the broader product.
Takeaways
What this project taught me about designing with ambiguity
Design decisions are stronger with evidence: Several key moments in this project — the onboarding structure, the navigation model, the assumption card format — involved bringing a different perspective to the table. What made those conversations work was having a clear rationale rooted in the user experience: interaction cost, content requirements, accessibility. Design thinking lands best when it connects to outcomes.
Navigating ambiguity is its own skill I joined a product that was still finding its footing: There wasn't a traditional brief — more of a vision and a set of early screens to build from. Learning to shape a coherent product direction through stakeholder conversations, competitive research, and first principles turned out to be one of the most formative parts of the project.
What I'd do differently: I'd put more thought into the design system from the start. My understanding of systems was still developing at the time, and a more token-based, documented approach would have made iteration smoother and handoff cleaner. I'd also carve out time for even a light round of user interviews — having direct user voices in the room, even informally, tends to sharpen every decision that follows.
