Scope: this page covers only the parts I built myself: the design system documentation, the component state rules, and mobile flows for a new student persona.
Principle: mobile is an application of the web app, not a separate product. Same records, same fields, same tokens.
Eight linked guides. I turned the web Figma file into a documented system: eight linked markdown guides covering principles, colour, typography, spacing and layout, radius and shadow, components and the product’s domain, built from the variable, text and effect exports and about 27 product screens.
Tokens with one source. I wrote a generator that turns the Figma export into code-ready tokens (W3C DTCG JSON, a CSS theme and a Tailwind config), so token values live in one place and can’t drift between the guides and the code.
Load three files, not eight. A usage guide maps four workflows (designing a screen, coding a prototype, auditing in Figma and developer handoff) to the three files each one actually needs, so neither a person nor an agent has to read everything.
Saying what the system doesn’t decide. A coverage-gaps file lists what is still open, such as motion, truncation, undo, permissions and localisation, so nobody mistakes a gap for a rule.
Pressed is a border, not a fill. For bordered, card-like components such as selection cards and chips, pressing keeps the white background and only darkens the border, one step at a time. Selected items follow their own darker green steps. Green belongs only to what is selected or active.
One focus ring. Focus comes only from a ring effect style, never from a recoloured border, so every component shows focus the same way.
One disabled rule. Buttons and visual elements fade with an opacity/disabled token; form fields and cards switch to disabled colour tokens; never both at once.
Measured, not assumed. I measured how much of the mobile library is bound to tokens: 956 of 961 text layers, 95 of 111 effects, 844 of 863 corner radii and 3,478 of 3,498 spacing values.
Same fields, better input. Each mobile task asks for the same fields, with the same data types, as its web form. Only the presentation changes: prefilled values, a note tucked behind a button, a bottom sheet instead of a modal.
Log Weight. A six-screen flow from an empty entry to a saved record. A typo check catches a value like 24 lbs typed instead of 2.4: Save stays disabled and the warning offers a one-tap fix, because nobody means to save 24 lbs.
After a daily care check. I proposed four after-save states, from a calm confirmation to a milestone, following the product’s rules: reward accuracy rather than activity, no streaks or points, and never frame a missed day as a failure.
Prototypes that behave like the app. Figma prototypes can’t hold state, so Back often lands on the wrong screen. I built coded React prototypes of the mobile student app and the web show-entry flow, so flows could be reviewed and tested like the real product.
Specs on the canvas. Developer handoff lives as a Figma Spec inside both design files, mobile and desktop, kept identical: rules, states, and what is not designed yet.
Metrics before launch. For the student feature I wrote the analytics plan: the events, the success metrics and how each one is computed, so the team knows what success looks like before launch.
A baseline before the restructure. The guides will split into separate mobile and desktop versions. Before that, I set up a baseline: three frozen screen scenarios and a scoring sheet, to compare what an agent produces before and after.
Honest status. There are no measured outcome numbers yet. Running that baseline is the next step.