MotionSites-inspired mobile apps

# Design reference: Energy Monitoring Dashboard Design - Solora
Source: https://dribbble.com/shots/27210300-Energy-Monitoring-Dashboard-Design-Solora
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27210300-energy-monitoring-dashboard-design-solora/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Solora: three clear phone screens combine dimensional home imagery with energy monitoring controls. Credit: Phenomenon Studio. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Find a Tutor Mobile app
Source: https://dribbble.com/shots/25278544-Find-a-Tutor-Mobile-app
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-25278544-find-a-tutor-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Find a Tutor: flat phone screens use portrait cutouts, confident teal and yellow, and clear booking controls. Credit: Aakash Kiri. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Travel Mobile App UI Exploration
Source: https://dribbble.com/shots/25879163-Travel-Mobile-App-UI-Exploration
Swipefile reference: https://swipefile.design/ref/ms26-mobile-25879163-travel-mobile-app-ui-exploration/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Pastel travel cards and airy forms show a coherent visual language across discovery and booking screens. Credit: Paperpillar. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Self-care Mobile App Design Concept
Source: https://dribbble.com/shots/23278774-Self-care-Mobile-App-Design-Concept
Swipefile reference: https://swipefile.design/ref/ms26-mobile-23278774-self-care-mobile-app-design-concept/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Expressive pastel faces, dark backgrounds, and simple daily prompts give a self-care app a distinctive emotional tone. Credit: Ronas IT | UI/UX Team. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: AI-Powered Mobile App for Restaurant Operations
Source: https://dribbble.com/shots/26787072-AI-Powered-Mobile-App-for-Restaurant-Operations
Swipefile reference: https://swipefile.design/ref/ms26-mobile-26787072-ai-powered-mobile-app-for-restaurant-operations/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Bright modular tiles and bold dark panels turn restaurant operations into a compact, colorful mobile overview. Credit: tubik. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Food Tracking Mobile App UI with AI Scan
Source: https://dribbble.com/shots/27377874-Food-Tracking-Mobile-App-UI-with-AI-Scan
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27377874-food-tracking-mobile-app-ui-with-ai-scan/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Food photography, a segmented nutrition gauge, and warm cream backgrounds connect scanning with daily food tracking. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Nutrition Tracking Mobile App Design – DailyMe
Source: https://dribbble.com/shots/27334823-Nutrition-Tracking-Mobile-App-Design-DailyMe
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27334823-nutrition-tracking-mobile-app-design-dailyme/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. DailyMe: clear blue phone screens pair nutrition data with a distinctive gradient progress visualization. Credit: Phenomenon Product. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: AI Agent Mobile App UI Animation for Automation Platform
Source: https://dribbble.com/shots/27502216-AI-Agent-Mobile-App-UI-Animation-for-Automation-Platform
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27502216-ai-agent-mobile-app-ui-animation-for-automation-platform/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. A luminous orange orb and dark conversational screens give an AI automation concept a distinctive mobile character. Credit: vino_costa. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mental Health Mobile App
Source: https://dribbble.com/shots/24175254-Mental-Health-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-24175254-mental-health-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Soft peach backgrounds, friendly illustrated cards, and clear daily questions make a mental-wellbeing interface approachable. Credit: Bogdan Nikitin. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Cooper AI Chat - Mobile App Exploration
Source: https://dribbble.com/shots/24133515-Cooper-AI-Chat-Mobile-App-Exploration
Swipefile reference: https://swipefile.design/ref/ms26-mobile-24133515-cooper-ai-chat-mobile-app-exploration/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Small lavender cards and clear conversational actions organize an AI assistant across home, activity, and plan screens. Credit: Paperpillar. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Creative Sketchbook Mobile App
Source: https://dribbble.com/shots/26831486-Creative-Sketchbook-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-26831486-creative-sketchbook-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Creative sketchbook: three flat screens show a refined editorial inspiration board, sketch wall and activity view. Credit: DIGI.CO. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Home Automation App Design - Hume
Source: https://dribbble.com/shots/27412627-Home-Automation-App-Design-Hume
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27412627-home-automation-app-design-hume/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Hume: coherent dark smart-home screens integrate realistic room imagery with orange scene controls. Credit: Phenomenon Product. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Neap - Mental Health Mobile App UI UX Design for Diabetics
Source: https://dribbble.com/shots/18442291-Neap-Mental-Health-Mobile-App-UI-UX-Design-for-Diabetics
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-18442291-neap-mental-health-mobile-app-ui-ux-design-for-diabetics/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Neap: friendly dimensional jellyfish illustrations unify onboarding and diabetes management screens. Credit: Phenomenon Product. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mobile App - AI Daily Quiz
Source: https://dribbble.com/shots/25889270-Mobile-App-AI-Daily-Quiz
Swipefile reference: https://swipefile.design/ref/ms26-mobile-25889270-mobile-app-ai-daily-quiz/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. A prominent illustrated quiz object, large answer actions, and warm cream backgrounds focus attention on a single learning task. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Habit Tracker & Routine Planner - Minimal Mobile UI Design
Source: https://dribbble.com/shots/27520618-Habit-Tracker-Routine-Planner-Minimal-Mobile-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27520618-habit-tracker-routine-planner-minimal-mobile-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Habit tracker: acid-yellow accents and dimensional progress elements give clear routine and calendar screens character. Credit: Safayet Hossain. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: AI Learning Platform Mobile App for Creators
Source: https://dribbble.com/shots/27420485-AI-Learning-Platform-Mobile-App-for-Creators
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27420485-ai-learning-platform-mobile-app-for-creators/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Dark purple cards, editorial portraits, and compact progress rings create an expressive mobile-learning environment. Credit: Bogdan Nikitin. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Travel Meetup & Bill Splitting App - Modern iOS UI Design
Source: https://dribbble.com/shots/27537248-Travel-Meetup-Bill-Splitting-App-Modern-iOS-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27537248-travel-meetup-bill-splitting-app-modern-ios-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Travel meetup: warm photography, a sculptural card treatment and clear expense-sharing controls form a cohesive phone flow. Credit: Safayet Hossain. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mobile app - Rent a boat
Source: https://dribbble.com/shots/7520340-Mobile-app-Rent-a-boat
Swipefile reference: https://swipefile.design/ref/ms26-mobile-7520340-mobile-app-rent-a-boat/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Bright illustrated boats, large color fields, and compact booking controls create a playful rental interface. Credit: Outcrowd. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mobile app - Best Catering
Source: https://dribbble.com/shots/6690497-Mobile-app-Best-Catering
Swipefile reference: https://swipefile.design/ref/ms26-mobile-6690497-mobile-app-best-catering/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Purple framing, orange illustrations, and bold category cards give a catering app a coherent, friendly visual language. Credit: Outcrowd. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Ecommerce Mobile App UI Design
Source: https://dribbble.com/shots/27738038-Ecommerce-Mobile-App-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27738038-ecommerce-mobile-app-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Fashion commerce: warm editorial portraits, generous typography and a visible product browsing interface. Credit: Design Monks LLC. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Creative 3D Builder Mobile App UI
Source: https://dribbble.com/shots/26958138-Creative-3D-Builder-Mobile-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-26958138-creative-3d-builder-mobile-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. A three-dimensional character anchors dark tiles and vivid lime accents in a playful creative-tool interface. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Beauty Service Booking Mobile App UI
Source: https://dribbble.com/shots/27262835-Beauty-Service-Booking-Mobile-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27262835-beauty-service-booking-mobile-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Warm orange gradients, stylist portraits, and a compact booking calendar connect service discovery to scheduling. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: CraveAI - Smart Food Ordering & AI Assistant Mobile App UI/UX ✨
Source: https://dribbble.com/shots/27696272-CraveAI-Smart-Food-Ordering-AI-Assistant-Mobile-App-UI-UX
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27696272-craveai-smart-food-ordering-ai-assistant-mobile-app-ui-ux/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. CraveAI: peach gradients, a luminous voice orb and readable food suggestions create a polished mobile assistant flow. Credit: Safayet Hossain. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Synvy Neuro Mobile App - Health Tracking App UI
Source: https://dribbble.com/shots/27420244-Synvy-Neuro-Mobile-App-Health-Tracking-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27420244-synvy-neuro-mobile-app-health-tracking-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Translucent blue panels and soft reflective forms produce a futuristic health-tracking concept with compact key metrics. Credit: Jack R.. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Time Tracking & Productivity Mobile App UI
Source: https://dribbble.com/shots/27279963-Time-Tracking-Productivity-Mobile-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27279963-time-tracking-productivity-mobile-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Warm orange and deep blue screens give calendar, daily planning, and a circular focus timer distinct visual roles. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Tesla Mobile App — Premium EV Charging
Source: https://dribbble.com/shots/27199111-Tesla-Mobile-App-Premium-EV-Charging
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27199111-tesla-mobile-app-premium-ev-charging/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. EV charging: three crisp dark screens combine vehicle imagery, charge percentage and a map with restrained green controls. Credit: Kris Anfalova. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mobile Fitness Readiness Dashboard
Source: https://dribbble.com/shots/27519525-Mobile-Fitness-Readiness-Dashboard
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27519525-mobile-fitness-readiness-dashboard/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Fitness readiness: readable recovery scores and multicolor metric bars create a strong mobile health dashboard. Credit: Excited. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Furniture Mobile App UI UX Design
Source: https://dribbble.com/shots/27467764-Furniture-Mobile-App-UI-UX-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27467764-furniture-mobile-app-ui-ux-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Furniture: dark navy commerce screens feature sculptural furniture photography and clear product controls. Credit: Ismail Nahid. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: AI Learning Mobile App — Kids Education UI
Source: https://dribbble.com/shots/27068193-AI-Learning-Mobile-App-Kids-Education-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27068193-ai-learning-mobile-app-kids-education-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Large condensed orange text and a playful character give a children's learning interface a strong visual personality. Credit: Bogdan Nikitin. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Mobile App Design — ECG & Heart Rate Monitoring UI
Source: https://dribbble.com/shots/26808268-Mobile-App-Design-ECG-Heart-Rate-Monitoring-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-26808268-mobile-app-design-ecg-heart-rate-monitoring-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. An anatomical heart illustration connects compact ECG data, a large pulse metric, and clear health-status panels. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Cinema & Movie Streaming App UI
Source: https://dribbble.com/shots/26982243-Cinema-Movie-Streaming-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-26982243-cinema-movie-streaming-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Cinema: atmospheric film imagery transitions into a legible seat-selection interface across three phone screens. Credit: Sadekur Rahman (AI Product Designer). Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Personal Finance Mobile App UI/UX Design
Source: https://dribbble.com/shots/27663824-Personal-Finance-Mobile-App-UI-UX-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27663824-personal-finance-mobile-app-ui-ux-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Deep blue product cards, prominent balances, and light transaction lists create a polished finance-app composition. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Crypto Wallet & Portfolio Mobile App UI Design
Source: https://dribbble.com/shots/27722011-Crypto-Wallet-Portfolio-Mobile-App-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27722011-crypto-wallet-portfolio-mobile-app-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. A dark violet wallet with lime actions and compact asset rows provides a clear contrast hierarchy for crypto holdings. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Inventory Management Mobile App UI
Source: https://dribbble.com/shots/27634525-Inventory-Management-Mobile-App-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27634525-inventory-management-mobile-app-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Dimensional inventory objects and compact status tiles make a dark mobile operations interface visually distinctive. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Beauty Skincare E-Commerce Mobile App UI Design
Source: https://dribbble.com/shots/27591562-Beauty-Skincare-E-Commerce-Mobile-App-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27591562-beauty-skincare-e-commerce-mobile-app-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Warm product photography, a large skincare bottle, and restrained purchase controls create a premium commerce detail screen. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Food Order Mobile App
Source: https://dribbble.com/shots/26878187-Food-Order-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-26878187-food-order-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Sushimi: vivid food photography and orange controls form a coherent dark ordering flow. Credit: Sadekur Rahman (AI Product Designer). Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Digital Banking Mobile App– Finance Wallet & Money Management UI
Source: https://dribbble.com/shots/27558232-Digital-Banking-Mobile-App-Finance-Wallet-Money-Management-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27558232-digital-banking-mobile-app-finance-wallet-money-management-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Luminous green charts, dark panels, and strong balance typography build a cohesive mobile wallet concept. Credit: Faruk Hossain 🍄. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Scuba Diving App — Ocean Adventure & Booking UI
Source: https://dribbble.com/shots/27715055-Scuba-Diving-App-Ocean-Adventure-Booking-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27715055-scuba-diving-app-ocean-adventure-booking-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Scuba diving: cinematic underwater imagery and teal booking controls connect discovery, equipment and purchase screens. Credit: SHEIKH NAEEM - (AI Product Designer). Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Venzer. - Finance Mobile App
Source: https://dribbble.com/shots/26238860-Venzer-Finance-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-26238860-venzer-finance-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Soft mint backgrounds and large circular balance graphics give a finance app a calm, distinctive presentation. Credit: Padhang Satrio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Dark Mode Delivery App — Live Tracking & Package Management
Source: https://dribbble.com/shots/27731004-Dark-Mode-Delivery-App-Live-Tracking-Package-Management
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27731004-dark-mode-delivery-app-live-tracking-package-management/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Trace delivery: warm truck imagery, a route map and shipment controls communicate a complete mobile logistics flow. Credit: SM NAYMUR RAHMAN NABIL. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Finance Mobile App — Digital Wallet UI
Source: https://dribbble.com/shots/27186662-Finance-Mobile-App-Digital-Wallet-UI
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27186662-finance-mobile-app-digital-wallet-ui/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Warm orange lighting, a large central balance, and dark transaction cards create an expressive wallet interface. Credit: Nixtio. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Trading crypto finance mobile app
Source: https://dribbble.com/shots/26256933-Trading-crypto-finance-mobile-app
Swipefile reference: https://swipefile.design/ref/ms26-mobile-26256933-trading-crypto-finance-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Neon-green gradients and dark market charts create a vivid crypto-trading interface with strongly emphasized primary actions. Credit: Robin Holesinsky. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Fitness App Design
Source: https://dribbble.com/shots/25273044-Fitness-App-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-25273044-fitness-app-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Fitness timer: airy mint surfaces, full-body photography and oversized timer controls create a focused mobile training flow. Credit: Nixtio. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Fitness app design
Source: https://dribbble.com/shots/22952104-Fitness-app-design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-22952104-fitness-app-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Fitness training: athletic cutouts overlap cream cards, with lime and lilac statistics and a clear workout action. Credit: Anastasia Golovko. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Goodier - Health Fitness | App Design
Source: https://dribbble.com/shots/27636386-Goodier-Health-Fitness-App-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27636386-goodier-health-fitness-app-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Goodier: expressive orange illustrations and disciplined white screens make a memorable nutrition tracking identity. Credit: Mario Vladimirov. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: AI Music Mobile App
Source: https://dribbble.com/shots/25830504-AI-Music-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-25830504-ai-music-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Music discovery: flat phone screens use bold geometric genre discs and colorful stacked mood cards. Credit: Maria Makova. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Music Discovery Mobile App
Source: https://dribbble.com/shots/27519191-Music-Discovery-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-27519191-music-discovery-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Mood Radio: expressive dimensional characters connect mood selection with a readable music player. Credit: Victoria Grinevich. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Music Streaming Mobile App
Source: https://dribbble.com/shots/26126834-Music-Streaming-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-26126834-music-streaming-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Music streaming: confident red, yellow and white screens use vinyl imagery and editorial type for playback and discovery. Credit: Ronas IT | UI/UX Team. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Crypto Finance Mobile App UI Design
Source: https://dribbble.com/shots/27736627-Crypto-Finance-Mobile-App-UI-Design
Swipefile reference: https://swipefile.design/ref/ms26-mobile-27736627-crypto-finance-mobile-app-ui-design/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Acid-yellow cards, purple gradients, and playful controls create a vivid mobile-investing direction. Credit: Roohi Koohi ✦. Designer-published mobile apps presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Curated for the MotionSites-inspired batch (2026-10-10).

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Music Player - Mobile App
Source: https://dribbble.com/shots/25604428-Music-Player-Mobile-App
Swipefile reference: https://swipefile.design/ref/ms26-mobile-v2-25604428-music-player-mobile-app/
Captured: 2026-10-11. This is a dated reference, not a claim about the current live product.
Source scope: static designer or award presentation. This may be concept or case-study artwork. Do not infer working features, unseen screens, or tested interactions.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
Mobile apps reference. Music player: restrained cream and black screens pair a vinyl disc, strong serif type and clear playback controls. Credit: Nina Skrbic. Designer-published design presentation on Dribbble; concept or case-study artwork, implementation not independently verified. Visually reviewed for the MotionSites-inspired collection.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Accessible platform-native components express the interface; use semantic HTML when the target is mobile web. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.