Seite 15: Mock-up / Benutzeroberflächen-Entwurf
Diese Seite erklärt den Mock-up / Benutzeroberflächen-Entwurf so, dass du ihn schnell für IHK-Aufgaben anwenden kannst.
Ein Mock-up zeigt:
Wie eine Benutzeroberfläche aussehen soll
welche Felder und Buttons vorhanden sind
wie die Navigation aufgebaut ist
wo Fehlermeldungen erscheinen
wie der Benutzer durch die Oberfläche geführt wird
Wichtig:
Ein Mock-up ist kein UML-Diagramm.
Ein Mock-up zeigt keine Programmlogik.
Ein Mock-up zeigt die geplante Bedienoberfläche.
Grafik 1: Mock-up – Grundlagen
Diese Grafik zeigt die wichtigsten Bestandteile eines Mock-ups:
Fenster / App-Rahmen
Titelbereich
Navigation
Inhaltsbereich
Formularfelder
Buttons
Fehlermeldung
Benutzerführung
Wofür braucht man ein Mock-up?
Ein Mock-up wird benutzt, um eine Oberfläche vor der Programmierung zu planen.
Typische Ziele:
Benutzeroberfläche sichtbar machen
Bedienung planen
Felder und Buttons festlegen
Fehler- und Erfolgsmeldungen berücksichtigen
Benutzerführung prüfen
Missverständnisse vor der Programmierung vermeiden
Ein Mock-up beantwortet also Fragen wie:
Welche Eingabefelder braucht der Benutzer?
Welche Buttons sind notwendig?
Wo steht die Fehlermeldung?
Wie kommt der Benutzer zurück?
Was passiert nach dem Speichern?
Woran erkenne ich in einer Aufgabe, dass ein Mock-up gemeint ist?
Typische Signalwörter:
| Signalwort / Formulierung | Hinweis |
|---|---|
| Benutzeroberfläche | Mock-up wahrscheinlich |
| Oberfläche entwerfen | visuelle Darstellung gefragt |
| Formular | Eingabefelder und Buttons |
| Eingabemaske | UI-Entwurf |
| Dialogfenster | Mock-up / GUI-Skizze |
| Benutzerführung | Bedienlogik der Oberfläche |
| Wireframe | einfache Mock-up-Form |
| Entwurf | noch keine fertige Anwendung |
| Skizzieren Sie die Maske | Mock-up-Aufgabe |
| Fehlermeldung anzeigen | UI-Element berücksichtigen |
Grundidee
Ein Mock-up ist ein visueller Entwurf.
Es zeigt nicht:
Java-Code
SQL-Code
Methodenaufrufe
Datenbankstruktur
UML-Beziehungen
Sondern es zeigt:
Oberflächenaufbau
Felder
Buttons
Navigation
Meldungen
Anordnung
Bedienbarkeit
Merksatz:
Mock-up = Wie sieht die Oberfläche für den Benutzer aus?
Grafik 2: Beispiel – Produktformular
Diese Grafik zeigt ein typisches Mock-up für eine Produktverwaltung.
Enthalten sind:
Toolbar
Formularbereich
Produktname
Kategorie
Preis
Lagerbestand
Aktiv-Checkbox
Speichern-Button
Abbrechen-Button
Zurück-zur-Liste-Button
Fehlermeldung am Preisfeld
Wichtige Bestandteile eines guten Mock-ups
| Bestandteil | Bedeutung |
|---|---|
| Titel | zeigt, worum es in der Oberfläche geht |
| Navigation | Benutzer findet wichtige Bereiche |
| Eingabefelder | Benutzer kann Daten eingeben |
| Pflichtfelder | wichtige Eingaben werden markiert |
| Buttons | Benutzer kann Aktionen auslösen |
| Fehlermeldungen | Benutzer erkennt Probleme |
| Rückmeldung | Benutzer sieht, ob etwas geklappt hat |
| Abbrechen / Zurück | Benutzer kann die Aktion verlassen |
| klare Beschriftungen | Benutzer versteht die Oberfläche |
Pflichtfelder
Pflichtfelder sind Felder, die ausgefüllt werden müssen.
Typische Markierung:
Produktname *
Preis *
Kategorie *
Das * bedeutet:
Dieses Feld muss ausgefüllt werden.
Wichtig:
Pflichtfelder sollten klar erkennbar sein.
Validierung und Fehlermeldungen
Validierung bedeutet:
Das System prüft, ob die Eingabe gültig ist.
Beispiele:
Preis muss größer als 0 sein.
Produktname darf nicht leer sein.
Kategorie muss ausgewählt werden.
E-Mail-Adresse muss gültig sein.
Passwort muss lang genug sein.
Gute Fehlermeldungen stehen möglichst nah am betroffenen Feld.
Beispiel:
Preis *
[ 0,00 € ]
Preis muss größer als 0 sein.
Merksatz:
Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht.
| Button | Bedeutung |
|---|---|
| Speichern | Eingaben übernehmen |
| Abbrechen | Vorgang verlassen |
| Zurück zur Liste | zur Übersicht zurückkehren |
| Neu | neuen Datensatz anlegen |
| Bearbeiten | vorhandenen Datensatz ändern |
| Löschen | Datensatz entfernen |
Wichtig:
Buttons sollten eindeutig beschriftet sein.
Nicht ideal:
OK
Weiter
Klick
Button 1
Besser:
Speichern
Abbrechen
Zurück zur Liste
Produkt löschen
Benutzerführung
Benutzerführung bedeutet:
Der Benutzer erkennt, was er tun soll.
Eine gute Oberfläche hilft dem Benutzer durch:
klare Überschriften
verständliche Feldnamen
sinnvolle Reihenfolge der Felder
sichtbare Pflichtfelder
verständliche Fehlertexte
logische Buttons
Rückweg zur Übersicht
Merksatz:
Der Benutzer soll nicht raten müssen.
Mock-up vs. UML-Diagramme
| Mock-up | UML-Diagramm |
|---|---|
| zeigt Oberfläche | zeigt Struktur oder Ablauf |
| visuelle UI-Planung | Modellierung |
| Felder, Buttons, Navigation | Klassen, Objekte, Prozesse |
| Benutzerbedienung | Systemlogik |
| nicht zwingend formal | UML hat festere Notation |
Merksatz:
Mock-up = Oberfläche
UML = Modell
Mock-up vs. ERM
| Mock-up | ERM |
|---|---|
| zeigt Eingabemaske | zeigt Datenmodell |
| Benutzer sieht Felder | Entwickler sieht Entitäten |
| Beispiel: Produktformular | Beispiel: Produkt-Entität |
| Oberfläche | Datenstruktur |
Beispiel:
Mock-up-Feld: Produktname
ERM-Attribut: produktname
Mock-up vs. Aktivitätsdiagramm
| Mock-up | Aktivitätsdiagramm |
|---|---|
| zeigt Oberfläche | zeigt Ablauf |
| Benutzer klickt Speichern | Ablauf nach dem Klick |
| Felder und Buttons | Aktionen und Entscheidungen |
| statische Ansicht | Prozesslogik |
Beispiel:
Mock-up:
Button „Speichern“
Aktivitätsdiagramm:
Eingabe prüfen → gültig? → speichern oder Fehler anzeigen
Vorgehensweise in der Prüfung
Wenn du ein Mock-up erstellen sollst, gehe so vor:
| Schritt | Frage |
|---|---|
| 1 | Welche Aufgabe soll die Oberfläche erfüllen? |
| 2 | Wer benutzt die Oberfläche? |
| 3 | Welche Daten müssen eingegeben werden? |
| 4 | Welche Felder sind Pflichtfelder? |
| 5 | Welche Buttons braucht der Benutzer? |
| 6 | Welche Fehlermeldungen können auftreten? |
| 7 | Wie kommt der Benutzer zurück oder weiter? |
| 8 | Ist die Oberfläche übersichtlich? |
| 9 | Sind Beschriftungen eindeutig? |
Typische IHK-Fehler
| Fehler | Warum problematisch? |
|---|---|
| Pflichtfelder nicht markiert | Benutzer weiß nicht, was nötig ist |
| Fehlermeldung fehlt | Benutzer versteht den Fehler nicht |
| Fehlermeldung an falscher Stelle | Fehler ist schwer zuzuordnen |
| Buttons unklar beschriftet | Benutzer weiß nicht, was passiert |
| kein Abbrechen / Zurück | Benutzer steckt fest |
| zu viele Elemente auf einmal | Oberfläche wirkt unübersichtlich |
| Felder ohne Beschriftung | Bedeutung ist unklar |
| Oberfläche passt nicht zur Aufgabe | Anforderungen werden nicht erfüllt |
Prüfungs-Merksätze
Mock-up = visueller Oberflächenentwurf
Mock-up ist kein UML-Diagramm
Mock-up muss nicht funktionieren
Mock-up zeigt Felder, Buttons und Benutzerführung
Pflichtfelder klar markieren
Fehlermeldungen direkt am Feld anzeigen
Buttons eindeutig benennen
Benutzer soll die Oberfläche ohne Raten verstehen
Mini-Beispiel 1
Aufgabe:
Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts.
Wichtige Elemente:
Produktname *
Kategorie *
Preis *
Lagerbestand
Aktiv-Checkbox
Speichern
Abbrechen
Fehlermeldung bei ungültigem Preis
Mini-Beispiel 2
Aufgabe:
Ein Benutzer soll sich anmelden können.
Wichtige Elemente:
Benutzername / E-Mail
Passwort
Anmelden-Button
Passwort vergessen
Fehlermeldung bei falschen Zugangsdaten
Mini-Beispiel 3
Aufgabe:
Ein Kunde soll eine Bestellung abschließen können.
Wichtige Elemente:
Warenkorbübersicht
Lieferadresse
Zahlungsart
AGB-Checkbox
Bestellung abschließen
Zurück zum Warenkorb
Fehlermeldung bei fehlender Zahlungsart
Mini-Testfragen
1. Was ist ein Mock-up?
Ein Mock-up ist ein visueller Entwurf einer Benutzeroberfläche.
Es zeigt, wie die Oberfläche aussehen und bedient werden soll.
2. Ist ein Mock-up ein UML-Diagramm?
Nein.
Ein Mock-up ist kein UML-Diagramm.
Es ist ein Oberflächenentwurf.
3. Was zeigt ein Mock-up typischerweise?
Ein Mock-up zeigt zum Beispiel:
Felder
Buttons
Navigation
Fehlermeldungen
Layout
Benutzerführung
4. Was bedeutet ein Sternchen `*` an einem Feld?
Das Sternchen zeigt ein Pflichtfeld.
Beispiel:
Preis *
Der Preis muss eingegeben werden.
5. Wo sollte eine Fehlermeldung stehen?
Möglichst nah am betroffenen Feld.
Beispiel:
Preis muss größer als 0 sein.
direkt unter dem Preisfeld.
6. Warum sind eindeutige Buttons wichtig?
Weil der Benutzer erkennen muss, welche Aktion ausgelöst wird.
Besser:
Speichern
Abbrechen
Zurück zur Liste
statt:
OK
Weiter
Button 1
7. Was ist Benutzerführung?
Benutzerführung bedeutet, dass die Oberfläche dem Benutzer klar zeigt, was er tun soll.
Dazu gehören:
klare Beschriftungen
sinnvolle Reihenfolge
Fehlermeldungen
Rückwege
8. Was ist der Unterschied zwischen Mock-up und Aktivitätsdiagramm?
Ein Mock-up zeigt die Oberfläche.
Ein Aktivitätsdiagramm zeigt den Ablauf.
Beispiel:
Mock-up: Speichern-Button
Aktivitätsdiagramm: Eingabe prüfen → speichern
9. Muss ein Mock-up programmierbar oder funktionsfähig sein?
Nein.
Ein Mock-up muss nicht funktionieren.
Es zeigt die geplante Oberfläche.
10. Was ist ein häufiger Fehler bei Mock-ups?
Ein häufiger Fehler ist, dass Pflichtfelder, Fehlermeldungen oder wichtige Buttons fehlen.
Dadurch versteht der Benutzer die Oberfläche schlechter.
Nächste Seite
Danach kommt die eigene Trainer-Seite:
Mock-up-Trainer
Dort übst du:
Pflichtfelder erkennen
Fehlermeldungen richtig platzieren
notwendige Buttons auswählen
Benutzerführung bewerten
Mock-up-Elemente aus einer Aufgabenstellung ableiten