# Case Study – Split-Twint
## Ausgangslage
Die gestaltenden Personen haben die Aufgabe, die kontaktlose Bezahlungsapp Twint um eine Funktion zu erweitern, damit eine gemeinsame Rechnung einer Konsumation je Person bezahlt werden kann. Übliche soziale Konventionen und Gegebenheiten die sich bei der Bezahlung mit Bargeld ergeben sollen auch digital unersucht werden und ermöglicht sein. Am ende des Tages wird ein LoFi-Prototyp erwartet, der die Funktion und den Userflow ersichtlich macht.
### Beispiel
Folgende Konsumation dient als Beispiel zur Untersuchung und visualisierung.
#### Vier Personen
* Tim (hat kein Twint)
* Karl (hat Twint)
* Klara (hat Twint)
* Gaby (hat Twint)
#### Konsumation
| Person | Bestellung | Preis |
| ----------------- | ------------------ | ----------- |
| Karl, Klara, Gaby | 1 × Apéro-Platte | CHF 28.– |
| Karl, Klara Gaby | 1 × 0.75 l Wein | CHF 34.– |
| Alle | 1 × 1 l Mineralwasser | CHF 13.– |
| Tim | 2 × 3 dl Rivella | je CHF 5.– |
| Karl | 1 × Menü 1 | CHF 25.– |
| Klara, Gaby | 2 × Menü 2 | je CHF 24.– |
| Alle | 4 × Herbst-Dessert | je CHF 9.– |
| Tim, Klara, Gaby | 3 × Espresso | je CHF 4.– |
## Termine & Abgabe
* **11:20** Austausch in Klasse – Doku in HackMD
* **14:00** Zwei Screenshots je Gruppe in HackMD
* **14:45** Austausch in Klasse – Abgabe in HackMD
## Technische Voraussetzung
Innerhalb der bestehenden Twint-App kann
## Präsentation (11:20 Uhr)
Die Zwischenpräsentation dient dem Lernprozess und soll einen Austausch innerhalb der Klasse fördern. Die Qualität des Entwurfs wird noch nicht beurteilt.
## Abgabe & Präsentation (14:45 Uhr)
* Funktion ist visualisiert
* Der Ablauf ist visualisiert
* Die Abgabe ist aussagekräftig um das Konzept verständlich
## Bewertung
### Technik (10 %)
* Die Abgegebenen Visualisierungen sind für eine spätere Überarbeitung aussagekräftig
* Die Realisation orientiert sich an technisch machbarem
### Inhalt (30 %)
* Aufgabestellung wurde analysiert und entsprechende Antworten vorgeschlagen
* User journey ist durchdacht und visualisiert
* Alle Inhaltselemente wurden genügend visualisiert
* Komplexität wurden für eine allgemeine Nutzergruppe angepasst
### Interaktion/Führung (50 %)
* Interaktion ist schlüssig und schnell zugänglich
* Interaktion ist für breite Bevölkerung optimiert
* Die Leseführung/Menüführung ist überlegt und offensichtlich
* Interface-Konzepte ist leicht zugängliche
### Grafisches Konzept (10 %)
* Das Grafische Konzept ist schlüssig und durchgängig
* Typografie überlegt eingesetzt
* Screenarchitektur überlegt
* Zweckmässigkeit gegeben
## Research
### Splitwise
* Chantal
* Cheyenne
* Dan
* Flavia
* Joshua
| | |
| -------- | -------- |
|  |  |
|  |  |
**Fazit:**
* App ist auf mehrere langfristige Payments einer Gruppe ausgelegt (z.B. WG, auf Reisen, Ausgang)
* Die effektive Zahlung, z.B. im Restaurant, erfolgt offline von einer Person
* Schulden untereinander werden via PayPal oder über einen anderen Kanal beglichen
* Payments können individuell aufgeteilt werden
* Die App ist sozusagen ein digitales Rechnungsbüchlein
* Trinkgeld muss von der Gruppe selber einberechnet werden
___
### Plates von Splitwise
* Dominique
* Sam
* Stefanos
<br>
| | |
| -------- | -------- |
|  |  |
|  |  |
|  |  |
|  |  |
|  |  |
|  |  |
<br>
**Fazit:**
* Funktioniert ausschliesslich im Restaurant
* Für US Markt ausgelegt (Tax, Tip)
* Gleichmässige Teilung einfach möglich
* Beträge können per drag & drop auf Personen zugewiesen werden
* Bezahlen kann man mit der App nicht
* Notwendigkeit fraglich (Mehrwert gegenüber Taschenrechner?)
<br>
___
### Bezahlen mit Bargeld – Aufsplittung manuell oder mit Taschenrechner, aber ohne App
* Nina
* Patrick
* Samira
* Selina


