MasterAI

Claude Design: Mobile App Click-Prototyp & Hand-off zu Claude Code

15. Mai 2026·24 min·Claude Design, Anthropic, Mobile App, Prototype, Claude Code, Hands-on

Mit dem "Interactive prototype"-Skill produziert Claude Design echte klickbare Prototypen — Buttons funktionieren, Navigation springt zwischen Screens, Modals öffnen sich. Diese Übung baut eine Mobile App für B2B-Kunden. Und zum ersten Mal in dieser Serie nutzen wir den Hand-off zu Claude Code — der Schritt, der den Prototyp in eine echte produktive App verwandelt.

Teil 5 von 5 — Lies zuerst Übung 3 (Design System), da Mobile-UI am stärksten von einem Brand-System profitiert.

Warum Mobile App Mockups jetzt zugänglich sind

Ein Mobile-App-Mockup war bisher Spezialisten-Gebiet: Figma + Prototyping-Setup, Sketch oder ein UX-Designer im Team. Für Solo-Founder oder KMU ohne Design-Department hieß das: entweder Budget investieren — oder die App-Idee als Text-Beschreibung an Entwickler übergeben und auf das Beste hoffen.

Claude Designs Interactive Prototype schließt diese Lücke. Zwei direkte Anwendungsfälle:

Stakeholder-Validierung vor Code-Entwicklung — zeig die App deinem Mitgründer oder ersten Pilotkunden und sammel echtes Feedback, bevor 30k € Entwicklungsbudget verbrannt sind
Investoren-Pitch mit klickbarer Demo — kein abstraktes "Wir bauen X", sondern "Hier ist X — probier's aus"

Das Szenario: Bergwerk Café-Manager App

Wir bauen eine Mobile App für Bergwerks B2B-Kunden — Café-Inhaber, Restaurant-Manager, Hoteliers — mit der sie ihr Bohnen-Abo unterwegs verwalten.

Kern-Screens:

Onboarding/Splash
Dashboard (aktuelle Lieferung, nächste Anpassung, Verbrauch)
Sortiment-Browser mit Filterung
Bestellung anpassen (Mengen, Sorten, pausieren)
Profil & Support

Schritt 1: Screen-Brief vorbereiten

Mehr als bei Websites und Decks zählt hier die Detailtiefe. Pro Screen definierst du:

Name + Zweck in einem Satz
Datenpunkte die angezeigt werden (3–7 pro Screen)
Aktionen die der User triggern kann (1–3 pro Screen)
Navigations-Ziel wohin jede Aktion führt

Warum das so wichtig ist: Mobile-Screens sind dicht. Kein Whitespace zum Improvisieren. Ein schlechtes Briefing führt zu Screens, die korrekt aussehen aber tot sind — Buttons ohne Ziel, fehlende Empty States.

Vollständiges Beispiel (Auszug):

# Bergwerk Café-Manager — Mobile App Screens

Format: iOS-style, 9:19.5 (iPhone-Frame)
Navigation: Bottom Tab Bar mit 4 Tabs

## Screen 2: Dashboard / Übersicht

Inhalte:
- Greeting-Zeile: "Hallo Lukas" (Café Brenner, Salzburg)
- Card "Diese Woche": 4 Bohnen-Chips mit Mengen, Lieferdatum,
  Status "In Vorbereitung"
- Card "Nächste Anpassung": CTA "Bestellung anpassen" → Screen 4
- Card "Verbrauch": 23 kg im Mai, Balken-Diagramm

## Screen 4: Bestellung anpassen

Inhalte:
- Pro Bohne: Sorte, Menge in kg (Stepper +/-), Toggle "Diese Woche dabei"
- Lieferung: Datum-Wahl (tappable)
- Toggle: "Diese Woche pausieren"
- Sticky Bottom-Button: "Änderungen speichern" (deaktiviert wenn keine Änderung)

Aktionen:
- Stepper → Live-Update der Mengen
- "Speichern" → Bestätigungs-Modal → zurück zu Dashboard
- "Abbrechen" → zurück ohne Speichern

Schritt 2: Projekt anlegen und Skills wählen

Geh auf claude.ai/design → "New Project" → "Prototype"
Name: "Bergwerk Café-Manager App"
Design system: dein in Übung 3 publiziertes System auswählen
High Fidelity wählen (nicht Wireframe)
Klick "Create"

Wireframe vs. High Fidelity: Wireframe für die erste interne Diskussion. High Fidelity für Stakeholder-Reviews, Investoren-Pitches und den Hand-off zu Claude Code — production-ready Look von Anfang an.

