JAppL

Problem & Context

Japanese is one of the hardest languages for an English speaker to pick up — no shared roots, no cognates, and a completely different grammatical structure. English-native students spend close to an average of 2,200 hours studying to reach fluency. That's a brutal number. Put those hours into a traditional, textbook-style app, and most casual learners burn out long before they see any progress.

The developer I worked with wanted to build something different: an app that leaned into gamification to make that grind feel less like a chore — one that could teach hiragana, katakana, kanji, and grammar through game-like mechanics instead of rote memorization. My job was to figure out what that app should feel like before a single screen got built.

I started looking at what already exists within the market of language-learning apps. I dug into Duolingo, LingoDeer, and Anki, and — more usefully — into what users were actually saying about them in reviews. The pattern was clear: people were drawn to brighter, warmer, more welcoming visual identities, but they also valued simplicity over cluttered interfaces. That became my guide for who this app was for: casual learners and hobbyists, a lot of them probably coming in through anime or pop culture, who want something approachable rather than academic. That's why I leaned into simple, doodled illustration which reads as fun and low-stakes rather than intimidating, and appeals to a wide range of people without feeling niche.

Design Process

First step was a deep-dive interview with the developer — why he wanted to build this app, what he'd already envisioned, and where he was flexible. From there, I put together multiple options across color palette, typography, and overall visual aesthetic, and we iterated on those together until we converged on a visual identity we both felt strongly about.

We didn't start at JAppL; the first concept was Kanjify (Kanji + Simplify). This sounded clean on paper but ended up feeling vague, forgettable, and a little too serious for what we were building. JAppL — J(apanese) App (for) L(earning), doubling as a play on "apple" — hit the tone we actually wanted; something that doesn't take itself too seriously, because the app itself is about making a hard subject feel fun.

Once we had something solid, we ran it past a general audience to pressure-test. That's actually where one of the bigger pivots came from. An earlier iteration leaned hard into the literal "apple" concept, and the feedback was consistent: it read as corny and too on-the-nose. So we scaled the apple motif back and kept it as a supporting nod rather than the star of the show, which made the whole identity feel more intentional and less like an overused pun.

A moment of friction during the process including one point in which the developer pushed for a simpler design purely to make his build easier. I understood the constraints involved, but I decided to push back as the whole premise of this app was built on being fun and interactive. Simplifying too far for dev convenience would have undercut the core value proposition. We found a middle ground that stayed buildable without losing the personality that made the concept work in the first place.

Rationale

Colours — Red, green, cream, and a soft light blue. The green and cream tie back to nature (leaves, apples, growth), which supports the wordplay in the name. Red was a more deliberate choice: in Japan, red is associated with luck. I wanted JAppL to feel like a bit of a lucky charm for the learner; something rooting for them from start to finish!

Typography — Gilker for the wordmark, TT Commons Pro for body and subheadings. Gilker has an organic, slightly hand-drawn shape that matches the illustration style; TT Commons Pro is there purely for readability once you're past the headline. The pairing gives you both visual personality and clarity, which matters a lot for a learning product where users will be reading instructional text constantly.

Mascot & key visual elements — This is where I tried to build in room for actual product mechanics, rather than simple decoration:

• A seed-to-tree growth metaphor as a visual system for streaks and progress. A learner starts as a seed and grows into a full tree as they advance, which gives progression an emotional, visible payoff instead of just a number going up.
• A simple doodled mascot character. This was JAppL's answer to Duolingo's "Duo", meant to act as a guide/companion figure throughout the learning journey.
• Stars to represent proficiency in a specific lesson or unit. We considered sticking with apples here too, but stars are a more universal, psychologically intuitive symbol of achievement. Also visually, they gave the system a needed break from an otherwise all-nature palette.

Constraints & Trade-offs

This was a passion project, not a client engagement with a formal scope, so the constraints were softer but still very real. I was designing for a single independent developer to build and maintain, which meant every visual decision had to stay realistic to hand-code without a design system team or animation budget behind it; no heavy custom animation, simple vector shapes throughout. That's part of why the pushback moment mattered as much as it did: I had to argue for personality within a scope that was genuinely limited. There was no budget either, which shaped tool and typeface choices, everything came from free resources (Figma, Canva, freely available fonts) rather than paid stock or licensed type. The project also ran around my own coursework schedule rather than a compressed sprint, so iteration happened in bursts, which is part of why the feedback loop with friends and colleagues mattered as it let us course-correct between sessions instead of losing momentum. And there's an obvious one worth naming honestly: the name and apple imagery sit close enough to Apple Inc.'s identity that it's a real brand consideration, even for a concept piece.

Outcome & Reflection

JAppL was purely a concept project, built to demonstrate brand and product design thinking end-to-end rather than a live product with metrics behind it. But this allowed me the freedom to fully delve into product thinking. I learned how to navigate real product tasks, like translating a vague brief into research-backed decisions, iterating with a real stakeholder, defending a product principle when it came under pressure, and building a visual system that does more than look nice to support actual product mechanics like streaks and proficiency tracking.

If I picked this back up, the natural next step is extending the brand into the actual product experience. I would like to delve into designing the home page and lesson pages themselves, building off the visual identity and product design we've started. This would include figuring out how the growth-tree progression, the mascot, and the star system actually behave inside an interactive UI: what a home page looks like when it needs to represent streaks, next lessons, and progress at a glance without feeling cluttered, and what a lesson page needs to feel game-like, intuitive, and interactive. I'd want to prototype those flows in Figma and actually test them by putting them in front of casual learners to see where the UI is instinctive versus where it's just aesthetically pleasing, and iterating based on where people hesitate, misclick, or drop off. That's the gap between "the brand feels fun" and "the product is fun to use," and it's the part of this project I'd most want to close!

This project is where I first felt what it means to juggle user needs, stakeholder constraints, and a solid brand definition, which I believe are the core concepts of product management. Interviewing the developer to uncover what he actually wanted, researching competitor products to ground decisions instead of relying on taste, and becoming the primary advocate for the product allowed me to hone product skills while experimenting with a workflow that meshed well with both my personal style and the project at hand. Going forward, I want to carry that instinct into more structured PM work: writing the research and rationale down as a proper PRD-style document instead of just a brand board, defining success metrics up front, and getting more comfortable making that same kind of stakeholder trade-off call in contexts with real users and data behind it!