-
Notifications
You must be signed in to change notification settings - Fork 0
Usability Tests
The test plan addresses the how, when, where, who, why, and what of our usability testing. We've documented our approach to set a consistent framework that will serve us not only in this initial round of testing but in all subsequent rounds. Using the same test plan structure across multiple rounds allows us to:
- Maintain methodological consistency, making results comparable over time
- Onboard new team members or stakeholders more efficiently
- Track how user needs and pain points evolve as the product develops
- Build institutional knowledge about what works (and what doesn't) in our testing approach
The following sections detail the full usability testing program for VeloSim. On this Wiki page you can also find results from past rounds of testing.
- Evaluate whether the current features meet the needs of all users
- particularly BIXI dispatchers (the domain experts) as the primary target group
- Identify gaps between what end users need and what is currently provided
- Discover usability issues and pain points in existing features
- Prioritize future requirements based on user feedback and observed behaviour
- Current System Perception:
- What are users' overall attitudes/satisfaction with the current system?
- Feature Assessment:
- What tasks are users trying to accomplish that the current software doesn't support?
- What features do users expect to find but couldn't?
- Which existing features are intuitive vs. confusing or difficult to use?
- Workflow & Efficiency:
- Where do users get stuck or frustrated in their workflows?
- What would make users more efficient or productive in their work?
- What workarounds, if any, are users creating to compensate for missing functionality?
- How well does the software align with users' mental models of the problem domain?
- Unexpected behaviour in a production system:
- Did end users encounter any issues, bugs, or unexpected behaviour?
These personas trace back to the types of users that we've documented on the Personas Wiki page.
| Participant/Persona Type | Experience Level | Notes |
|---|---|---|
| Dispatcher | Domain experts | Dependent on dispatcher availability |
| Trainee | Simulated by friends and family | Debriefed with a script |
| Scenario Administrator | Simulated by friends and family | Debriefed with a script |
Test Design:
- Type: Moderated usability testing (formative evaluation)
- Estimated duration per session: 30 minutes (actual duration as of round 1 usability testing: 20 - 35 minutes)
- Structure: Think-aloud protocol with task completion
Environment:
- Platform: Production website (https://velosim.app)
- Devices: Desktop and laptop computers
- While VeloSim's interface is responsive and supports mobile and tablet devices, the primary user base accesses the product on desktop and laptop computers. Accordingly, usability testing will focus on these platforms.
Data Collection:
- Screen capture and audio: OBS Studio
- Additional feedback: Post-test form via Google Forms
Moderator Protocol:
- Open the testing script in a browser window
- Open VeloSim production environment (https://velosim.app)
- Create a new non-admin user account for the participant (record credentials)
- For Dispatcher/Trainee personas: Download the test scenario file
- Open the feedback form
- Begin screen recording with OBS Studio
- Hand computer to participant and instruct them to read the introduction and work through tasks
- Observe and note any criticisms or issues during the session
- Ensure participants complete checkpoint questions in the feedback form
- After completion, stop recording, name video file with participant username, and upload to designated Google Drive folder
Context: Participants role-play as student/intern BIXI task dispatchers who must manage battery swap operations. They assign tasks to drivers, prioritize urgent work, and monitor progress in a simulation environment.
Tasks:
- Log into VeloSim using provided credentials
- Import a pre-configured simulation scenario
- Start the simulation
- Zoom in to view station icons
- Speed up the simulation
- Wait for tasks to appear at stations
- Pause the simulation
- Click on stations to check existing tasks
- Assign a task to a driver
- Resume the simulation
- Assign remaining tasks to the other driver
- Reorder the task queue for a driver with multiple tasks
- Explore additional features: unassigning tasks, dragging tasks to drivers
Checkpoints:
- After Tasks 1-2: Rate ease of login and scenario loading
- After Task 12: Rate ease of time navigation, task assignment, and task reordering
- Final: Complete general feedback section
Context: Participants create simulation scenarios by defining stations, drivers, vehicles, and scheduled tasks using the Scenario Editor.
Tasks:
- Log into VeloSim using provided credentials
- Navigate to Scenario Editor and create a new scenario
- Draft a scenario following a detailed specification including:
- Three stations with specific locations, initial tasks, and scheduled tasks
- Two drivers with shift times and lunch breaks
- Two vehicles with starting locations and battery inventory
- Explore additional features: saving scenarios, creating duplicates, exporting to local computer, editing scenario titles, creating new versions vs. overriding existing scenarios
Checkpoints:
- After Task 3: Rate ease and effectiveness of Scenario Editor, suggest improvements, evaluate error message clarity
- Final: Complete general feedback section
- Quantitative data
- Likert-scale questions about ease of use for feature set
- System Usability Scale (SUS) questions
- Task-specific ease ratings (login, scenario loading, time navigation, task assignment, task re-ordering, scenario editor usage, error message clarity)
- Qualitative data
- Observed pain points, confusions, and delights
- Feature requests and suggestions
- Positive feedback and what's working well
- Open-ended feedback on overall system experience and suggested improvements
All quantitative and qualitative feedback will be collected through a standardized post-test Google form.
- GitHub wiki page containing all our Usability Testing information
- Summarizes the background of the study
- including the goals, methodology, and participant characteristics
- Present findings for original questions to investigate
- Give user feedback results and discuss specifics (appropriate to data)
- Suggest follow-up research
- Summarizes the background of the study
- SOEN 490 Release Presentation videos
- Summarize usability testing plan and our results
- Discuss how feedback was incorporated into design and implementation
TODO
Feedback pertaining to the scenario editor:
- Issues due to the use of the JSON format to define the scenarios (clarity, readability, troubleshooting validation issues, too text-heavy) (7 mentions)
- Alternatives proposed include a different format than JSON, form-based (4), a datetime picker for timestamp fields, map-based (world-builder-esque)
- The scenario editor lacks functionality expected in text editors (tab-friendliness, line numbers, syntax coloring, collapsable fields) (2 mention)
- Difficult to understand what to delete and what not to delete in the json editor (1 mention)
- The scenario doesn't save automatically when pressing Start simulation (1 mention)
- Desire for the ability to drag a JSON file over the editor to import / save it (1 mention)
- The use of red for the selected scenario is confusing since red is usually used to indicate something bad (1 mention)
- The placement of the scenario description field before the scenario content field is unatural (1 mention)
Feedback pertaining to the login page:
- Log in page should allow white-space around the username (1 mention)
Feedback pertaining to the usability test:
- Titles in the task tables should match the json titles (1 mention)
- Instructions could be a little simplified (1 mention)
Bugs discovered:
- Clicking on the current scenario after it has been edited shows a "Unsaved Changes" card (1 mention)
TODO
TODO
TODO
TODO
Simulation Meeting Minutes
Frontend Meeting Minutes
Backend Meeting Minutes
Risks
User Consent and End-User License Agreement
Legal and Ethical Issues
Economic
Budget
Personas
Diversity Statement
Overall Architecture and Class Diagrams
Infrastructure and Tools
Name Conventions
Testing Plan and Continuous Integration
Security
Performance
Deployment Plan and Infrastructure
Missing Knowledge and Independent Learning
Glossary
Mockups
UI Evolution
Logging
Metrics
VeloSim Observability & Performance Insights
User Manual
Usability Tests