Case study 01 · Classeh
FahmYar
An AI-supported learning app for school students. Learning happens in missions made of short stages, and a game layer of resources and buildings is being designed on top of it.
01The problem
One mission structure has to work for a pre-schooler and for a student in upper secondary, without feeling childish to the older ones.
On top of that, a game economy with many resources and buildings needs rules a student can read without a manual.
FahmYar covers school subjects, English, AI and life skills. Its two layers are at different stages: the mission-based learning experience is in the product today, while the city-building game is specified in design and planning documents and isn't complete. I keep the two apart below.
02My part
I work with the product, development and game-economy teams. What I designed and documented:
Learning experience
- Mission and stage structure by age
- Interaction fit by subject and age
Game system
- Building, production and construction states
- Resource and building logic
- Economy tables
Content quality
- Review areas for test content
- Broken-question reporting
Measurement
- Usage and drop-off definitions
- Daily dashboard brief
Feedback and QA
- Teacher test feedback, sorted into bugs, feature requests and onboarding gaps
- Content matching and duplicate checks against the school calendar
Different roles
- Needs of students, families, teachers and schools, and of each age group
Proposals
- Parent panel
- Certificates
Visual exploration
- AI-assisted art direction for buildings and characters
The economy tables and simulations were prepared together with the game-economy team. The AI-assisted visual concepts are art direction, not final assets.
03Constraints
Different ages, different interaction
About three stages for pre-school, four to five for primary and secondary. Upper-secondary maths, physics and chemistry need deeper interaction than a quick tap.
An economy a child can read
Water, food, wood, stone and metal, plus houses, farms, storage, wells, mills, a market and workshops: many combinations of what can and can't happen.
Designing ahead of the build
The game layer was specified before it existed, so the design couldn't lean on parts of the product that weren't there yet.
04Key decisions
Plain words instead of a percentage
Early versions showed a productivity percentage for each building. I replaced it with named states, so a student sees why a building isn't producing and what to do next.
Fewer concepts to learn
Every separate rule is another state to explain. I took rules out of the system rather than explaining them better.
Count mission starts, not mission opens
Some older “mission start” events only meant the roadmap had opened. The measurement brief separates opening from starting, unique students from attempts, and a student's real grade from the grade that owns a mission.
A certificate that doesn't wait for missing pages
A proposal for the MVP: the certificate shouldn't depend on a course page that doesn't exist yet. Unlocking is tied to important missions or learning paths.
Sort feedback before acting on it
A teacher's test session surfaced permission, camera, sharing, discoverability and first-use problems in one report. I separated them into bugs, feature requests and onboarding gaps, so each kind of problem goes to the right owner and nothing is fixed with the wrong tool.
05Flows and states
A building is always in exactly one named state. These are the rules I specified for the game layer and for content quality.
06Screens
07Status
The mission-based learning experience is in the product. The city-building game is a designed system that hasn't been released in full, and I don't assume which of its state rules are live in the current build.
I'm not quoting learning or engagement results. The measurement work defines how usage can be read reliably; it isn't a result in itself.
I can walk through the full spec and handoff files in an interview.
08What I learned
A metric depends on its definition. Finding that some “starts” were only roadmap opens showed me how easily a funnel overstates progress.
In a game, a short plain status does more than a number. Telling a student why a building can't produce is what lets them act.