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

In Sprint 2, the UI team focussed their energy on the Building Status Pop-up which displays the building's health, and level, and enables the user to sell or upgrade their building. The feature was proposed by a fellow team in the cohort and thus, wireframes were essential to ensure the output of our team matched the concepts suggested in the studio. After communicating with teams the wireframes were iterated upon, and ultimately informed the final output.

Wireframes Version 1

Visuals

wireframe1 1

Description

The initial low-fidelity wireframe was released early on in sprint two, which was necessary to outline what needed to be coded and produced. Hand-drawn digital sketches were produced to mock up the first concepts. The following points outline considerations of the first wireframe.

  • Building Level Title: To inform the user what level their building is on, we have chosen to display 'Building Level XXX' at the top of the pop-up. It is important the user understands what level their building is on, as they may want to upgrade the building to increase defences which improves gameplay.
  • Health Status Bar: Since buildings can cop damage just like the main character and crystal, we want to allow the user to see a close-up of the building's health to keep track. More specifically, if the building runs out of health then it disappears from the game which disadvantages the user. Hence, it is important for the user to understand the status of their defences/resource buildings.
  • Upgrade Building Button: A user may want to upgrade their building's level to improve their defences/strength in the game as it progresses. Hence it is useful to easily upgrade a certain building by accessing the pop-up and simply clicking one button that handles the currency transaction as well as improving the building.
  • Sell Building Button: A user may want to sell a building to generate money that can be spent elsewhere in the game. Therefore, a sell button was implemented to take care of the transaction in one click for the user.

Design Considerations

Producing the wireframes stimulated design and delivery considerations our team needed to account for. This included the following:

  • Building Levels: How many building levels are possible? What is feasible yet still enough for the game?
  • Different Prices for Upgrading and Selling: What price are we going to sell the different levels of buildings? What amount is charged to upgrade a building between levels?
  • Coding: Do we handle the upgrading/selling of the building code? Do we need to create multiple entities to accommodate the different types of buildings?

Feedback

To obtain feedback on 'Wireframes Version 1' we reached out to team 7 and team 2. Team 2 were in charge of the story-line this sprint, so we wanted to get their approval on the design and they said that our wireframes look great, but the building UI won't affect their work this sprint as they will be working on cut scenes before you start the game and some during the gameplay (eg cut scenes just before the first night cycle starts) rather than the tutorial of the game. We obtained more feedback from team 7 as they actually suggested the feature ticket in the studio session so they had ideas and concepts as to how the building UI would operate and look. We also gained insight from potential users to get their opinions on design elements that improved the second wireframe.

Feedback from Team 7:

  • Upgrade Information: They advised that the upgrade button or a placeholder message should tell the user what is being upgraded, E.g. 10% increase in damage. Hence in wireframes version 2, we inserted a placeholder message that informs the user what to expect by upgrading their building.
  • Other: We clarified some integration information this included... The building will not change in appearance to the upgraded building until it's purchased so no need to show a preview of the building, our team will handle the linkage between the upgrade button and calling the upgrade function that team 7 will provide, and we will have to change the UI components (health status) based on the stats of the building, 3 levels for buildings, to begin with, is in scope and we can manipulate in future.

Design Feedback from Potential Users:

  • Upgrade Symbol: A user suggested including an upgrade symbol like a star, medal or upwards arrow to excite and motivate the actual game user to upgrade their building. Visual stimulation can sway actions and validify users' decisions, so a positive symbol may make the game more playful. Hence, a star was implemented next to the upgrade message.
  • Colour Scheme of Buttons: The users suggested not to change the colour of the buttons but rather stick with the golden yellow toned buttons used on other UI components across the game.

Wireframes Version 2

Visuals

wireframe2

Description

Based on the feedback provided from the wireframes version 1 and also sourcing design input from potential users the second iteration of wireframes was created. Wireframes version 2 was produced in higher fidelity to appear more like the final product which will provide more targeted feedback and a more thorough user experience can then be delivered.