Wireframes, App Design

Wir brauchen gute User Experience-Designer*innen. Ich habe dafür hier eine Liste eröffnet, wo wir gute Leute/Firmen, die wir anfragen sollten, eintragen können:

Achja, weil ich das noch gar nicht aus dem github übertragen hatte. Hier die ersten Entwürfe zum Software-Design.

Die Datei mit den Wireframes, wie wir sie vergangenen Mittwoch diskutiert haben, habe ich im Chat gepostet.

@katharina, kannst du hier deinen aktuellen Stand (vielleicht als Screenshots) ergänzen?

Ich hab mal den Usecase „Brot essen“, den wir am Mittwoch besprochen haben, in eine Art Wireframe Storyboard übersetzt. Die blauen Screens sind Person X, Rot ist Person Y, Lila ist Person Z. Ich hoffe das ist soweit verständlich. Vollständig sind die Wireframes noch nicht, es fehlen noch Screens und Inhalte auch auf den abgebildeten Screens, z.B. brauchen wir noch ein Menü auf jeder Seite. Soweit aber erstmal zur Übersicht. (Ich hoffe das geht auch mit reinzoomen, dass man alles lesen kann)

Ist es richtig, dass Person Y zuerst den Bedarf „Brot“ deckt und nicht die Tätigkeit „Brot backen“ ausführt? Ich weiß, die Unterscheidung haben wir neulich schonmal besprochen, aber hier war es mir doch noch nicht ganz klar, sorry…

2 Like

Ja, sehr verständlich, vielen Dank!

Ja, das funktioniert gut.

Interessant. Spontan hätte ich gesagt, die zweite Zeile (erste Zeile von Y) kann weg. Aber …

Tatsächlich ist es ja so, dass Y, wenn sie etwas beitragen möchte, sowohl die Bedarfe als auch die Tätigkeiten durchgucken kann.

Wenn Y die Tätigkeiten durchschaut, wird sie gleich nach X Äußerung dort die Tätigkeit „Brot backen“ finden. Die Software legt dort automatisch die Tätigkeit „Brot backen“ an, wenn (laut Datenbank) in Rostock kein fertiges Brot da ist.

Wenn Y allerdings die Bedarfe durchschaut, wird dort ebenfalls das Brot auftauchen. Y könnte ja auch gerade ein Brot (zuviel) gebacken haben und möchte es gleich weitergeben. Wenn sie allerdings keins da hat, könnte hier vielleicht ein Verweis auf die Tätigkeit (als Alternative) auftauchen?

Oder fügen wir die beiden Listen zusammen? D.h. das Brot als Bedarf und „Brot backen“ als Tätigkeit tauchen in dem gleichen Eintrag auf. Y kann das auswählen und dann entscheiden, ob sie schon ein Brot hat oder ob sie die Tätigkeit ausführen möchte. Macht das mehr Sinn?

Sehr interessant. :slight_smile:

Das habe ich mich auch gefragt. Ich finde in diesem Anwendungsfall wäre es sinnvoll wenn man beide Lsiten zusammen legt, da eine Trennung vielleicht unnötig verwirrend ist. Dann könnte der User/die Userin danach auswählen auf welche weise sie den Bedarf erfüllt. Mann müsste nur mal gucken ob das in allen Fällen so funktioniert. Ich glaube das hängt auch damit zusammen wie man die Bedürfnisse formuliert, die in die App eingetragen werden.

Kannst du das im Beispiel mal anpassen, wie das dann aussähe? Ich kann es mir gut vorstellen.

@Marcus, kannst du das überschauen? Aus meiner Sicht müsste es gehen. Wenn nicht, ist ein Gegenbeispiel hilfreich.

Erstmal danke @katharina für die Wireframes!

Ich finde es gerade wirklich spannend. Im Konfigurationsprozess, in welchem Tätigkeitsmuster zur Selbstzuordnung freigeschalten werden, wird ja wirklich nur mit Mitteln umgegangen, die sicher verfügbar sind - also nicht abgefragt, ob jemand einen Bedarf kaufen/spenden kann etc. Das mit dem Spenden etc. habe ich in der Textreihe wirklich einfach noch gar nicht bedacht und der Auswahlprozess (Anwender:innen ordnen sich irgendwohin zu) läuft bei mir bisher nur mit Tätigkeitsmustern und müsste also entsprechend erweitert werden.

Ich denke, am Ende des Tages muss man das filtern können, oder? Also dieselbe Liste, aber ich kann sagen: „Zeige mir nur Tätigkeiten an“ oder „Zeige mir nur Bedarfe an“

Der Einfachheit wegen würde ich sagen, Y durchsucht die Liste nach Tätigkeiten (also fällt die zweite Zeile weg) und Z durchsucht die Liste nach Bedarfen. Aber richtig ist es auf jeden Fall, wie es in den jetztigen Wireframes ist.

Hier eine aktualisierung: es gibt eine Liste mit allem, was benötigt wird. wenn man dann einen bedarf erfüllen möchte kann man auswählen, ob man es als mittel einfach bereit stellen kann oder ob man es herstellen möchte, also die tätigkeit dazu ausführen möchte, wobei man dann zur konfiguration weitergeleitet wird. was meint ihr?

außerdem bin ich noch nicht sicher an welcher stelle man die detailansicht mit der baumstruktur einbauen kann. habt ihr dazu eine vorstellung?

Mir gefällt das gut, ich denke, für die Videos ist das genau das, was wir brauchen. Für die App-Entwicklung später müssen wir das noch etwas ausfeilen.

An Stellen, wo ein konkreter Bedarf (Brot, Mehl) oder eine konkrete Tätigkeit (Brot backen) bildschirmfüllend zu sehen ist (also quasi in der Detailansicht), könnte es einen Knopf mit einem Symbol geben, welcher dann zu dieser Ansicht führt.

Sehr spannend, liebe Leute. @katharina: Was sind für dich die nächsten Schritte? Ich fänds spannend, wenn wir diese Wireframes-Abläufe im Design sehen könnten. Das brauchen wir fürs Kürzestvideo sowieso, richtig?

Ja genau. Ich versuche möglichst bald in jeder Design Richtung die Webseite, die App und das Video durch zu gestalten (zumindest als erste umsetzungsidee), damit sich jeder was darunter vorstellen kann und wir uns hoffentlich bald auf eine Richtung einigen können.

Toll, ich freue mich mega! :slight_smile: