Seenry Apps

Mobile quality is mostly platform fidelity plus the same discipline as the web system: a strict grid, components built in layers, few type sizes, one accent, and every state designed. Work in the project's existing stack and components.

References over priors. The palette, materials, type and layout come from the screens you studied, never from what you would reach for unprompted. When a screen looks like "a dark screen with one yellow accent and bold headlines", it came from priors, not research.

References inform, taste decides. Research shows what people expect and how leaders solved the screen; it does not design the screen. The design comes from one idea, chosen on purpose, and carried into the small, ordinary parts of the interface, the way a designer thinks: "if every place you keep is a matchbook, then progress is five matches and each answered step strikes one." Rules in this skill catch tells; they never outrank a choice that clearly fits the idea, written down with its reason in .seenry/look.md.

Carry the idea into the ordinary parts. After choosing the idea, go through the plain components every screen has and ask what each becomes in this product's world. Pick the three or four where the answer is simple, obvious once seen and still usable, and build those; leave the rest native. Write them in .seenry/idea.md as "component → what it becomes → why it reads instantly":

• Progress: steps as the product's own unit (matches struck, pins dropped on a map, stamps in a passport, cups filling), never a generic bar when the idea offers a unit.
• Selection: a chosen option changes like the object would (stamped, pocketed, pinned, lit), not only a checkmark.
• Buttons and replies: labels in the user's voice that answer the screen ("same here.", "that's me"), one consistent voice.
• Counts and totals: the tally is the collection itself (three matchbooks, not "3 selected").
• Loading and waiting: the wait shows the thing being made (matchbooks being printed), never a spinner when something is being built from the answers.
• Empty and payoff states: the empty state is the object with nothing in it yet; the payoff is the user's answers made into the object. Each one must stay instantly legible: if a person has to learn what the metaphor means, use the native control instead. Two to four of these, done simply, are what make a screen feel designed; ten of them make it a gimmick.

Scope is what was asked. "A welcome screen" is one screen (with its entrance motion and states), not an onboarding flow; "the onboarding" is the flow. Build the asked scope to the highest standard rather than a larger scope to an average one.