Mobbin research playbook
reference· designer · updated 2026-06-28 · source
How to find references on mobbin.com depending on what you're building.
Decision (José, 2026-06-10, #293): manual, no MCP — the Mobbin MCP requires a paid plan + interactive
auth; this playbook covers the same job. Mobbin = reference/inspiration. Paper artboards
remain the source of truth (design-routing.md); values come from our tokens,
never from someone else's screenshot.
The 4 search surfaces — which to use
| Surface | What it is | Use it when you need |
|---|---|---|
| Screens | Individual screens, filterable by pattern | Layout, hierarchy, density of a screen |
| Flows | Step-by-step sequences (sign up, checkout…) | Multi-step UX — what happens before and after |
| UI Elements | Cropped components (tables, navs, cards) | Anatomy of ONE component, not the screen |
| Apps | All the screens of an app | Studying how ONE app solves its whole system |
Key filters: platform (Web / iOS / Android), app category (Business, Finance, AI, Productivity…), pattern (Dashboard, Onboarding, Settings, Empty State, Pricing…).
Recipes by build type (tedos scenarios)
| You're building | Recipe on Mobbin |
|---|---|
| Dashboard / Mission Control | Screens → pattern Dashboard + platform Web + category Business/Analytics. Refs: Linear, Stripe, Attio, Notion |
| Auth (sign-in/sign-up, Clerk) | Flows → "Log in" / "Sign up" + Web — look at the full sequence (errors, verification), not just the pretty screen |
| Onboarding (new client) | Flows → "Onboarding" + category B2B/SaaS — count the steps; fewer is the winning pattern |
| Lists + detail (Plans, Reports) | UI Elements → Table / List + Web; Screens → "Content feed/list". Look at row anatomy: leading icon, meta, trailing action |
| Empty / loading / error states | Screens → pattern Empty State — what they offer as the next action (never just "no data") |
| Settings / configuration | Screens → Settings + Web — section grouping and navigation, not aesthetics |
| Pricing / billing / upgrade | Screens → Pricing; Flows → "Upgrading" / "Subscribing" |
| Search / command palette | Flows → "Searching"; UI Elements → Search. Refs: Linear, Raycast, Notion |
| A specific component (modal, toast…) | UI Elements straight to the component — compare 3 anatomies, extract the common structure |
Heuristics (how to search well)
- Search by pattern, not by app. "Dashboard" crosses industries; opening your favorite app biases you.
- Platform = Web for apps/admin. iOS patterns lie about density and navigation for a B2B admin.
- Max 3 references per decision. More references = mediocre average. Three anatomies → the common structure → decide.
- Extract principles, not pixels. From a reference you take: hierarchy, grouping, states, sequence. Never: colors, spacing, radii — those come from our tokens (
admin-ui-conventions.md). - Flows before Screens for anything multi-step. An isolated screen hides the real cost of the flow.
- References go into the Design Spec as links (URL of the screen/flow on Mobbin), alongside the Paper ref — so Frontend sees the intent without reinterpreting.
- Collections per feature if you have an account — group what you collected for the handoff and review.
Anti-patterns
- Copying a whole screen "because it looks good" — without running it through the rubric (
design-principles.md) or the tokens. - Searching for references AFTER deciding — then they only confirm; search before the spec.
- Consumer references (iOS social apps) for B2B admin surfaces.