#### Ablauf 1
* Gruppe bestellt Rechnung
* Service kommt mit Rechnung
* Jedes Gruppenmitglied zählt auf, was er konsumiert hat und Service rechnet dies dann für jedes Gruppenmitglied einzeln aus (manuell oder mit Taschenrechner)
* Jeder zahlt seinen Betrag
#### Ablauf 2
* Gruppe bestellt Rechnung
* Service kommt mit Rechnung
* Ein Gruppenmitglied zahlt für alle mit Bargeld
* Die anderen Gruppenmitglieder zahlen dieser Person dann jeweils den eigenen Betrag zurück
#### Ablauf 3
* Gruppe bestellt Rechnung
* Service kommt mit Rechnung
* Der gesamte Betrag wird durch Anzahl Personen geteilt (manuell oder mit Taschenrechner :)
* Jeder zahlt seinen Teil
#### Ablauf 4 (mit App)
* Gruppenmitglieder werden auf «Splid» erfasst
* Gruppe erfasst alle Zahlungen in «Splid» und definiert die dafür aufkommenden Mitglieder
* Alle Zahlungen werden für die betreffenden Personen berechnet und benachrichtigt die Mitglieder mit der Schlussberechnung
* Sobald die Ausgaben / Einnahmen untereinander ausbezahlt und in «Splid» bestätigt wurden, wird es in «Splid» bestätigt
* Jeder zahlt seinen Teil
1. 
2. 
3. 
4. 
5. 
6.

#### Ablauf 5
* Bei Fremdwährungen in den Ferien
* Jeder gibt ein Betrag in ein gemeinsames «Kässeli»
* Mit diesem Bargedl wird dann gemeinsames Essen bezahlt
#### Situationen mit Bargeld
* Unangenehm, weil es untereinander diskutiert werden muss
* Hat man es passend dabei?
* Hat man nur grosse Noten
* Hat man zu viel Kleingeld (Münz)
* Hat man kein Bargeld dabei (sondern nur Karte)
* Wieviel Trinkgeld?
* Beide möchten einladen
* Einer geht davon aus, dass der andere bezahlt
*
#### Bargeldsituation für Servicepersonal
* Am angenehmsten: Ablauf 2 (Einer zahlt alles)
+ geht schneller
+ Nur 1x Rückgeld
+ Keine unangenehme Situation mit Kunden
+ Weniger Kopfrechnen
## Gruppe 1
* Dominique
* Nina
* Patrick
* Chantal
**1) Zwischenstand:**

**2) Abgabe**
***User Journey***
https://www.figma.com/proto/EOZPXmG7E1LgKMXB3Mj2Kc/Gemeinsam-zahlen?node-id=72%3A10&scaling=min-zoom
***Figma Prototyp***
https://www.figma.com/proto/EOZPXmG7E1LgKMXB3Mj2Kc/Gemeinsam-zahlen?node-id=1%3A138&viewport=1201%2C619%2C0.38164305686950684&scaling=contain
***Screens***
| | | |
| -------- | -------- | -------- |
|  |  |  |
|  |  | |
|  |  | |
|  |  |
-----------------------------------
## Gruppe 2
* Sam
* Samira
* Cheyenne
* Dan
**Stand 14.00 Uhr**


**Lösung (für Abgabe)**
Zielgruppe Restaurant: Moderne Restaurants
Ausgangslage: Jeder Kunde scannt einen QR Code an seinem Tisch. Der QR Code bezieht sich auf den Tisch. Jeder Kunde bestellt sei Essen selber über sein Smartphone. Über das Twint app. Wer kein Twint App hat bekommt ein Tablet. Danach hat man auch die Möglichkeit mit Bargeld oder EC zu zahlen.
Bezahlt kann erst werden, wenn alles aufgeteilt ist.
* Eine Person kann den gesamten Betrag übernehmen und bezahlen.
* Die Personen können den Betrag zu gleichen Teilen bezahlen
* Die Personen können ihre bestellten Positionen bezahlen und Teile von anderen übernehmen (z.B. Die Hälfte des Weines)
* Person ohne Twint kann auf dem Tablet, die Rechnung (Bar, EC, oder Credit) anfordern
* Es kann erst bezahlt werden, wenn alle Beträge restlos aufgeteilt wurden.
**Figma Prototyp**
https://www.figma.com/proto/ZjyWBZyNfEXwaAaZUSCtA7/Twint-Erweiterung?node-id=1%3A2&scaling=scale-down
**Abgabe**
| Column 1 | Column 2 | Column 3 |
| -------- | -------- | -------- |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |
## Gruppe 3
* Stefanos
* Selina
* Flavia
* Joshua
### Stand 14.00Uhr

### Lösung / Abgabe
* Die Rechnung wird über die App eingescannt und danach in eine Tabelle innerhalb der App umgewandelt
* Es gibt nur ein Host der die Aufteilung der Beträge in Absprache mit der Gruppe macht
* Es wird nichts vorausgezahlt, jede Person bekommt eine Einladung, seinen Betrag über Twint selbst zu bezahlen
* Beteiligte Personen werden über die Kontakte, direkt auf Twint hinzugefügt
* Die Person ohne Twint wird per SMS mit dem zu bezahlenden Betrag informiert, und kann dies gleich vor Ort bezahlen
****Figma Prototyp****
https://www.figma.com/proto/qjqX7lK2TZepldOVSNixUN/TWINT?node-id=1%3A411&viewport=-1603%2C-512%2C0.39916491508483887&scaling=min-zoom
****Screens****


# Schöni Festtäg! ;)