Building UI Testing - UQdeco2800/2022-studio-1 GitHub Wiki

Abstract Testing

This type of testing was done to ensure that the design of the UI pop-up is what users expect and the feature needs changes. Does it hold all the features the user needs, wants and expects?

User Testing Plan

The user was given a piece of paper and asked to draw a pop-up for a building interface. This task was open-ended and allowed users to make their own assumptions about what information is needed, and expected.

After this was created the users were asked about features such as upgrading the building and selling it. This allowed time to take those features into the design.

After this they were asked if they had to remove an element from the pop-up and which feature would they remove. And if they had to add something for future development then what would they add?

Results From Testing

Four Users tested using the method above the following drawings were made: resized image

resized image 2

305521922_1457571781407493_1577268683204550160_n

305910925_5357432647667581_4211432134181838214_n

Once testing was completed we compared these images of building pop-ups to our own wireframe (which can be found on the planning page) and noticed we may have made the pop-up too full and busy. Many of the users made their building pop-ups as simple as possible, even one user stated when asked to add an extra feature "I don't want to add more as it's just a pop-up, I wouldn't want to spend too much time on a pop-up but playing the game". Therefore, for this reason, we simplified the pop-up. We did this by removing the symbols on of upgrade and sell buttons and tried to make it smaller by reducing the building description and the large heading of the building name. By doing this hopefully, the user will not be distracted by the pop-up and not draw away attention from playing the actual game.

Looking at the illustrations above, helped validate the sell and upgrade feature as some of the designs do have these features. Another pop-up design also has the building health and building name which also helps validate that aspect of our design.

Navigational Testing

After the success of user testing in sprint one, the UI team completed navigational testing with users again to gauge how effective the building UI pop-up's interactivity was. Navigational testing is when a user is given a list of tasks to complete without assistance from the tester (observation only). The results are helpful in understanding how intuitive an action may be, and ultimately, measures the interface's success.

User Testing Plan

The user must complete the following tasks without any guidance or assistance. Condition: always start from the game screen with pre-placed buildings.

  1. Identify the health status of a building.
  2. Find out what level your building is on.
  3. Upgrade your building and then explain what the upgrade did to your building (i.e change in what?
  4. Sell your building.

Purpose of Each Task

  • Task 1: A user needs to know the health status of their buildings as buildings also get attacked by enemies. If there is no health left the building disappears which disadvantages the user. Hence, they may want to upgrade to prevent this outcome.
  • Task 2: A user needs to know the level of their building as level 1 has less strength and power than that of level 3. Hence, to progress through the game and play strategically it is advantageous to identify the building's level.
  • Task 3: A user must be able to upgrade a building to play the game with strategy. If the transaction fails, this inhibits the user's gameplay.
  • Task 4: Same purpose as Task 3 but for selling a building.

Results and Conclusions

Navigational testing was conducted on ten non-expert users between the ages 15 and 25. The results of the testing for Task 1 showed that all of the users tested immediately recognised that clicking on a building will display the building's health, and correctly identified the actual building health. One critical issue that 80% users faced was that in the clicking process, another building would be spawned next to the building they were going to click and that would result in the pop-up disappearing. However, the users would correct this by clicking back into the building and quote the health from it. Additionally, all users were able to identify the level of the tower which was picked up being next to the to building type in the title of the pop-up. All users identified that the wall had no associated level. For Task 3 and 4, all users identified the method of selling and upgrading building and clicked on the buttons. All users showed concern when the pop-up and the building did not disappear on selling button clicked.

The conclusions drawn from navigational testing include making the sell button disappear the pop-up and remove the building. Event handlers will need to be be put into place in Sprint 3 once the building placement is integrated with the shop. Additionally users questioned the health bar and its purpose considering the text placed next to non-functioning health bar. This was an issue faced in Sprint 2 and was not able to be addressed in this sprint due to the complexity of positioning the entity's health bar above the pop-up (i.e., it would be placed behind the pop-up).