What method(s) did you use to evaluate the results of your usability tests? How did you evaluate the results?
Wir haben die Verbesserungsvorschläge und Kritik am Prototypen der Testpersonen zusammengefasst und systematisch aufgeschrieben. Die Task Completion Rate weiter auszuwerten war nicht sinnvoll, weil alle Personen alle Tasks abgeschlossen hatten.
What did you learn from the testing?
Es macht einen großen Unterschied, ob man aus der Entwickler-Perspektive auf oder von außen auf den Prototypen schaut. Der Nutzer versteht eventuell Gedanken hinter Funktionen und Funktionsweisen nicht die für uns klar waren. Die Verbesserungsvorschläge von außen waren auch sehr hilfreich.
What are your main takeaways?
Testen ist gleichzeitig schwierig aber auch sehr wichtig. Auch sollte man relativ früh anfangen, damit Veränderungen noch leicht möglich sind. Die Aufgabenstellung für den Test ist relevant um möglichst aussagekräftige Ergebnisse zu produzieren.
(2) Project description
One image (1000×500 px, png), which shows your prototype:
One image (200×200 px, png), which shows some unique part(s) of your project or prototype in a very detailed way (e.g., some logo or part of a screen):
Name of your project + tagline/sub-line:
Social Gaming – no more messy remote board game nights
Project description text:
We are big fans of fun, relaxed board game nights with our friends. However, during the pandemic we experienced that remote version of the board game nights often turned out to be more frustrating than fun: switching between all the different websites, not knowing which games have an online version,…
With Social Gaming, we want to transform remote board game nights into a great time with your friends instead of an exhausting evening. To achieve this goal, Social Gaming consists of three core elements:
You are able to audio-, video chat and message your friends over our platform
You can filter all the online versions of the board games from our many partners exactly according to your needs
You can play the board games embedded on our website.
To conclude: With Social Gaming your whole game experience will take place on one website, and one website only – no more messy remote board game nights!
Gruppe 4 hatte nicht ihr Google Form, also ihr Feedback, im letzten Blogbeitrag verlinkt bzw. ihr Feedback im Blogpost beschrieben. Wir konnten Gruppe 4 leider nicht über Mattermost erreichen, weshalb wir leider nicht ihr Feedback einarbeiten konnten.
(2) Preparation for a summative evaluation
1. Please recall your experience and takeaways from your first testing session (#Assignment 6)
Wir möchten uns stärker an unser Skript als in Assignment 6 halten, da unsere Interviews alle sehr verschieden geworden sind(zumindestens der Sprechteil des Moderators)
2. Prepare all documents (script, consent form, …) you will need during the test session:
a. Für die Verwendung und Auswertung der gesammelten Daten, brauchen Wir eine Eigenständigkeitserklärung. Wir haben eine Online Format als Vorlage genommen.
b. Ein Skript für die Einführung durch den Moderator. Das Meiste konnten wir von unserem alten Skript übernehmen, da es gut funktioniert hatte. Wir müssen aber die Aufgaben erneut formulieren, da die Aufgabe konkret mit einem bestimmten Ziel ausformuliert werden soll.
4.This time, you will also measure the satisfaction of users, by using a post-task or post-test questionnaire.
We plan to take UEQ for measuring the satisfaction of users. Here are our considerations:
(1) We prefer a post-test questionnaire, since the full process from create account task to log out task is a complete user journey on our web application, which cannot be seperately measured. Lack of any single task will make the user journey incomplete and will make the satisfaction evaluation unreliable. The usage of social play is based on a smoothly enjoyable gaming evening, which consists of several tasks to be completed through our web application. But the usage process will be interrupted by task-level satisfaction assessment. And since all task satisfaction level together account for the general usage of social game, we decided to use post-test satisfaction questionnaire.
(2) Between different standardized measurements we prefer SUS, UEQ and AttrakDiff2 in terms of their reliability and widely usage. We first don‘t want to choose questionnaire with too many questions, since we are afraid that those questionnaires will cause implatiency of participants. Compared to SUS, UEQ and AttrakDiff2 measures satisfaction on a more well-round level with different dimenstions. But AttrakDiff2 has a strong focus on hedonistic quality, which is not our main purpose, we therefore choose UEQ for our satisfaction measurement.
The questionnaire can be reached by scanning the QR Code:
We made a google form questionnaire used the standard questionnaire provided by UEQ. The QR code is then self-made using the onling platform QR-Code Monkey.
5. Document preparation.
We document the preparation as by using the assignment questions.
Our prototype is improved with some tiny updates so that the test users can have a more near to reality feel by heuristic evaluation and usability testing. We aim to create an easily usable interface for our potential users with corresponsing changes to user tasks.
(2) heuristic evaluation (Phase 1 and 2)
Phase 1 Prepare
Use case:
You have finished a long day of work and would like to have a game night with your friends. After consultation, you decided to organize a game night together online on Social Play. You already have an account on Social Play and you would like to invite your friends join your group. You have sent a link via Social Play to your friend by email. After your friend has logged in, you have started to play together in a meeting.
Tasks for evaluators:
1.register/log-in on Social Play
2.meet with your friends in your group
3.search a game you want to play
4.enjoy your Gaming Night with your friends with Games together with chat
Online form for evaluation collection:
we use google form to collect our feedbacks. The google form is designed using the template given by the lecturer.
Phase 2 Evaluation
We evaluate the protype of JuurMate under the scenario:
Anwendungsfall:
Du musst als Hausaufgabe einen Rechtsfall prüfen. Aktuell bist du auf dem Weg nach Hause und möchtest schon mal damit beginnen. Also öffnest du die JuurMate Anwendung auf deinem Notebook. Nach dem öffnen erscheint ein Auswahlbildschirm, bei dem du dich entscheiden kannst, ob du die geleitete Variante der Anwendung oder die ungeleitete Variante benutzen möchtest. Mit der geleiteten Variante kannst du nun ganz einfach in der Bahn auf dem Nachhauseweg ein einziges Schema dynamisch generieren lassen, dass dir dabei hilft deine Hausaufgabe zu Hause schneller zu beenden.
Aufgaben:
1.Fertige mithilfe der Anwendung ein Prüfungsschema zum Prüfen einer Rechtsfrage zu Mord an.
2. Öffne ein altes Schema, das im Vorhinein abgespeichert wurde.
3. Suche nach einem Tatbestand.
Documentation and Reflection
The individual evaluation was done separately. Ina and Brendan filled in the online form with their observations, Xin has problem filling in the form, therefore documented on a document with screenshots.
Summary of Evaluation
Based on our evaluations, we found out that (3) user control and freedom and (8) Aesthetic and Minimalist Design are the most violated guidelines. We have found out some critics in common, for example once we entered in a case, there is no „back“ button to go back to previous page. The only choice we could do is to click on the „JuurMate“ and begin with the main page.
We also encountered some problems here, there are some problems we are not so sure to which guideline they belong to. Some heuristics are hard to be evaluated, since we don’t really find any error message in the prototype (we also don’t include them in our prototype). (7) Flexibility and Efficiency of Use is also a hard to be evaluated guideline.
Reflection
Who did what?
Ina improved prototype ready for evaluation. Ina and Brendan prepared the template in google form and described the test case of JuurMate. Xin described the test case of Social Play prototype. The heuristic evaluation regarding JuurMate was done individually. Xin then summarized the evaluation while creating the blogpost.
What have we learned?
We learned how to prepare a prototype for evaluation as well as the heuristic evaluation methods. My only concern was that since our prototyp is really simple at the moment but the evaluation guidelines seem to be well-rounded, is it the good timing to do the heuristic evaluation on such a simple prototype?
What went well?
The individuell evaluation went well (not without problems) even though with difficulties by problem categorization. We were happy that the templated are provided so only minor changes need to be done by us.
What do we want to improve?
The 1st task was some how confused since it is not so clear which preparation is for us and which step is for classmates. The evaluation form is not well established, it is really hard to summarize the severity of each guideline violation and to see the screenshots indicating the problems.
What framework or tools are you going to use? Why?
Für das Gantt-chart haben wir ein normales Excel/Sheets Dokument verwendet, da das kein neues Tool ist mit dem man sich beschäftigen muss ist. Ausserdem hat das den Vorteil, dass die Darstellung recht flexibel ist. Für den Prototypen haben wir bubble.io ausgewählt, da es zum einen eine Zusammenarbeit ermöglicht und da sich bei uns nicht alle mit HTML/CSS auskennen eine einfachere Erstellung von Web Apps ermöglicht.
List your functional and non-functional requirements (features) you are planning to include in your High-Fidelity Prototype
Functional
Gruppe per Link beitreten
Filter View darstellen
Game Info Display
Non functional
Simpel
Klare Menü Führung
We now have 6 weeks left for our projects. Produce a detailed timeline (e.g., a Gantt-chart or similar) of jobs that need to be done and milestones that need to be reached starting from today.
Please answer the following question: How did you handle the topics: menu, UI consoles, and Design patterns?
What menu type did you choose and why?
Es existiert kein wirkliches Menu(daher haben wir auch keins ausgewählt), es gibt allerdings ein button zum Zeigen/Verstecken der Video Ansicht. Die eigentliche Navigation ist im Hauptbild zu finden.
Which UI controls are appropriate for your application and why?
Wir haben vor allem Buttons und Text Input Fields verwendet, da diese eine sehr gradlinige Navigation ermöglichen und klar ist welcher Schritt als nächstes erfolgt. Ausserdem gibt es selten mehr als 3 Möglichkeiten, um den Nutzer nicht zu überfordern. Für die Filter Views haben wir uns für Dropdowns entschieden, da es hier nur begrenzte Möglichkeiten für die Auswahl gibt.
Which design patterns are suitable for your application and which ones have you implemented or used? Why?
Wir haben nicht bewusst Design Patterns verwendet, allerdings kommt unsere filter Ansicht doch einem Design Pattern nahe, was man Table Filter nennen kann. Wir haben die Ansicht so gestaltet, da sie uns intuitiv vorkam und die Parameter übersichtlich darstellt.
(1) Continue to develop (or start a new) paper prototype based on new insights or feedback from your peers.
We skip this subtask since we considered the feed back from peers was planned to gathered during last lab session on 25. May which didn’t happen (question asked and got confirmed in Mattermost).
Wir testen die Webapplikation, nicht dich! Fragen bitte gerne stellen, ich kann aber nicht versprechen, alle Fragen direkt zu beantworten! Bitte laut denken (Think aloud). (übernommen von Lab 07)
(2) Kontext der Anwendung erklären
Wir wollen eine Webapp entwickeln für online Spieleabende mit Freunden. Sie soll die remote Brettspielabende unkomplizierter und übersichtlicher machen. Neben der Kommunikationsformen, wie Audio-, Videochat, soll unsere Webapplikation eine Filterfunktion für Brettspiele haben, sowie die eigentlichen Brettspiele eingebettet haben. Wir haben einen ersten Prototypen gebaut und würden in diesem Test gerne die Verständlichkeit und Übersichtlichkeit testen.
(3) Fragebogen
Wie heißt du?
Wie alt bist du?
Was machst du beruflich?
Spielst du gerne Gesellschaftsspiele in deiner Freizeit?
Hast du schon einmal einen remote Spieleabend gemacht?
Hast du schon einmal einen usability test (als Testperson) gemacht?
(4) Szenario(s)
erste Szenario: per Link einladen
Du hast einen langen Tag der Arbeit beendet und würdest gerne mit deiner Freund_Innen ein Spielabend machen. Nach der Absprechung habt ihr entschieden, gemeinsam online ein Spielabend auf Social Play zu organisieren. Du würdest gerne erstens ein Account auf Social Play einlegen und deine Freund_Innen per link einladen. Du hast über Social Play einen Link per email an deindem/r Freund_In geschickt. Nachdem deindem/r Freund_In sich eingeloggt ist, habt ihr eingefangen in einem Treffen zusammen Spiel auszuwählen.
zweites Szenario: Spiel aussuchen und filtern
Du triffst dich mit deiner Freund_Innen zusammen im online meeting Raum von Social Play. Ihr habt gestartet ein Spiel auszusuchen. Jenach euer gewünschte Filterkriterien (z.B. Spielzeitlänge, Spielart, geeignete Personenanzahl usw., die sollte Testperson selbst gegeben werden, um zu gucken, ob wir einige Kriterien vergessen haben) sollte eine Liste von Spiele ausgegeben werden. Dann du und deine Freund_Innen gucken solche Spiele durch und sucht ihr ein Spiel aus. Anschließend spielt ihr das Spiel zusammen.
(5) Aufgaben
Mache dich mit der Anwendung vertraut
Beschreibe was du siehst und deinen ersten Eindruck.
Was wären deine ersten Schritte, um in eine Gruppe mit deinen Freund_innen zu gelangen ?
Finde die Gruppe No board games, no gain.
Lerne die Gruppenmöglichkeiten kennen
Wie würdest du einer Gruppe per Link beitreten?
Wie würdest du eine Gruppe erstellen?
Erstelle ein Gruppe, bei welcher du deine Freund_innen hinzufügst.
Lerne die Filterfunktion kennen
Wie würdest du ein Spiel finden?
Wie würdest du das passende Spiel für euch auswählen?
Finde ein passendes Spiel für deine Gruppe und wähle es aus.
Lerne die Spielfunktion kennen
Was würdest du machen, um mit deiner Gruppe zu spielen?
Wie würdest du ein Spiel starten?
Spiele ein Spiel durch mit deiner Gruppe
(6) Abschließende Fragen
Welche Vor- und Nachteile siehst du bei der Benutzung der WebApp?
Was fehlt dir an der Social Gaming App?
Hast du Schwierigkeiten (Wo hast du Schwierigkeiten) bei Nutzung des Apps? (z.B. eine bestimmte icon oder Funktion zu finden, verwirrende icon design oder Layout design usw.)
(7) Abschluss
Hast du weitere Fragen oder Anmerkungen?
Vielen Dank für deine Teilnahme! Du hast uns sehr geholfen.
(übernommen von LU 7)
2.Document who is taking what role
In the first and second usability tests Ina will be the Facilitator and in the third Brendan. Xin will be the Observer in all usability tests.
3.Decide if you want to record your test session and how you take notes during the test sessions.
We don’t want to record the test sessions as our users expressed uncomfort with the idea of being recorded. We will take notes on paper during the usability test, as we find it the easiest way to create “creative” and adaptable notes. We will later summarise these notes in a more structured way in a Google Doc.
4.Document who you are inviting for a test session and how long the session lasted.
Table created in word document. We hide test perons‘ name for privacy reason.
(3) Document and evaluate the results of your testing.
Results Evaluation
We first wrote down notes on paper block and then tranformed them into structured notes in word documents (each document for one single test person). The document is structured as the usability test workflow. We take Affinity Diagram to evaluate our results of usability testing since we consider it as the best way to fulfill our „gather and then organize“ evaluation steps.
Since we most concentrate on the improvement suggestions and critics from our test persons, we organize only the „negative“ feedback from our test persons and didn’t write down „positive feedback“ in our affinity diagram (of course positive feedbacks are noted in our structured documents).
The affinity diagram is generated using online tool Flinga.
It is the first version of our affinity diagram which consists of all unorganized ideas from our test persons. We then organized them into two sub categories: general suggestion (left) which doesn’t correspond to a single function/page and feature/design suggestions (right) which correlate to a single function or page design.As the last step, we again subcategorized the Feature/Design suggestions(right) into four subgroups: social functions (left), interaction features (middle up), design defects (middle down), and gaming functions(right). Social functions are functions are regarding accout and group creations, where as gaming functions are regarding all functions correlated to games (including filter, in-play scree etc.). Design defects is a subcategory which should not happen but we still have it based on our carelessness in first design.
Learning and Takeaways
We learned that all test persons liked our design idea behind our application. And they think our first design is not overwhelmed with non-necessary information, wo that the it is easy to follow the test process. However, some confusions can also be found in testing. Part of the confusions are based on the Marvelapp and partly is based on our design defects. There are also some functions we didn’t think of but proved to be important by testings. We think there are really lots of improvements to be done in further design iterations.
Part II Reflexion
(1) Team member contribution.
We first meet together in Discord and discussed the organisatorial stuff of how to organize the usability tests. Then we worked together on our script for further steps (Ina for contextual introduction and questionaire, Brendan for following-up questions, Xin for scenarios. However the separation is not 100% clear since we review and improved each other’s parts though).
The three usability tests are taken part separately over the weekends (responsible persons can be found in the table for task (2)). Notes are generated after the test and uploaded into our shared google folder.
We created the Affinity Diagram after gathering all three notes and evaluate the results.
(2) Learnings from assignment.
We learned how to formly conducted a usability test. It was an interesting experience because somehow the test person can get confused by some designs which we didn’t notice it at all. We are pleased to get constructive feedbacks from our test persons. We will take their feedback into serious considerations and think about how to improve our design.
(3) possitive/successful experience
We successfully found 3 different test persons to help us with the usability testings, which we really appreciate their kindness and helpfulness. All our test persons are so cooperative which make our test processes much more smoothly.
(4) What would you like to improve?
It seems that the assignment workload is not so evenly distributed throughout weeks, for example three usability tests over a weekend is somehow a little bit more. It is also not so easy to find and contact test persons, and then finish usability testings so shortly within a week (for example, some people may be really suitable for usability testing but due to their tough schedule they need to be contacted at least one week before for appointments). That would be so nice if we can see some assignments in advance and maybe prepare it in advance.
Another improvement lies in our previous assignments. In our assignment #2 we didn’t chose „Analyze existing software“ for data gathering. Based on our usability testing results, we found it essential to do that since some of our design defects can be easily resolved by viewing similar apps or apps offer similar functions. If we view similar app designs, we at least won’t forget registration function on the main page.
Additionally, we didn’t undertake probe testing on ourselves before formal usability testing. If we did so, some problems can also be detected earlier.
besides the filter option, there should be also an option to browse manually through the board games, a little bit like the discovery page of Netflix;
there should be an option to show or hide the video chat and messenger;
there should be a way to listen to the sound of the board game but also to be able to audio chat with friends ;
don’t show the percentage of the match (board game matches …% the filters) but just show the board games with the highest rank first;
describe the games in one sentence already on the result page;
good idea to include webcam games for movement games.
We found all of the feedback helpful and good ideas (thanks for the feedback from fellow students). Some points we thought of already but didn’t feature it in our storyboard as it was more of a detail. For our first simple prototype we will also focus on the “less tricky”/low-fidelity feedback (point 4, 5) and include the other feedback in later, more high-fidelity prototypes .
We first decided on which tool we want to use for our prototype. We liked the example from the lab session, so we decided on using Marvel. We first played around on the website a bit. Then we talked about what we want our prototype to have: We talked about the general ideas that we decided on the last couple of weeks and about how we could add the given feedback by the others from the last lab session. We decided on which sites we want our prototype to have. We found it really helpful to look at our storyboard for this. We then created one site after the other together. While we created the prototype we realized that even though it is a low-fidelity prototype, we wanted to add some very simple design features: We decided on making important buttons green and adding some emojis to the texts to make them more “alive”. These little design additions helped us to make the prototype feel more like our idea for our “end design”. In the end, we played the prototype and looked at whether everything worked well.
(ii) the use case and/or model (task analysis from last assignment) this prototype relates to.
The prototype very much relates to our task flow from last assignment. The task flow was our basis for our storyboard and this was the basis for our prototype – so the task flow is very much reflected by our prototype. Our use cases are also generally speaking reflected by our prototype. The low-fidelity prototype doesn’t 100% relate to the use cases that it doesn’t feature as much details as our use cases (e.g. our prototype has name and a passwort as information about the user, while the use case for the user account also features favourite game of the person, profile picture,… – these details will be featured in later prototypes).
(iii) how the storyboard is reflected in the prototype
As mentioned above, the storyboard was the foundation of our prototype. It is therefore very much reflected by our prototype. We wanted the prototype to create the same atmosphere as our storyboard and constantly reflected on how “Max”, our persona, would like the prototype.
(iv) self-assessment of potential strengths and weaknesses of this first step into your design space
Generally speaking, we are happy with the prototype and think that it is a step in the right direction. The site layouts are overall what we had in mind. We find a potential strength of the prototype that it is very clean and has only the absolutely necessary functions. This makes it easy to understand and the users can directly focus on playing board games rather than trying to understand the website.
A potential weakness is that the prototype idea works so well because it is not designed for answering details. So naturally, some details still haven’t been answered by it. For example: How exactly will the explanatory videos about the board games look like? What exactly will be our features? How exactly will the chat function look like? This could be a weakness moving forward since the devil is always in the details. We are curious to see whether this causes our future prototypes to later change drastically or not.
*The prototype is generated on 21. Mai 2021 through group collaboration using online collaboration tool Marvel.
(3) Design rationales
For capturing design rationales analysis, we choose process-oriented gIBIS. We consider gIBIS with its avantages of its clear presentation of inter-relationship and inter-dependencies of questions and subquestions, as well as a clear comparision between pros and cons for each position. It consists better with our design thinking process.
We did the assignment as usual in a regular team meeting on Friday, 21. Mai 2021. Ina first reviewed the feedback and summarized it for other team members. We then considered and discussed how to incorprate the feedback into our prototype design.
For the second task, we first discussed how we would like to corporate and which tool we want to use for collaboration. We then discussed a general idea of prototype representation such as what layouts we want to design, for what use cases we want to design, and what interactions/functions need to be included in the low fidelity prototype. Then we separate the tasks to each team member, e.g. Ina is responsible for user/user accounted related pages, such as log-in, account registration etc, she is also responsible for homepage/welcome page; whereas Brendan is responsible for filter function related pages. Xin is responsible for the in-play and after-play pages. We also viewed each other’s pages and helped each other in process.
After viewing and agreeing on all the page designs, Brendan linked them together. Ina then finalized the final version with interaction and refinements.
The design retionales analysis is done by using gIBIS based on group consensus. Brendan and Xin are respectively responsible for a design question.
(2) Learnings from assignment.
We learned how to implement the theoretical knowledge into actual design processes by doing the assignments. We also learned by feedback that it is important to escape the „group think trap“ by design. Even though we analysed the user context in advance, it seems that we somehow still get caught up in „developer mind“. More important is „what users need“, but not „what developers want to offer“.
(3) possitive/successful experience
We appreciate our team work as always. Additionally, thanks to the advice for open design tools which helped us a lot in the beginning. Based on personal experience, an inadequate choice of design tools may trigger problems in later design process and waste time. But we found all the suggested tools went well with our tasks, in terms of both user friendliness as well as accessibility.
(4) Expected improvements
We are currently satisfied with the team work and team progress. But for further design phase, as mentioned in (2), we need to keep users in mind throughout the design process.
Max needs a way to easily choose board games online with his friends because they changed their board game nights to remote board game nights because of the pandemic and are not very accustomed to the online board games. We will know this to be true when we see: The group can choose a board game according to their interests in a short amount of time.
HYPOTHESIS STATEMENT
We believe that by creating a web application that includes a filter and recommendation system for online board games forMax, we will achieve that Max and his friends will have less stress and frustration during their remote board game nights.
2. Task flow with BPMN
Our task flow with BPMN starting from when user has logged in until he/she logs out. The task flow was created with BPMN.io
Why did we decide to do a task flow with BPMN?
We chose BPMN because the task flow gives us a good overview over the activity order of a user in our web application. Moreover, we chose BPMN because we find it very clear and easy to understand without any unnecessary details. It therefore helps us to focus on the essential aspects of our idea for further steps in our project.
3. Moodboard
Our moodboard. We worked a lot with pictures that we think create certain atmospheres that we also want to have for our application later. We created the moodboard with jamboard.google.com.
4.-5. Sketches
An individual sketch of how the filter system for the board games might look like.Another individual sketch of how the filter system might look like.
We decided to keep the sidebar with the video chat from the first sketch and the prediction of how closely the shown game matches the filters from the second sketch.A sketch of how an embedded board game might look like.Another sketch of how an embedded board game might look like.And another sketch of how an embedded board game might look like.
We decided to keep the sidebar with the video chat from the second sketch for the embedded board games as it seemed to us the most useful for different types of games.
6. Storyboard
The first page of our storyboard.The second page of our storyboard.
Reflexion
Wer hat welchen Beitrag geleistet?
Wir haben in Gruppenarbeit die Aufgaben bearbeitet, also haben wir alle zusammen bearbeitet. Da wir für alles shared documents verwendet haben, konnten wir so gut gemeinsam Texte schreiben und das Moodboard, den Task flow erstellen. So haben wir sichergestellt, dass wirklich immer alle ihre Ideen mit einfließen lassen konnten. Für die individuellen Aufgaben haben wir uns jeweils einen Tag Zeit gelassen und uns dann erneut getroffen, um die Ergebnisse zu besprechen. Wir hatten uns entschlossen, dass Ina das Storyboard zeichnet, da wir das Layout am vielsagensten fanden. Wir haben davor besprochen, wie das Storyboard aussehen soll und sie hat nach der Fertigstellung es nochmal mit uns besprochen, sodass wir noch kleinere Änderungen zusammen umsetzen konnten.
Was habt ihr gelernt?
Wir haben unser Wissen über die Darstellung von Task Flows mit BPMN vertieft. Außerdem haben wir gelernt, unsere Idee auf die wesentlichen Aspekte runterzubrechen, damit sowohl der Task Flow als auch das Storyboard auf eine klare (und im Fall des Storyboards sehr bildliche) Weise die Funktionen unseres Projekts darstellt.
Was lief gut?
Da wird diesmal erst individuelle Ansätze erarbeiten mussten für das Moodboard und die Sketches, mussten wir diese schließlich auch gegenseitig beurteilen um auf gemeinsame Nenner zu kommen. Das lief sehr gut, da wir alle sehr konstruktive Kritik gegeben haben, die unsere Idee weitergebracht hat.
Was möchtet ihr verbessern?
Wir haben erst bei dem gemeinsamen Treffen uns die Aufgaben durchgelesen und gesehen, dass individuelle Arbeit nötig ist. Deshalb fänden wir es hilfreich, wenn wir die Aufgabe schon vorher durchlesen würden in Zukunft, um mögliche individuelle Arbeit schon vorher zu erledigen und sie so direkt besprechen zu können.
The picture shows you the initial unsorted result of data collection from the user interview.
1st Iteration
After the first iteration the clusters of ideas are created. The ideas with related content are grouped together.
2nd Iteration
Headlines are created for each group, which describes what the user ideas are about.
3rd Iteration
Superheadlines are created for inter-related subgroups, which reflect the idea categories.
4th Iteration
We settled the Priority for each category, to show which user needs/expectations are our primary tasks.
All diagrams are created using Google Jamboard as a collaboration tool.
2. Primary Persona
The Persona is created using a free version of online tool xtensio with provided template. The photo of Max is downloaded from Unsplash, where provides freely-usable images. Accessed at 14:05, 4.May 2021.
3. Create a Scenario
Color code: what & where
Freitag Abend möchte Max sich, wie vor Coronazeiten auch, mit seinen Freund_innen treffen, um einen entspannten Abend zusammen zu haben. Dafür setzt er sich in seinem Zimmer vor seinen Computer und loggt sich auf der Spielewebseite ein. Er klickt auf die Gruppe, die er zusammen mit seinen Freund_innen hat. Aimee hat keinen eigenen Account auf der Spielewebseite, weshalb ihr Max eine Link zuschickt, mit welchem sie auf die Gruppe zugreifen kann. Hier startet er den Videochat mit ihnen.
Nachdem sie für ein Viertelstündchen ein bischen gequatscht haben, wollen sie anfange zu spielen. Was genau, wissen sie noch nicht. Max würde aber gerne mit einem recht kurzen Spiel einsteigen, eine andere Person aus der Gruppe möchte ein Brettspiel spielen, eine weitere ein Logikspiel spielen. Sie geben ihre Kriterien in dem Vorschlag-system der Webseite ein, indem sie entsprechende Filter auswählen. Es wird ihnen eine Liste von Spielevorschlägen angezeigt. Nachdem sie sich die Kurzbeschreibung der ersten fünf Spiele angesehen haben, entscheiden sie sich für das 3. Sie klicken es an und beginnen direkt das eingebettete Spiel auf der Webseite. Sie kommunizieren weiterhin per Audio und Video. Joachims Mikrofon ist leider kaputt, deshalb kommuniziert er per Chat und Video. Nachdem sie das Spiel fertig gespielt haben, spielen sie nach dem gleichen Prinzip noch viele weitere Spiele an dem Abend, sodass Max und seine Freund_innen einen lustigen remote Spieleabend zusammen haben.
4. Two Use Cases with UML
First use cases describes the user interaction with our application for a normal social gaming night.The second use case describes the user-application interactions for a typical registration process.
Both use cases are generated using online free tool diagrams.net.
Reflexion
Who made what contribution?
We generally did everything together in the group with twice meetings in the week. Ina prepared the documentation from her interview with friend and shared on Tuesday in the group meeting. The bulletpoints noted by Ina then are gathered unsorted in the diagram. All group members are participated in the initial gathering of ideas and further iterations. The final version with priority points as well as superheadlines is refined by Ina and Brendan.
The Persona is also created during group meeting. The main part is finished based on group discussion based on previous data analysis using affinity diagramming. Small refinements afterwards and looking for photo are done by Ina and Xin.
In our second meeting on Friday, the use cases are finished within group discussion. Ina mainly focuses on the registration process whereas Brendan and Xin focus on the social gaming process. The blogpost is then written by Xin with support from Ina and Brendan.
Learning & Take-Aways
The Interpretation of qualitative data can somehow be ambiguous since even though in our group, people have different perceptions of the qualitative data. Therefore, a sufficient and efficient communication as well as opinions exchange is really import. Otherwise, the gathered user data cannot be precisely or even correctly represented by us als developers.
With persona we learned how to depict a „typical“ user image for our product. By using the online template provided by Xtensio, we see some sections which are less relative to our project (or: we currently cannot really see /uderstand the necessity for our project) auch as personalities. We somehow also have the feeling that some descriptions are inituitiv and subjective, since an „absolut covergence“ from user data is alway hard to find.
What went well?
Everything went well. We see our weekly progress as positiv.
Improvement and Concern
We got some really use ideas from our potential users, but some the cutomer wishes are hard to implement. For this case, we are unsure whether we need to considerate the person as secondary potential user, or should we take the suggestion as important feature which we ignored to garantee. Maybe some functions proposed by users require advanced technologies which we are not sure whether it is able to implement in our application. Some user wishes seem to be hard to realize based on our product format (web application).
Another confusion is that we are not sure whether our data gathering method will trigger bias, since either interviewee or survey participants are in our „connected cycle“.
Zuerst wollen wir erfahren, was die größten Probleme sind, die aktuell bei Online Brettspielabenden bestehen, um danach anhand dieser Funktionen Prioritäten vergeben zu können. Weiterhin wollen wir erfahren wie und in welchem Umfang die Nutzer vor Corona und jetzt Brettspielabende gestalten um unsere Nutzer besser kennenzulernen und besser einzuschätzen wie sie die Anwendung nutzen würden. Auch wollen wir erfahren wie die Nutzer sich den „perfekten“ Brettspielabend vorstellen.
Based on your goal, derive the kind of people you want to gather data from
Unsere Teilnehmer für die Umfrage sind Personen die gerne Brettspiele spielen und eher jünger (wahrscheinlich eher Studenten). Für das Interview befragen wir 2 Freunde.
Decide on your data gathering method
Which methods are you using and why?
Zusätzlich zu den Interviews werden wir auch noch eine Umfrage durchführen, da die Daten die sich hier sammeln lassen deutlich besser vergleichbar sind und sich schneller/einfacher auswerten lassen sind dafür allerdings nicht so detailliert. Die Interviews dagegen sollen uns sehr detaillierte Antworten bringen, was für Probleme und Wünsche es gibt.
What type of interview (structured, unstructured, semi-structured)?
Wir planen ein semi-strukturiertes Interview durchzuführen. Wir werden ein Größtenteils wird es ein strukturiertes Interview sein, allerdings wenn es um Problembeschreibung oder Wünsche geht werden wir die Fragen offen stellen.
What kind of data do you want to gather?
Das Interview ist vor allem daraus ausgelegt qualitative Daten zusammen, die Umfrage dagegen soll hauptsächlich quantitative Daten sammeln.
Decide how you handle the topics pilot study & data recording.
Pilot Study
Wir haben die Pilot Study aufgrund der kurzen Zeit ausschließlich für die Umfrage durchgeführt um dafür zu sorgen, dass die Fragen verständlich für den Teilnehmer der Umfrage sind. Hierfür haben wir uns ein paar Personen aus unserem Bekanntenkreis Gesicht, die sich dass angeschaut haben.
Data Recording
Interviews: schriftliche Notizen – Die sind einfacher Auszuwerten und meistens akzeptierter bei Interviewpartner als Aufnahmen
Umfragen: Tabellen und Diagramme, die automatisch vom Umfrage Tool erzeugt werden.
Who is your user group? People who are in need of social gathering during the pandemic time and want to have board games night online. Other stakeholders might be board game companies that want to create an online version of their board game (or already have one) and want it to be known by a broad audience.
What is the exact problem? It is difficult to have an overview over the online board games and thus to choose a game
Where is your user group interacting with your software? At home with access to internet and a browser
When is the user group interacting with your software? At any time in their free time, the interacting with software depends on the common online time of someone’s friend circle
Why do your users need this software?
Pandemic time reduce the chance of meeting people physically
psychological and mental need (lonely, lack so social contact, need to relax etc)
time-consuming to search an online version of a social board game on google, currently there is no web app which helps people to communicate visually as well as play game together in the same application
How do you want to solve the problem? We want to solve this problem by creating a web application:
helps people virtually interacting with each other
provides an overview of different kinds of social games, helps with selection
includes embedded version of the online board game in our web application so the users won’t have to switch between different websites for different games all the time
Reflection
Our team worked together on this blog post (with video chatting), we learned how to initialize a project idea with basic consideration for stakeholders, problem solving format, etc. The initial formulation of the project idea was quite smooth, the only point we need to consider is how we specify our use groups and if we have access to them for further process.
