Design-Prompt verwenden
Projektanforderungen hinzufügen
Füge unten deinen Kontext hinzu. Er wird beim Kopieren oder Herunterladen in den Design-Prompt aufgenommen.
Erstelle mit dem vorhandenen Projekt-Stack einen bearbeitbaren Mobile-First-App-Prototyp für [PROJECT] und [AUDIENCE]. Die Aufgabe lautet: Pendler-Ticket-Wallet.
Erforderliche Inhalte und Struktur
Wähle einen Ausgangsort, ein Ziel und eine Abfahrtszeit, prüfe einen eindeutig als Demonstration gekennzeichneten Fahrpreis und zeige anschließend ein Beispielticket mit seinem Gültigkeitszeitraum.
Ansichten und Navigation
Erstelle drei verbundene Ansichten: Fahrt wählen; Ticket prüfen; Meine Tickets. Halte den ausgewählten Datensatz im Bildschirmtitel oder in der Zusammenfassung sichtbar. Unterstütze eine eindeutige Zurück-Aktion und bewahre unfertige Eingaben beim Wechsel zwischen den Ansichten. Platziere die primäre Aktion nahe bei den relevanten Inhalten und berücksichtige mobile Sicherheitsbereiche, eine sichtbare Bildschirmtastatur und lange übersetzte Beschriftungen. Passe die Komposition bei Desktop-Breiten an, ohne einen Schritt zu entfernen oder die Aufgabe zu verändern.
Projektvorgaben
Verwende [APPROVED_CONTENT] für Namen, Datensätze, Beschriftungen, Mengen und Ziele. Frage nach fehlenden Daten, statt Angaben zum Betrieb zu erfinden. Für Demonstrationsdatensätze darf die fiktive Marke Metroday verwendet werden; kennzeichne sie als Beispieldaten. Erkläre, welche Aktionen lokale Interaktionen des Prototyps sind und welche Authentifizierung, Persistenz, Berechtigungen oder ein Backend erfordern würden. Verbinde keine externen Dienste und behaupte nicht, eine Transaktion sei abgeschlossen worden, sofern diese Integration nicht ausdrücklich implementiert und getestet wurde.
Designausrichtung
Befolge [BRAND_RULES]. Wenn keine Marke vorgegeben ist, verwende Weiß, tiefes Marineblau, elektrisches Limettengrün und ÖPNV-Typografie. Mache den Ablauf durch eigene Inhalte und Bedienelemente erkennbar, statt generische Dashboard-Karten zu wiederholen. Verwende eine konsistente Abstandsskala und eine klare Texthierarchie. Integriere einen sichtbaren Tastaturfokus, barrierefreie Namen, ausreichenden Kontrast und Statusbeschriftungen, die nicht allein auf Farbe beruhen. Berücksichtige reduzierte Bewegung und halte animierte Übergänge optional.
Aufgabenspezifische Abnahmeprüfung
- Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig.
Interaktionszustände
Implementiere den erfolgreichen Ablauf über drei Bildschirme mit lokalen Beispieldaten. Füge einen hilfreichen Leerzustand, eine Validierung vor Abschluss einer Aktion, einen Lade- oder Ausstehend-Status und einen behebbaren Fehlerzustand hinzu. Destruktive Änderungen erfordern eine Prüfung oder eine Möglichkeit zum Rückgängigmachen. Halte den Zustand eines Datensatzes in allen drei Ansichten konsistent. Verwirf teilweise ausgefüllte Eingaben nicht unbemerkt und ändere die Auswahl einer Person nach einem erneuten Versuch nicht.
Übergabe und Prüfung
Gib die bearbeitbaren App-Ansichten zurück und erläutere das Datenmodell, das Verhalten des lokalen Speichers sowie nicht implementierte Integrationen. Teste bei 320px und in einem breiteren Viewport, mit Tastaturnavigation und langen Inhalten. Prüfe das Ergebnis anhand der oben genannten aufgabenspezifischen Abnahmekriterien, bevor du Funktionen hinzufügst. Hebe das Demonstrationsverhalten klar von einem laufenden Produktivdienst ab.
Referenzanhang und Rekonstruktionsziel
Füge reference.webp aus dem Download-Paket dieses Prompts zusammen mit diesem Prompt in OpenDesign ein. Erstelle ein bearbeitbares Ergebnis mit ähnlicher Komposition und Hierarchie; binde nicht das gesamte Referenzbild als fertige Benutzeroberfläche ein. Bewahre freigegebene Projektinhalte und Markenregeln, wenn sie fiktiven Beispielbeschriftungen widersprechen. Falls das Bild fehlt oder unleserlich ist, frage danach, anstatt visuelle Übereinstimmung zu behaupten.
Komposition und Inhalt der Referenz
Verwende die angehängte Datei reference.webp als visuelle Referenz für das Pendler-Ticket-Wallet. Ermittle vor der Umsetzung die wichtigsten Bereiche von oben nach unten, ihre relativen Breiten und Höhen, Ausrichtung, Abstände, typografische Hierarchie, Flächenfarben, Rahmen, Bildmaterial und wiederkehrenden Komponenten. Bewahre diese Beziehungen, statt sie durch eine generische Vorlage zu ersetzen. Erforderlicher Aufgabeninhalt: Wähle einen Startort, ein Ziel und eine Abfahrtszeit, prüfe einen eindeutig als Demonstration gekennzeichneten Fahrpreis und zeige anschließend ein Beispielticket mit seinem Gültigkeitszeitraum. Nutze bei der Übertragung des Bildes in bearbeitbare Elemente die folgenden aufgabenspezifischen Layout-Vorgaben: Beginne mit „Fahrt wählen“ als Einstiegsansicht, gib „Ticket prüfen“ eine klare primäre Aktion und erläutere unter „Meine Tickets“, was geschehen ist und was als Nächstes möglich ist. Verwende Weiß, tiefes Marineblau, elektrisches Limettengrün und ÖPNV-Typografie als Ausgangsrichtung und passe sie an die vorgegebene Marke an. Halte die Identität des Datensatzes und den Navigationskontext über alle drei Ansichten hinweg sichtbar. Priorisiere mit dem Daumen gut erreichbare Bedienelemente und lesbare Beschriftungen gegenüber dekorativen Flächen; halte den Ablauf auf breiteren Bildschirmen schlüssig, statt eine mobile Komposition über die gesamte Breite zu strecken.
Visuelle Ausrichtung aus den beispielhaften Projektanforderungen
Weiß, tiefes Marineblau, elektrisches Limettengrün, ÖPNV-Typografie.
Interaktionsspezifikation
Die Referenz ist ein statisches Konzept: Das nachfolgend beschriebene Verhalten ist eine zu implementierende Anforderung und kein Beleg dafür, dass das Bild bereits funktioniert. Kopiere den angepassten Prompt in dein Projekt und erstelle den verbundenen Ablauf: Wähle einen Startort, ein Ziel und eine Abfahrtszeit, prüfe einen eindeutig als Demonstration gekennzeichneten Fahrpreis und zeige anschließend ein Beispielticket mit seinem Gültigkeitszeitraum. Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig. Gib für jedes sichtbare Bedienelement seinen Auslöser, den betroffenen Zustand und das Feedback an; implementiere lokale Änderungen mit konsistentem Zustand über zusammengehörige Ansichten hinweg. Sorge dafür, dass Suche und Filter echte Ergebnisse liefern, Auswahlsteuerungen einen eindeutigen aktiven Zustand haben und Speicheraktionen gegebenenfalls sichtbares Feedback für ausstehende, erfolgreiche und fehlgeschlagene Vorgänge anzeigen. Füge keine sachfremden Abläufe hinzu. Verwende richtige Links für die Navigation, Schaltflächen für Aktionen und barrierefreie Namen für Symbol-Bedienelemente. Erwecke nicht den Eindruck, dass ein Backend-Vorgang erfolgreich war, wenn sich lediglich eine lokale Demo geändert hat.
Visueller Vergleich und Übergabe
- Vergleiche das Ergebnis bei übereinstimmenden Proportionen mit dem angehängten Bild. Prüfe vor der Ausarbeitung dekorativer Details die Platzierung der Hauptbereiche, relative Bildgrößen, Zeilenumbrüche, Abstände, typografische Hierarchie, Kontrast, aktive Zustände und Inhaltsdichte.
- Teste anschließend das schmale Layout, ohne Desktoptexte in winzige Beschriftungen zu zwängen.
- Halte Logos, Fotos und Symbole als separate Assets und alle aussagekräftigen Beschriftungen bearbeitbar. Führe nicht verfügbare Schriftarten und Assets sowie beabsichtigte Abweichungen auf. Gib die funktionsfähigen Dateien zusammen mit einer knappen Beschreibung des implementierten Verhaltens und der noch ausstehenden Integrationen zurück; versprich nicht allein auf Grundlage des Prompts ein pixelgenaues Ergebnis.
Design-Prompt + Bild herunterladen
Enthält den vollständigen Design-Prompt und das Referenzbild in voller Größe. Füge beides in OpenDesign hinzu, um das Layout zu steuern.
So verfasst du einen Design-Prompt für ein Pendler-Ticket-Wallet
Verwende diesen Design-Prompt für ein Pendler-Ticket-Wallet, um einen Startort, ein Ziel und eine Abfahrtszeit auszuwählen, einen eindeutig als Demonstration gekennzeichneten Fahrpreis zu prüfen und anschließend ein Beispielticket mit seinem Gültigkeitszeitraum anzuzeigen.
Die Referenz ist ein KI-generiertes Konzept. Die folgenden Anweisungen beschreiben, was erstellt und getestet werden soll; das Bild belegt kein funktionsfähiges Verhalten.
Ticketgültigkeit offline lesbar machen
Ein Pendler-Ticket-Wallet muss klar zwischen gespeicherten Informationen und einer gültigen Fahrtberechtigung unterscheiden.
Ein Beispielfahrpreis und ein Beispielticket müssen klar als Demonstration erkennbar bleiben. Beginne mit „Fahrt wählen“ als Einstiegsansicht, gib „Ticket prüfen“ eine klare primäre Aktion und erläutere unter „Meine Tickets“, was geschehen ist und was als Nächstes möglich ist. Verwende Weiß, tiefes Marineblau, elektrisches Limettengrün und ÖPNV-Typografie als Ausgangsrichtung und passe sie an die vorgegebene Marke an. Halte die Identität des Datensatzes und den Navigationskontext über alle drei Ansichten hinweg sichtbar. Priorisiere mit dem Daumen gut erreichbare Bedienelemente und lesbare Beschriftungen gegenüber dekorativen Flächen; halte den Ablauf auf breiteren Bildschirmen schlüssig, statt eine mobile Komposition über die gesamte Breite zu strecken.
Aus dem Prompt
Erstelle drei verbundene Ansichten: Fahrt wählen; Ticket prüfen; Meine Tickets.
An dein Projekt anpassen
Ermögliche Nutzenden, eine Fahrt auszuwählen und einen gekennzeichneten Demofahrpreis zu prüfen. Zeige ein Beispielticket mit seinem Gültigkeitszeitraum und unterscheide zukünftige, aktuelle und abgelaufene Zustände auch ohne Verbindung.
Inhalte für das Pendler-Ticket-Wallet vorbereiten
Der Überprüfungsbildschirm zeigt Strecke, Ticketart, Gültigkeit und Preis vor dem Kauf. Verwende die genauen Tarifregeln und verstecke Einschränkungen nicht hinter der Zahlungsschaltfläche.
Stelle Beispielhaltestellen, Abfahrtszeiten, Demonstrationsfahrpreise und Gültigkeitszeiträume für Tickets bereit. Beziehe zukünftige und abgelaufene Tickets ein und lege fest, welche Details offline gespeichert werden können, ohne den Eindruck zu erwecken, dass die Demo Fahrkarten ausstellt.
Aus dem Prompt
Wähle einen Ausgangsort, ein Ziel und eine Abfahrtszeit, prüfe einen eindeutig als Demonstration gekennzeichneten Fahrpreis und zeige anschließend ein Beispielticket mit seinem Gültigkeitszeitraum.
An dein Projekt anpassen
Verwende für [PROJECT] [APPROVED_CONTENT] als Quelle für dieses Pendler-Ticket-Wallet. Freigegebene Datensätze und Feldbeschriftungen für „Fahrt wählen“, „Ticket prüfen“ und „Meine Tickets“; Aktions- und Persistenzregeln; Markenressourcen und Berechtigungsanforderungen. Ermittle fehlende Eingaben, bevor du sie durch Demonstrationsinhalte ersetzt.
Ein abgelaufenes Ticket offline öffnen
Die Wallet unterscheidet ein aktives QR-Ticket von bevorstehenden und abgelaufenen Tickets. Teste Offlineverfügbarkeit und Validierungszustände; der Beispiel-QR-Code darf nicht als nutzbares Ticket dargestellt werden.
Das Ticket darf weiterhin angezeigt werden, doch sein abgelaufener Status muss unmissverständlich sein. Die Offline-Verfügbarkeit darf niemals als Beleg dafür dargestellt werden, dass das Ticket für die Fahrt genutzt werden kann. Teste zuerst diesen konkreten Grenzfall: Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig. Führe anschließend den Hauptablauf mit einem langen Datensatztitel, ohne gespeicherte Datensätze und mit einer fehlgeschlagenen Aktion aus. Nutzende müssen ohne alleinige Abhängigkeit von Farbe erkennen können, was gespeichert ist, was noch aussteht und was rückgängig gemacht werden kann. Prüfe, ob die Rückkehr zum vorherigen Bildschirm eingegebene Daten bewahrt und ob ein Screenreader Titel, Status und primäre Aktion in einer sinnvollen Reihenfolge erfasst.
Aus dem Prompt
Halte abgelaufene und zukünftige Tickets klar getrennt; die Offline-Anzeige darf nicht den Eindruck erwecken, dass ein Ticket für die Fahrt gültig ist.
An dein Projekt anpassen
Prüfe das Pendler-Ticket-Wallet anhand dieser Anforderung: Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig. Teste zuerst diesen konkreten Grenzfall: Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig. Führe anschließend den Hauptablauf mit einem langen Datensatztitel, ohne gespeicherte Datensätze und mit einer fehlgeschlagenen Aktion aus. Nutzende müssen ohne alleinige Abhängigkeit von Farbe erkennen können, was gespeichert ist, was noch aussteht und was rückgängig gemacht werden kann. Prüfe, ob die Rückkehr zum vorherigen Bildschirm eingegebene Daten bewahrt und ob ein Screenreader Titel, Status und primäre Aktion in einer sinnvollen Reihenfolge erfasst. Bewahre die freigegebenen Inhalte und überarbeite nur die Teile, die diese Prüfung nicht bestehen.
Ergebnis deines Pendler-Ticket-Wallets prüfen
Das Beispiel ist ein KI-generiertes visuelles Konzept. Verbundene Dienste, Geräteberechtigungen und persistente Daten erfordern eine separate Implementierung und Prüfung.
- Halte abgelaufene und zukünftige Tickets klar getrennt; die Offline-Anzeige darf nicht den Eindruck erwecken, dass ein Ticket für die Fahrt gültig ist.
Anschluss-Prompt
Verwende dies nach dem ersten Ergebnis. Dadurch wird die Überarbeitung auf den wichtigsten Teil dieser Aufgabe eingegrenzt.
Verfeinere ausschließlich den Übergang von „Ticket prüfen“ zu „Meine Tickets“. Unterscheide abgelaufene und zukünftige Tickets eindeutig; die Offline-Anzeige darf nicht den Eindruck erwecken, ein Ticket sei für die Fahrt gültig. Zeige die relevanten ausstehenden, fehlgeschlagenen und abgeschlossenen Zustände mit eindeutigen Beschriftungen. Behalte die freigegebene Navigation, Typografie und die übrigen Ansichten bei. Gib die geänderten Ansichten zurück und beschreibe, wie eingegebene Daten einen erneuten Versuch überstehen.