Skills-Kombination:

| Kategorie | Skill | Warum | |-----------|-------|-------| | Output-Type | Interactive prototype | Working app with real interactions | | Behavior | Make tweakable | State-Toggles im Tweak Panel | | Export-Format | Save as standalone HTML | Backup-Variante und Sharing |

Schritt 3: Eröffnungs-Prompt

Make an interactive mobile app prototype from the attached
screens briefing.

Format: iOS-style mobile app in an iPhone frame (status bar with
time 9:41, home indicator). 5 screens with real click-through
navigation between them.

Audience: Café and restaurant owners, age 35–60,
moderate tech literacy. They use this app between customer
orders, often one-handed.

Visual style: Use the Bergwerk Coffee design system. Editorial
but mobile-optimized — larger touch targets, generous tap areas,
no hover states.

Interaction design:
- Bottom tab bar with 4 tabs (Dashboard, Sortiment, Bestellung,
  Profil) persistent across screens 2–5
- Active tab visually distinct
- All buttons must be tappable and lead somewhere — no dead ends
- Steppers (+/-) update displayed values
- Toggles visually flip when tapped
- Modals slide up from bottom (iOS bottom sheet pattern)

Mobile-native feel:
- Status bar always visible
- Bottom safe-area respected
- No web-style hover effects
- iOS-native easings

Add a Tweak Panel:
- Auth state toggle (logged-out / logged-in)
- Order state toggle (active / paused) — affects dashboard and
  adjust screen synchronously
- Accent color swatches from the brand palette

Generate all 5 screens, fully wired up. German UI throughout.

Schritt 4: Was Claude baut — kein Clarifying-Questions-Flow

Bei klickbaren Mobile-Prototypen kommt kein Clarifying-Questions-Flow wenn dein Briefing sauber strukturiert ist. Claude legt direkt los und zeigt, welche Entscheidungen er trifft:

Screens
1. Dashboard — Greeting, "Diese Woche" card with 4 bean chips,
   "Nächste Anpassung" card, "Verbrauch" card with mini chart.
2. Sortiment — 5 filter chips (live filter), 6 bean cards,
   tap → detail sheet slides up.
3. Bestellung — per-bean Toggle + Stepper (active),
   date picker sheet, "pausieren" toggle, sticky save bar
   (disabled until dirty) → confirmation sheet → back to Dashboard.
4. Profil — Avatar, Konto/Service/App sections, call sheet,
   Abmelden returns to splash.

Mobile-native bits
- Translucent bottom tab bar with active indicator
- 44px tap targets on steppers
- Sheets slide up with iOS easing
- iOS-style toggles

Schritt 5: Caveats lesen

Transparent, was Claude inferiert hat und was du prüfen solltest:

Caveats / next
- The Decaf filter chip scrolls horizontally (intentional, but
  worth noting on first glance).
- Confirmation sheet currently just returns to Dashboard —
  could persist the new saved snapshot for "undo".

Beide Punkte sind nützlich: eine bewusste Design-Entscheidung die benannt wird, und ein Verbesserungsvorschlag für die nächste Runde.

Schritt 6: Review und Tweak Panel

Das Tweak Panel bei Mobile Apps — passend zum konkreten Output gebaut:

| Control | Typ | Wirkung | |---------|-----|---------| | Auth | Toggle | Splash ↔ Dashboard als Entry-Screen | | Bestellung | Toggle | Aktiv ↔ Pausiert — Dashboard und Adjust-Screen synchron | | Akzentfarbe | Swatches | 4 Farben aus dem Brand-System | | Quick-Nav-Buttons | Buttons | Springe direkt zu jedem Tab |

Quick-Nav-Buttons sind das wichtigste Feature für Reviews: Du musst nicht jeden Screen über den Happy Path erreichen. Direktsprung zu jedem Tab — spart massiv Zeit beim Review.

Review-Strategie — der "ersten Benutzung"-Test:

Happy Path komplett — Splash → Dashboard → Bestellung anpassen → Speichern → zurück
Alle Tabs und Karten testen — gibt es Sackgassen?
State-Variationen via Tweak Panel — Auth auf Splash, Bestellung auf Pausiert — bleibt die App konsistent?

Mobile-spezifisch prüfen:

Touch-Targets mindestens 44×44 pt (iOS-Standard)
Sticky Bottom-Buttons respektieren die Home-Indicator-Zone
Body-Text mindestens 16 pt

Schritt 7: Mobile-spezifische Iteration

