# 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:
```text
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:
```text
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:
```text
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:
```text
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:
```text
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:
```text
Java-Code
SQL-Code
Methodenaufrufe
Datenbankstruktur
UML-Beziehungen
```
Sondern es zeigt:
```text
Oberflächenaufbau
Felder
Buttons
Navigation
Meldungen
Anordnung
Bedienbarkeit
```
Merksatz:
```text
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:
```text
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:
```text
Produktname *
Preis *
Kategorie *
```
Das `*` bedeutet:
```text
Dieses Feld muss ausgefüllt werden.
```
Wichtig:
```text
Pflichtfelder sollten klar erkennbar sein.
```
---
**Validierung und Fehlermeldungen**
Validierung bedeutet:
```text
Das System prüft, ob die Eingabe gültig ist.
```
Beispiele:
```text
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:
```text
Preis *
[ 0,00 € ]
Preis muss größer als 0 sein.
```
Merksatz:
```text
Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht.
```
---
**Buttons**
Buttons lösen Aktionen aus.
Typische Buttons:
| 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:
```text
Buttons sollten eindeutig beschriftet sein.
```
Nicht ideal:
```text
OK
Weiter
Klick
Button 1
```
Besser:
```text
Speichern
Abbrechen
Zurück zur Liste
Produkt löschen
```
---
**Benutzerführung**
Benutzerführung bedeutet:
```text
Der Benutzer erkennt, was er tun soll.
```
Eine gute Oberfläche hilft dem Benutzer durch:
```text
klare Überschriften
verständliche Feldnamen
sinnvolle Reihenfolge der Felder
sichtbare Pflichtfelder
verständliche Fehlertexte
logische Buttons
Rückweg zur Übersicht
```
Merksatz:
```text
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:
```text
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:
```text
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:
```text
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**
```text
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:
```text
Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts.
```
Wichtige Elemente:
```text
Produktname *
Kategorie *
Preis *
Lagerbestand
Aktiv-Checkbox
Speichern
Abbrechen
Fehlermeldung bei ungültigem Preis
```
---
**Mini-Beispiel 2**
Aufgabe:
```text
Ein Benutzer soll sich anmelden können.
```
Wichtige Elemente:
```text
Benutzername / E-Mail
Passwort
Anmelden-Button
Passwort vergessen
Fehlermeldung bei falschen Zugangsdaten
```
---
**Mini-Beispiel 3**
Aufgabe:
```text
Ein Kunde soll eine Bestellung abschließen können.
```
Wichtige Elemente:
```text
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:
```text
Felder
Buttons
Navigation
Fehlermeldungen
Layout
Benutzerführung
```
4. Was bedeutet ein Sternchen `*` an einem Feld?
Das Sternchen zeigt ein Pflichtfeld.
Beispiel:
```text
Preis *
```
Der Preis muss eingegeben werden.
5. Wo sollte eine Fehlermeldung stehen?
Möglichst nah am betroffenen Feld.
Beispiel:
```text
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:
```text
Speichern
Abbrechen
Zurück zur Liste
```
statt:
```text
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:
```text
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:
```text
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:
```text
Mock-up-Trainer
```
Dort übst du:
```text
Pflichtfelder erkennen
Fehlermeldungen richtig platzieren
notwendige Buttons auswählen
Benutzerführung bewerten
Mock-up-Elemente aus einer Aufgabenstellung ableiten
```