Sprint 2 user feedback
Why we collected feedback
The first version of RODENT exposed a lot of functionality, but having the features did not automatically make the platform understandable. We asked people with different levels of technical confidence to explore the project and explain where they became confused, what became clearer after the interface changes and whether the APIs and extra features supported the research-platform goal.
These are team summaries of the feedback, not verbatim interview transcripts. The feedback was collected during Sprint 2. Exact session dates and links to any private notes should be added to the team's evidence record if they are available.
Participants and findings
Adilah Abed
Adilah was initially confused about where features were located, why particular controls existed and how the pieces supported the main goal. Exploring the original interface by herself produced only a small improvement in understanding. She specifically asked for the platform to be more readable, understandable and clear about what each part was for. After the UI was reorganised and the purpose of each stage was made clearer, she showed substantially better understanding of both the workflow and the team's goals.
This feedback supported clearer labels, task-based grouping and a more obvious sequence from project creation to setup, run and review. It also showed that discoverability could not rely only on a user clicking around until the interface made sense.
Devon Jarvis
Devon had a similar first reaction, although he found the original base formatting easier to understand than some of the other participants did. After the improvements, he felt that the project was on track for the outcome he expected as the client. He also found the updated interface and the internal and external API work useful.
His feedback was especially important because it checked whether the redesign still matched the client's actual direction. It supported keeping the platform centred on researchers, editable templates, external data and model integration rather than presenting the demonstration agent as the final product.
Muhammed Akhalwaya
Muhammed understood the project's goal and recognised that the early interface was still a first-sprint foundation. He suggested opening the experiment workspace in a separate browser tab so the researcher could give the simulator and its controls more room without losing the projects page. He nevertheless saw a clear improvement after the UI changes. He also found the APIs and additional experiment features useful.
This suggested that the underlying idea was understandable, but that the improved interface made the value of the implemented features more visible. His separate-tab suggestion was brought into the project flow so opening a workspace does not have to replace the project-selection context. It reinforced the decision to keep the richer functionality while presenting it in fewer, clearer stages.
Irfaan Fulat
Irfaan was less technologically confident than the other participants, but followed a learning curve similar to Muhammed Akhalwaya. He gave specific feedback on how he would group and lay out the buttons so that the most important action was easier to find. Once the workflow and purpose were explained and the controls were reorganised, he was able to follow the platform more comfortably.
His feedback highlighted the need for plain language, visible next actions, logical button grouping and less dependence on technical knowledge. His layout suggestions were incorporated into the task-based control design. A researcher should not need to know about Godot scenes, JSON structure, database functions or plugin order to create and run an experiment.
Shared findings
Across the sessions, the main findings were:
- The project goal needed to be stated before presenting detailed controls.
- The original interface made useful features feel scattered and difficult to discover.
- Simply allowing users to experiment with the interface did not solve the navigation problem.
- Grouping work into project creation, setup, run and review improved understanding.
- The APIs, templates, stimuli, treatment, replay and export features were viewed as useful once their purpose was clearer.
- Less technical users benefited from plain language and a visible next step.
- The client felt the revised direction was on track.
Changes made from the feedback
| Finding | Change made | Intended effect |
|---|---|---|
| Users did not know where to start. | Project creation and template choice were brought into a clearer new-project flow. | Give the researcher an obvious first action. |
| Controls appeared all at once. | The workspace was reorganised around Setup, Run and Review tasks. | Reduce clutter and avoid showing every control in every context. |
| The purpose of the platform was unclear. | Research-platform wording and limitations were added to the interface and documentation. | Explain that RODENT hosts researcher models rather than claiming to provide a validated rat model. |
| The simulator felt too small. | Arena focus and independent control-panel scrolling were added. | Keep the 3D experiment visible while controls remain usable. |
| Technical features were difficult to recognise. | Templates, APIs, environment import, model placeholders, replay and export were given labelled locations. | Make implemented and planned integration points visible. |
| Less technical users needed guidance. | Labels and instructions were rewritten in researcher-facing language. | Reduce the amount of software knowledge required. |
| Adilah asked for better readability and understanding. | Wording, hierarchy, spacing and explanations were revised throughout the website and documentation. | Make each section easier to scan and explain why it exists. |
| Muhammed Akhalwaya suggested a separate tab. | A project workspace can open in its own browser tab. | Give the simulator more room while preserving the project page. |
| Irfaan suggested a more logical button layout. | Primary actions were regrouped and placed according to the Setup, Run and Review task flow. | Make the next useful action easier to find. |
Each participant gave an opinion on what should change, and the team brought those suggestions into the redesign. The feedback was not treated as a general approval exercise. It directly influenced wording, navigation, workspace behaviour and control placement.
What still needs another feedback round
The next usability test should ask participants to complete the same tasks without coaching:
- Create an account and recover a password.
- Create a project from a chosen arena template.
- Add another researcher and restrict that person to one or two modules.
- Configure a stimulus and treatment condition.
- Start, pause and reset a run.
- Open or close a permitted door during the run.
- Save a replay and download readable results.
- Explain, in their own words, the difference between RODENT and the researcher-supplied behavioural model.
For each task the team should record completion, time, mistakes, questions, assistance required and the participant's final interpretation. The same tasks should be used before and after a major redesign so the team can compare outcomes rather than relying only on general impressions.
Evidence note
This page records the feedback provided to the team. It does not invent ratings, task times, quotations or formal consent that were not supplied. Before publishing participant names in a formal report, the team should confirm that each participant is comfortable being identified. Private contact details should not be added here.
AI Attribution: This page was organised and edited with OpenAI Codex assistance from feedback notes supplied by the team. The observations belong to the named participants and should be confirmed by the team.