B2C / APP / REDESIGN
Turtil App v2
Redesigning the app for an updated product direction, from optional social platform to essential campus interface.
// PROJECT OVERVIEW
A complete redesign of a student app that transformed from a social platform into essential campus infrastructure. When the Campus Management System launched, the student app became the primary interface for all academic information, requiring a rebuild to handle both trust-critical campus data and social engagement without compromising either.
// THE PROBLEM
v1 was built for exploration, not dependency.
The original app functioned as a student social platform with strong initial signups but declining engagement. Students opened it when bored, not when they needed something. Without a clear job-to-be-done, there was no natural trigger for return visits.
CMS integration changed the stakes entirely. Once institutions adopted the CMS, the app became essential infrastructure. Students would now depend on it daily for grades, attendance, timetables, and official campus information. This created fundamental conflicts:
High-intent campus actions (checking attendance) vs. low-intent social browsing (exploring feeds)
Trust-critical data accuracy vs. experimental social features
Daily frequent usage vs. an architecture built for occasional engagement
If academic data felt buried or unreliable, students would lose trust in the entire platform. If social features cluttered the interface, frustration would spread to every interaction.
HIGH-INTENT
Academics, attendance, timetables, official campus data
Trust-heavy, dependency-driven actions where accuracy is non-negotiable
LOW-INTENT
Browsing, posting, networking, social engagement
Optional interactions that students choose to do on their own terms
// MY ROLE
Sole product designer responsible for the complete redesign of the student app, working directly with the engineering team. I designed:
Product architecture and navigation systems
End-to-end user flows for campus and social features
Interaction patterns and information hierarchy
Motion design and visual language (prototyped in Jitter)
There was no room for post-launch structural fixes. Mistakes could break trust at scale.
// APPROACH
Instead of forcing engagement, I separated dependency from exploration. The app needed to support two fundamentally different modes: students accessing campus data because they need it (high-stakes, predictable), and students engaging socially because they want to (low-stakes, exploratory).
The solution wasn't adding features. It was structural clarity and systematic friction reduction.
// KEY DECISIONS
Separating campus data from social interaction
Navigation was designed deliberately. Social interaction tabs are distinct from the Campus Hub for CMS-driven information. All academic data is accessed through a single, clearly defined entry point. This was a product-architecture decision, not a UI one.
Reducing friction systematically
Simplifying post creation, reducing cognitive load, clarifying navigation, and organizing the homepage to stay calm, scannable, and predictable. Routine actions should not require thinking.
Channel-based feeds to prevent social collapse
The feed was redesigned around channels, dedicated spaces for specific topics. Posting became less intimidating, browsing became more intentional, and anonymous posting gained clear contextual value.
Motion as reinforcement, not decoration
Once core flows were simplified, motion was used to reinforce feedback, progress, and transitions, making state changes feel deliberate rather than abrupt. All animations were designed and prototyped in Jitter.
// OUTCOME
Deployment-ready, awaiting CMS adoption. The app is tied to CMS sales, and institutions are in various stages of evaluation and onboarding.
When an institution adopts the CMS, the student app isn't an experiment, it's infrastructure. v2 was designed to meet that standard without relying on post-launch iteration.
Campus and social features coexist architecturally without conflict
Navigation supports both dependency-driven and optional usage patterns simultaneously
Information hierarchy assumes frequent, dependency-driven access
Built for trust at scale, no reliance on post-launch iteration