Pattern 1: Tweak Panel für State-Varianten nutzen

"Add a Tweak Panel toggle: 'Last week of the month' state.
When ON, show an additional 'Kommender Monat' card with
a brief summary of next month's default delivery plan."

Pattern 2: Mobile-native Details

"Make all sticky bottom buttons 16pt taller and add 12pt
extra padding above the home indicator area."

"Tab bar icons feel oversized. Reduce icon size by 20%
and add 4pt vertical spacing between icon and label."

"When buttons are tapped, briefly scale to 0.96× for 100ms
before the action triggers. Native iOS feel."

Pattern 3: Empty States anfordern

"For the Dashboard screen, generate an empty state variant:
User logged in but no order placed yet.
Show: Headline 'Noch keine Lieferung geplant',
CTA 'Beratungstermin vereinbaren' (links to Screen 5),
minimal illustration in brand colors."

Schritt 8: Hand-off zu Claude Code

Das ist der Schritt, der Claude Design grundlegend anders macht als Figma oder Sketch. Du übergibst den Prototyp an Claude Code, der daraus eine echte App baut.

Was passiert beim Hand-off

Im Share-Menü: "Handoff to Claude Code" auswählen
Wahl: lokaler Claude Code (in deinem Editor) oder Claude Code Web
Claude Design packt das komplette Bundle:
- Alle Screens als HTML/CSS/JS
- Design-System-Tokens
- Komponenten-Struktur
- Navigations-Logik
- State-Definitionen aus dem Tweak Panel

Hand-off-Prompt

I'm attaching the Claude Design handoff bundle for the
Bergwerk Café-Manager mobile app.

Please:
1. Set up a React Native project with Expo
2. Use Tailwind via NativeWind for styling —
   match design system tokens 1:1 from the bundle
3. Implement all 5 screens with React Navigation:
   - Stack navigator for auth flow
   - Bottom tab navigator for main app
4. Make steppers, toggles and date pickers functional
   with React state
5. Mock the API layer — placeholder fetch functions
   returning static data matching the prototype content
6. Basic accessibility: VoiceOver labels for all
   interactive elements
7. README with setup instructions and where to plug in
   real API endpoints later

Use latest stable dependencies.
Don't write any code yet — first show me the proposed folder
structure and tech-stack choices so I can confirm.

Letzter Satz ist entscheidend: "Don't write any code yet — first show me the folder structure." Zwingt Claude Code in Plan-Mode, bevor er tausende Zeilen schreibt die du zurückrollen müsstest.

Was du danach hast

Nach 30–60 Minuten Claude-Code-Generation:

Lauffähige React-Native-App mit allen 5 Screens
Funktionierende Navigation mit React Navigation
Working State für Stepper, Toggles, Tab-Selektion
Vorbereitete API-Layer mit Mocks
README mit Setup-Anleitung

Was noch für Production fehlt:

Echte Backend-API anbinden
Push-Notifications
App-Icon und Splash-Screen finalisieren
iOS- und Android-Tests
TestFlight / Play Store Setup

Aber: Von Idee zu deployable Mobile-App-Prototyp in einem Arbeitstag. Das ist der Effizienz-Sprung.

Pro-Tipps

Briefing-Detail-Level: Bei Mobile Apps gilt: alle Datenpunkte konkret (nicht "Liste von Bohnen" sondern die echten Namen), alle Aktionen mit Navigations-Ziel, Edge Cases benennen.

Native iOS-Feeling explizit fordern: "Make it feel like a native iOS app — no hover states, native easings, safe-area respect." Sonst rutscht der Output ins Web-Look-Feel.

Tech-Stack im Hand-off benennen: React Native + Expo (Cross-Platform, schnelle Iteration), Flutter (wenn dein Team Dart kann), Swift/SwiftUI (iOS-only, native Performance). Schreib deine Wahl explizit in den Hand-off-Prompt.

Erfolgs-Check

✓ 5 Screens mit klaren Datenpunkten und Aktionen im Briefing definiert
✓ High Fidelity gewählt, Design-System im Dialog ausgewählt
✓ Interactive prototype + Make tweakable Skills aktiviert
✓ Happy Path von Splash bis Bestellung-Speichern komplett durchklickbar
✓ Tweak Panel mit Quick-Nav und State-Toggles aktiv genutzt
✓ Touch-Target-Größen und Safe-Area in der Iteration geprüft
✓ Hand-off zu Claude Code mindestens im Share-Menü geöffnet

Quellen

← Zu allen Tutorials