Enforce Mobile Design Best Practices
Mobile-first design system with an MFRI feasibility score, hard-banned anti-patterns, and platform unify/diverge rules for iOS/Android.
Why it matters
Ensure your mobile applications are built with a mobile-first, platform-respectful, and performance-conscious approach. This asset guides developers to avoid common anti-patterns and make informed design and architecture decisions.
Outcomes
What it gets done
Assess mobile feature feasibility with the Mobile Feasibility & Risk Index (MFRI).
Enforce mandatory pre-design questions regarding platform, framework, and user needs.
Prevent common performance, touch, UX, and security anti-patterns in mobile development.
Provide guidance on platform-specific defaults and unification vs. divergence.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-mobile-design | bash Overview
Mobile Design System
A mobile-first design discipline scoring feature feasibility (MFRI) before implementation, banning specific performance, touch, and security anti-patterns, and defining what to unify versus diverge between iOS and Android. Use before designing or implementing any mobile screen or feature, not for desktop or web UI work.
What it does
A mobile-first design and engineering discipline built on a core law - mobile is NOT a small desktop - and an operating rule to think constraints before aesthetics. Before any mobile feature or screen, it scores a Mobile Feasibility and Risk Index (MFRI) as Platform Clarity plus Accessibility Readiness minus Interaction Complexity, Performance Risk, and Offline Dependence, ranging -10 to +10, gating action: 6-10 is safe to proceed, 3-5 needs added performance and UX validation, 0-2 needs simplification, and below 0 requires a redesign before implementation. It mandates asking six clarifying questions before starting - platform, framework, navigation pattern, offline requirement, device targets, audience - rather than defaulting to a familiar stack, and requires reading six universal reference files (mobile-design-thinking.md, touch-psychology.md, mobile-performance.md, mobile-backend.md, mobile-testing.md, mobile-debugging.md) plus the relevant platform file before designing UI. It hard-bans specific anti-patterns across three categories: performance (ScrollView for long lists instead of FlatList or FlashList, inline renderItem instead of useCallback plus memo, index-as-key, JS-thread animations instead of the native driver, console.log in production, missing memoization), touch and UX (touch targets under 44-48px, gesture-only actions with no button fallback, missing loading or error-recovery states, ignoring platform navigation norms), and security (tokens in AsyncStorage instead of SecureStore or Keychain, hardcoded secrets, no SSL pinning, logging sensitive data). A unification-versus-divergence matrix says to keep business logic, data models, API contracts, validation, and error semantics unified across platforms while letting navigation behavior, gestures, icons, typography, and pickers or dialogs diverge to match each platform's own defaults, such as SF Pro, 44pt touch targets, and edge-swipe back on iOS versus Roboto, 48dp, and system back on Android. It grounds touch design in Fitts's Law - a finger isn't a cursor, accuracy is low, reach matters more than precision - so primary CTAs belong in the thumb zone and destructive actions get pushed away from it. A canonical framework decision tree resolves the stack choice: React Native plus Expo for OTA updates with a shared web team, Flutter for high-performance UI, SwiftUI for iOS-only, Compose for Android-only. Before writing any code, a mandatory checkpoint requires naming the platform, framework, files read, three principles to apply, and anti-patterns to avoid. A release-readiness checklist covers touch target size, offline handling, secure storage, list optimization, stripped logs, low-end device testing, accessibility labels, and an MFRI of at least 3.
When to use - and when NOT to
Use before designing or implementing any mobile screen or feature - assessing feasibility via MFRI, choosing a framework, or reviewing code against the hard-banned anti-patterns. Not for desktop or web UI work, where the thumb-zone, battery, and offline-first constraints this skill enforces don't apply the same way. If the platform, framework, navigation, offline requirement, device targets, or audience aren't explicitly stated, the skill requires stopping to ask rather than assuming.
Inputs and outputs
Input is a mobile feature or screen request plus its platform, framework, and audience context. Output is an MFRI score with its required action, a completed mobile checkpoint (platform, framework, files read, principles, anti-patterns to avoid), and implementation following the performance-safe patterns for the chosen framework.
const Row = React.memo(({ item }) => (
<View><Text>{item.title}</Text></View>
));
const renderItem = useCallback(
({ item }) => <Row item={item} />,
[]
);
<FlatList
data={items}
renderItem={renderItem}
keyExtractor={(i) => i.id}
getItemLayout={(_, i) => ({
length: ITEM_HEIGHT,
offset: ITEM_HEIGHT * i,
index: i,
})}
/>
Integrations
Points to sibling skills frontend-design for visual systems, frontend-dev-guidelines for React Native and TypeScript architecture, backend-dev-guidelines for mobile-safe APIs, and error-tracking for crash and performance telemetry. Named frameworks include React Native with Expo, Flutter, SwiftUI, and Jetpack Compose; named storage and security tools include SecureStore and Keychain.
Who it's for
Mobile engineers and designers who need enforced guardrails against desktop-thinking defaults - list performance, touch target sizing, offline handling, and platform-appropriate navigation - rather than a general UI style guide.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.