Sprint 2 - S3-Group36-Mobile-App-Development/Wiki GitHub Wiki
Usability Testing – Consolidated Findings
AI Usage Statement
The course guidelines establish that Generative AI may be used for brainstorming, outlining, and generating ideas, but AI-generated content should generally not be included directly in final deliverables.
For this activity, the professor explicitly authorized the use of Generative AI to support the consolidation and analysis of the usability interviews and surveys. AI was therefore used to organize, synthesize, and structure the information collected by the team. The original evidence comes from the interviews, surveys, prototype evaluation, and previous project artifacts.
1. Objective
The purpose of this usability evaluation was to validate the Zenmed prototype with potential users, focusing on:
- Visual perception: colors, illustrations and typography.
- Usability and navigation.
- Relevance of the proposed functionalities.
- Opportunities for improvement before implementation.
The evaluation is related to the Sprint 1 value proposition: supporting university students in managing stress and anxiety through accessible self-care tools, useful information, emotional tracking and access to a support network.
2. Method
The evaluation included:
- 2 semi-structured usability interviews.
- 6 survey responses.
Because some interview participants may also have completed the survey, the results are reported as two interviews and six survey responses rather than assuming eight independent participants.
The interviews evaluated the prototype while participants commented on colors, typography, navigation and functionalities. The survey complemented these observations with quantitative and open-ended responses.
This follows the usability-testing process discussed in class, where user perceptions and observations are analyzed to identify improvements.
3. Participant Context
Survey participants came from different academic areas:
| Faculty | Responses |
|---|---|
| Engineering | 2 |
| Business / Administration | 2 |
| Medicine | 1 |
| Economics | 1 |
| Total | 6 |
Five participants were between semesters 1 and 3, while one was above semester 7.
Five out of six participants reported personally experiencing or knowing someone close to them who experiences anxiety or other psychological difficulties.
The average reported anxiety level during the semester was 4.0/10.
4. Main Results
| Indicator | Result |
|---|---|
| Average comfort with the color palette | 4.4 / 5 |
| Considered all functionalities relevant | 5 / 6 |
| Considered some functionalities relevant | 1 / 6 |
| Would use the application | 5 / 6 |
| Maybe would use it | 1 / 6 |
Participants generally described the interface as simple, intuitive, well distributed and visually appropriate.
5. Main Findings
Visual identity
The colors and illustrations successfully communicate calmness and friendliness. Participants particularly associated green tones with tranquility, while the illustrations were considered attractive and appropriate for a mental-health application.
The current visual direction should therefore be preserved.
Color hierarchy
Participants considered stronger colors such as red appropriate for emergency actions, especially the panic button, but less appropriate for elements such as messages or flashcards.
Colors should therefore communicate both emotion and priority:
- Calm colors → general well-being.
- Accent colors → important actions.
- Alert colors → emergency functionality.
Typography
Typography was the clearest usability issue.
Participants considered the current font visually appropriate but indicated that the text sometimes required additional effort to read and could be slightly larger.
The next iteration should preserve the general typography while increasing body-text size and strengthening the hierarchy between titles, descriptions and actions.
Navigation
Navigation was perceived as intuitive and simple. One participant specifically highlighted that the six main elements were clearly distributed and that the application did not feel complex.
This supports maintaining the current navigation structure.
Support network and panic button
The support network and panic functionality were among the most positively perceived features.
Participants quickly understood their purpose and valued having direct access to trusted or emergency contacts.
These functionalities should remain central elements of Zenmed.
Emergency interactions
One important observation was that users experiencing intense stress may not want or be able to read long messages.
Therefore:
- Normal situations can include flashcards, educational information and explanations.
- Emergency situations should prioritize short instructions, large actions, guided breathing and immediate access to contacts.
Daily Check
The Daily Check was considered useful for following emotional progress.
Participants also suggested:
- Optional sharing of emotional progress with trusted contacts.
- Reminders asking users how they feel.
Any sharing of emotional information should remain optional and controlled by the user.
Visual contrast
One participant identified insufficient contrast in one of the illustrations, particularly a white fox against its background.
This can be solved by adjusting the background, outline, shadow or illustration colors without changing the overall visual identity.
6. Consolidated Design Decisions
| Priority | Decision |
|---|---|
| High | Increase text size and improve typographic hierarchy |
| High | Reserve alert colors mainly for emergency actions |
| High | Simplify interaction during high-stress situations |
| High | Preserve support-network and panic functionalities |
| Medium | Improve contrast between primary and secondary actions |
| Medium | Correct contrast problems in specific illustrations |
| Medium | Preserve the current navigation structure |
| Medium | Explore optional Daily Check sharing |
| Medium | Explore Daily Check reminders |
| Low | Continue refining motivational messages |
7. Relationship with Previous Work
The findings reinforce the main concepts established during Sprint 1:
- Guided breathing: useful as an immediate calming mechanism.
- Support network: provides quick access to trusted people.
- Panic functionality: clearly communicates emergency use.
- Daily Check: supports emotional self-monitoring.
- Information cards: useful for prevention and learning, but secondary during emergencies.
The results also provide evidence for the UI/UX decisions required in MS6 and MS7 regarding colors, typography, icons, illustrations, prototype views and navigation.
8. Limitations
This was an exploratory usability evaluation.
The survey included only six responses, most participants were in early semesters, and the sample should not be considered representative of the entire university population.
Interview and survey participants may overlap.
Additionally, some prototype interactions were not fully functional. Therefore, the evaluation primarily measures perceived usability, visual design and functional relevance, rather than task completion time, error rates or interaction performance.
A future evaluation with the implemented application should measure these aspects.
9. Conclusion
The usability evaluation supports continuing with Zenmed's current design direction.
Participants generally perceived the application as calm, friendly, simple and intuitive, and most considered the proposed functionalities relevant and indicated that they would use the application.
The main improvements identified are:
- Increase typography readability.
- Improve contrast and visual hierarchy.
- Reduce cognitive load during emergency interactions.
- Preserve the support network, panic button, Daily Check and guided breathing as key functionalities.
Sprint 2 - Deliverable
1. Implemented business questions
| Business Question | Asignee and subgroup | Type and rational |
|---|---|---|
| How can I log in authenticate my self in the app? | Marlon Londoño (Flutter) and Alejandro Celis (Kotlin) | Type 2: because it is answered with the very first interaction of the user, necessary to use all its features, that is is the log in view. |
| How can I practice breathing exercises so I can be calm and relax? | Laura Barrero (Flutter) and Estefania Quijano (Kotlin) | Type2: because it is answered through a daily functionality that is contained in the guided breathing view in the app. |
| How can I get advice based on the way im feeling? | Germán Jiménez(Flutter) and Leonardo Rueda (Kotlin) | Type 2: because it is answered through the interaction of the user with the app, specifically with the check-in page. |
| What screen has the highest crash rate in the app's navigation flow? | Alejandro Celis (Kotlin) and Leonardo Rueda (Kotlin) | Type 1: answered with telemetry: screen views sent to the backend and crashes reported by Firebase Crashlytics, tagged by screen. |
| How frequently is the guided breathing feature used? | Alejandro Celis (Kotlin) and Leonardo Rueda (Kotlin) | Type 3: answered in the Looker Studio dashboard from the breathing sessions stored in the backend. |
| Does the user truly complete the daily check-in every single day? | Alejandro Celis (Kotlin) and Leonardo Rueda (Kotlin) | Type 3: answered in the dashboard with the % of days with a check-in and the current/longest streak. |
| During which weeks of the semester is usage most frequent, grouped by the student's major? | Alejandro Celis (Kotlin) and Leonardo Rueda (Kotlin) | Type 4: answered in the dashboard (week × major), only with consenting users and groups of 5+. |
Note: These questions were not explicit in the deliverable of the sprint 1, but are questions that were contemplated since the beggining of the ideate stage for the features that we wanted the app to have which were, as well, included in the prototype constructed.
2. Analytics pipeline diagram
3. Architectural design
Deployment diagram
This diagram shows how the ZenMind mobile apps connect to the backend.
Both apps communicate with the REST API using HTTPS and JSON. The backend runs in a Docker container and uses Prisma to connect to a PostgreSQL database. The apps can also save some information locally on the device.
Rationale. We used this structure to keep the mobile apps, backend, and database separated. This makes the system easier to organize, maintain, and use from both mobile implementations.
Class diagram
This diagram shows the classes that are going to be implemented. With these classes the app will have all the entities it needs to implement the features decided, its important to notice that the diagram shown is for the complete app, in this sprint the app in no finished so it only uses part of the classes exposed on this diagram
This diagram is what we implemented on this spring.
Rationale: In the class diagram, User composes Check-in, Panic, SupportContact, and Activity log. We decided this because deleting the account wipes everything tied to that person instead of leaving orphaned data floating around.
Components diagram
This diagram shows how the system is organized. Two mobile apps (Kotlin and Flutter) use the same MVVM structure and send requests over HTTPS to a NestJS backend. The backend splits the work into modules (users, well-being, panic and support, activity, analytics) that store data in PostgreSQL through Prisma. Analytics views summarize that data. Data from users who did not give consent stays on the phone, and calls to contacts or emergency lines use the phone's call service directly. MVVM keeps screens separate from logic, so each part is easier to test. Backend modules let each member work on their own part. Direct calls work even without internet, which matters in a crisis.
4. List of implemented features
Flutter Team
| Feature | Author |
|---|---|
| Log in as an existing user | Marlon Londoño |
| Log in as guest user | Marlon Londoño |
| Log in with google account and athentication | Marlon Londoño |
| Movement detection for enabling or disabling breathing exercises | Laura Barrero |
| Guided breathing excercises | Laura Barrero |
| Check-in questionary | German Jimenez |
| Pop-up of recommendation for mood selected in the Check-in | German Jimenez |
Kotlin Team
| Feature | Author |
|---|---|
| Log in as an existing user | Alejando Celis |
| Log in as guest user | Alejando Celis |
| Log in with google account and athentication | Alejando Celis |
| Movement detection for enabling or disabling breathing exercises | Estefania Quijano |
| Guided breathing excercises | Estefania Quijano |
| Check-in questionary | Leonardo Rueda |
| Mood-based flashcard recommendation | Leonardo Rueda |
| Screen-view telemetry to the backend | Leonardo Rueda |
| Crash reporting with Firebase Crashlytics | Leonardo Rueda |
| Analytics dashboard in Looker Studio | Alejandro Celis |
Ethics Video
Dashboard
Crashlytics
