ロードマップ

Problem

Search returns single screens. When a designer lands on one screen of an onboarding, checkout or cancellation flow, they cannot see the screens before and after it inside the same product. Position in the journey is the information they need, and it is missing. The same gap hits AI agents: an MCP call that returns loose screens gives no order, so the agent has to guess which state comes next.

Public signal: a Refero reviewer on Product Hunt wrote that the results are separate screens and "they're not grouped in whole user experiences". Refero's team replied that they are "developing a feature that will group screens by site or application". On Mobbin's Product Hunt launch thread, a commenter asked about "a feature to compare different design flows side-by-side".

Who has it

• Product designers working on onboarding, paywalls, checkout, settings and cancellation.
• Design engineers and AI-coding users who ask an agent to rebuild a journey and need the order of states.
• Founders who benchmark a competitor's full sequence, not one screen.

Proposed solution

1. Sequence bar on flow screens. Every screen that belongs to a flow shows its position (for example, step 3 of 9), with previous and next controls that stay inside that flow.
2. Ordered state labels. Each step is tagged with the state it represents (empty, loading, error, permission, success) so a reader can see recovery paths, not only the happy path.
3. MCP tool get_flow_steps(flow_id). Returns the ordered screens with their state labels and a short description, so an agent can plan a journey from evidence.
4. Figma plugin: insert whole flow. One action drops the ordered steps into a Figma frame in sequence, with the flow name as the frame title.

Scope for v1: flows only, no new capture. Start with the flows that already have a complete step order.

Why it is hard to copy

Screen-level indexes do not contain order. A competitor that wants this has to re-capture flows, link screens to a flow ID, and verify sequence across apps. Sequence correctness across many products is slow to get right, and Refcat's existing flow library is the starting point. The state labels also depend on a consistent tagging scheme, which takes time to build and check.

Effort

M. Data work on flow ordering and state tags, one new UI component in the library, one MCP tool, one plugin action.

Open checks before build

• Confirm how many of the ~100k flows already store step order. If it is partial, the v1 scope should be the flows that have it.
• Confirm that the flow ID is stable across re-captures.

Evidence

• Refero Product Hunt reviews and team reply: https://www.producthunt.com/products/refero
• Mobbin Product Hunt launch thread (comment asking for side-by-side flow comparison): https://hunted.space/product/mobbin-2-0
• Mobbin changelog: video in flows was "one of the most requested features thus far": https://pre-production.mobbin.com/changelog
• Refcat roadmap context: no card covers flow navigation. Closest items are search relevance and reasoning beside a saved reference, neither of which covers sequence.

Problem

AI coding agents produce the same generic UI because they do not know the visual system behind a product. Screen references show layout but not the system: type scale, colour roles, spacing rhythm, radii, motion. Style-level references fill that gap, and the existing market offers them mainly for web marketing pages. In-app dashboards, auth screens, settings and iOS screens have no equivalent style system in the public offerings we reviewed.

Refero's own skill documentation states the limit: "Styles currently cover web marketing and product pages, not in-app dashboards, auth screens, settings or iOS screens as style systems." Refero also announced that agents can search across 2,000+ real product styles in DESIGN.md form.

Who has it

• Design engineers who ask an agent to build a settings page or dashboard that must match a known product's density and hierarchy.
• Product designers on iOS who need a reference for system-level treatment, not a single screen.
• Teams that keep a DESIGN.md or tokens file in their repo and want evidence for it.

Proposed solution

1. Extract style cards for in-app and iOS surfaces from the screens Refcat already holds. Output: colours by role, type scale, spacing, radii, motion notes, and component patterns. Start with the 50 most-referenced apps.
2. DESIGN.md export per app, with a short note on what was inferred and what was observed in screenshots. Mark inferred values as inferred.
3. MCP tools search_styles and get_style(app), filterable by surface: dashboard, auth, settings, onboarding, iOS.
4. Figma plugin: create styles from a card as local variables, so the reference can become a working token set.

Scope for v1: colour, type and spacing only. Motion stays out until the extraction is reliable.

Why it is hard to copy

Style extraction needs consistent token inference from screenshots, plus human review for accuracy. Doing it for in-app and iOS screens is harder than for marketing pages: screens are stateful, often behind login, and iOS styling relies on system components. The curation and the accuracy checks are the slow part, and a competitor starting from web marketing pages would need to rebuild the pipeline for these surfaces.

Effort

L. Extraction pipeline, review step, a new style data model, MCP tools, and Figma variable creation.

Open checks before build

• Measure how accurately colour and type can be inferred from existing screenshots on 20 apps before committing to scope.
• Decide whether inferred tokens are labelled as such in the API, to avoid presenting guesses as source values.

Evidence

• Refero's skill documentation on what styles cover today: https://uichemy.com/design-skills/refero-design/
• Refero MCP update announcing 2,000+ product styles as DESIGN.md: https://x.com/referodesign/status/2056463426528960935
• Refero Styles becoming searchable through MCP in May 2026, as summarised by a third-party review: https://ai-deck.app/blog/refero/
• Refcat roadmap context: no card covers style-level or token-level references. "Make reference freshness easier to judge" and "Keep the reasoning beside a saved reference" are adjacent but different.

Problem

Many iOS features now live outside the app: widgets on the home screen, Live Activities on the lock screen, and Dynamic Island states. A designer who needs to design a delivery tracker or a timer has no reference for these surfaces unless the library captures them. Agents asked to design a widget fall back to generic cards.

Mobbin describes this as a gap its users asked for: "Out-of-app content — particularly Live Activities and widgets — has been one of our most requested features", and it now ships iOS screenshots of Live Activities and widgets with filters for Live Activities, Dynamic Island and Widgets.

Who has it

• iOS product designers building widgets, live status features or timers.
• Design engineers asking an agent to build a SwiftUI widget or a Dynamic Island state.
• Teams auditing how a competitor uses the lock screen.

Proposed solution

1. New surface type in the capture pipeline: widget, live_activity, dynamic_island, with their sizes and states.
2. Filters for the same three surfaces in web and app search, plus the MCP search filter surface.
3. Per-state grouping: compact, expanded and minimal states of the Dynamic Island grouped under one app, so the states can be compared.
4. Source tagging that says whether each capture is a device screenshot or a simulator capture, so reviewers can judge fidelity.

Why it is hard to copy

It is parity, so the moat is small. The harder part is capture quality: these surfaces need real devices or accurate simulator output and an OS version note, because they change between iOS releases. Refcat can keep its own capture set and labelling, which is the part a copy would have to reproduce.

Effort

S if the iOS capture pipeline already runs on device or simulator. M if it has to be built for these surfaces.

Open checks before build

• Check whether the current iOS capture already records lock screen and widget surfaces, or only in-app screens.
• Pick one iOS version as the first capture set and state it in the library.

Evidence

• Mobbin changelog: Live Activities and widgets added as iOS screenshots, with three new filters, after being one of the most requested features: https://mobbin.com/changelog
• Refcat roadmap context: "Improve search relevance across real design tasks" and "Make web-to-Figma capture more dependable" are in progress. Neither covers out-of-app iOS surfaces, so this does not duplicate active work.