Usability tests

Iteration 1 – Wireframe Testing

These usability tests were carried out to gather early feedback on the design and navigation of our wireframes, before any code was written. The goal was to identify usability issues and improve the interface before development began. Who was tested: Classmates and friends outside the group. How the tests were conducted: Participants were shown the wireframes and asked to navigate through them as if it were a real application. A group member was present to observe, but did not guide the participant unless necessary.

Questions asked:

What do you think of the overall design? If you came across this application, would you understand which buttons take you where you want to go? Is the page easy to overview and read? Does the layout feel intuitive and would you know where to start without being told? Is there anything you find confusing or unnecessary? Is there anything you feel is missing from the interface?

Feedback received:

Overall design looks alright. Easy to understand functions and navigating to desired pages. Home page needs better design, several buttons navigate to the same page, which creates confusion.

Iteration 2 – MVP Testing

These usability tests were carried out to get feedback on the MVP of our project. Since the frontend was not yet completed at this stage, the tests were conducted directly through the IntelliJ console. A group member guided each participant through the relevant parts of the code, showing them where to input information and where to read output, error messages and confirmations. Who was tested: Classmates with software knowledge, and friends without a software background, which gave us two different perspectives.

The following functions were tested:

Creating a user

Making a donation

How user and donation data was stored in the database

How the tests were conducted:

Testing was split into two groups with different focuses: Classmates (software background): These participants were shown the code and database directly. They were asked to evaluate technical and architectural choices, giving feedback on implementation quality and code structure. Friends (non-technical): These participants were guided by a group member who showed them where to type input in the console and pointed out where feedback and confirmations appeared. This simulated the user experience as closely as possible given the lack of a finished frontend.

Questions asked to Classmates:

What do you think of the choice of SQLite as a local database, and how do you evaluate the implementation? Is the structure set up with "smidig utvlikingsmetoder" and OOP principles in mind? Does the database contain relevant columns and data fields? Is there anything in the implementation you would have done differently?

Questions asked to Friends:

Try to create a user. What do you think of the feedback you receive once the user has been created? Looking at the information stored in the database. Is this information you would want to see displayed in the application? Is there any information you feel is missing? Did the process feel straightforward?

Feedback received:

The choice of SQLite was seen as appropriate for a local desktop application, though classmates noted that connection handling could be made more robust. This was mainly in relationon to how the Database-class connected to the database via hardcoding the URL, rather than a method that connects straight to the file. OOP structure was generally well received, with a suggestion to further separate concerns between database logic and application logic. Friends found the console-based flow manageable with guidance, but noted that error messages could be more descriptive and user-friendly. Friends mentioned that displaying the user's donation history would be a valuable addition to the profile page.