Ani
An animanga social platform where people track what they’re watching and reading, discover what’s next, and actually talk to each other about it. I designed and shipped the MVP interface end to end, and built the design system behind it.
A fandom with no home
Animanga fandom is enormous and deeply engaged, but the tooling around it is scattered. Discovery happens on Reddit and Discord. Tracking happens on listing sites with interfaces that haven’t moved in a decade. Conversation happens somewhere else again. Nothing connects what you’re watching to the people you’d talk to about it.
Ani puts all three in one place: discovery, tracking and community, for both anime and manga, which most tools treat as separate problems.
Downloads in the first month after launch
Views on the launch video in its first month
Screens designed for the MVP build
Shipped with the founding team, concept to launch
Shipping the MVP interface
I designed the interface screens and user flows in Figma, and designed and shipped the MVP interface end to end, working directly with the founding team and engineers from concept through launch.
The MVP surface was wide: onboarding and auth, discovery, dual anime/manga tracking across five list states, detail pages with review and rating flows, a social feed with comments, profiles, notifications, moderation and settings. Over 180 screens went into the first build.
The app reached 10,000+ downloads in its first month, which confirmed the core bet: that fans wanted these three things in one place badly enough to switch.
Design decisions made with the people building it
A design system doesn’t get proven in Figma, it gets proven against what engineering can actually ship. Working directly with Ani’s founding team meant every token, variant and component decision had to hold up in a real conversation about feasibility and timeline, not just look right on a canvas.
Some ideas that worked cleanly on their own got reshaped once we talked through how they’d actually be built, and the system had to be flexible enough to absorb that without turning into a pile of one-off exceptions. None of that back-and-forth shows up in the screens above, but it’s most of where the real design work happened.
The part that has to outlast the launch
Shipping an MVP is one problem. Keeping it coherent while features keep landing is a different one, so I built and maintained Ani’s Figma design system: tokens, variants, and component architecture.
Tokens kept colour and type consistent wherever they were applied, and made accessibility something enforced by the system rather than checked by hand. Variants and a considered component architecture meant a new feature was usually assembled from parts that already existed, instead of drawn from scratch and slightly off.
That's what let the interface stay consistent while the product kept moving, for the two years I was there.
Low fidelity first
Before any of it looked like anything, the flows got mapped and the screens got wireframed. Low fidelity is the cheapest place to find out that a flow doesn’t work, and with a scope this wide, it was the only way to agree on what the MVP actually included before committing to pixels.
Design that had to sell it too
I also produced Ani’s design assets for product marketing and social content: including the launch video, which passed 100,000 views in its first month.
Being responsible for both the interface and the marketing around it was a useful constraint. The promise the campaign made and the thing the app actually did were drawn by the same person, so they tended to match.