Macro play areas

[johnsillings]

Note: this is one of the most important user stories of the entire mobile game UI/UX project. Handle with great care!

As a player, I need to understand the game state and perform a variety of actions on a mobile device, and accomplish the most frequent actions easily and intuitively.

We have a variety of prototypes to consider, but should settle on a Play Areas format that will guide future designs.

Examples:

Steps

• [ ] Look at other mobile turn-based strategy games and collect examples in both video & screenshot forms
• [ ] Brainstorm and list multiple designs that meet the acceptance criteria of the task to a satisfactory level. At this stage more exotic designs can be considered as it’s important to widen our view of the solution landscape before focusing too much on details.
• [ ] For each design rate values below from 0 to 5
  • Clarity: How clear is it: https://www.liamcharlton.com/post/signs-feedback-and-the-ux
  • Ease of use: Number of needed interactions with the UI, complexity of interactions, number of hands needed to complete the actions, thumb zone etc.
  • Acceptance criteria met:
• [ ] Implement changes to update the rating values of the above designs
• [ ] Identify any new player issues that may arise from each of your rough designs and the potential for them to be mitigated.
• [ ] Decide on 1-2 designs that have the greatest potential to work by analyzing the results from previous steps.
• [ ] Share all your results from the previous steps with the team in a table containing concise information; It’s important to also show your thought process for the design decisions you have made.
• [ ] Get the greenlight from project owners to start work on a detailed Figma prototype for one of the high potential rough designs.

Acceptance criteria

• [ ] Play area is displayed in native, vertical mode on a mobile device
• [ ] All major design elements are considered (see project for full list: https://github.com/orgs/colonistio/projects/4/views/1)
• [ ] Players have easy, intuitive access to the most frequent actions
  • [ ] Design considers the "thumb zone" (the easiest areas for players to click): https://www.smashingmagazine.com/2016/09/the-thumb-zone-designing-for-mobile-users/
• [ ] Players have clear awareness of the most critical game state information
  • [ ] Design considers where mobile users tend to look most frequently (see: https://www.toptal.com/designers/mobile-ui/fundamental-guide-mobile-usability)
• [ ] Play area does not feel overcrowded with UI elements
• [ ] Secondary actions are considered, such as
  • [ ] When and if certain UI elements are shown and hidden (e.g. on my turn vs. on opponent's turn)
  • [ ] When and if certain UI elements can be expanded or contracted

[AlfredTimmer]

Regarding these acceptance criteria:

Secondary actions are considered, such as When and if certain UI elements are shown and hidden (e.g. on my turn vs. on opponent's turn) When and if certain UI elements can be expanded or contracted

I think this would be better treated in the already created individual tasks (trade expansion panel treated in the trade task, and so on..), as the way they are designed will impact the required space/layout.

I have shown the contracted version in my sketches here: https://www.figma.com/file/SkflgpJdHl3crvc5Lg488a/Mobile-App---Board-Game-Actions?node-id=201%3A28398&t=sciJsRIwX6hXgt0g-0

[johnsillings]

@AlfredTimmer – yup, agree!

my thinking in including them here is that there may be interactions between them that might be beyond the scope of an individual design element, e.g.:

• trade menu may have multiple display states
• chat may have multiple display states
• when chat and trade are both in a particular state, one may interfere with the other

but agree that these are primarily considerations of the specific UI elements. what do you think? happy to strike from here, but i want to make sure that these sorts of cases are being considered early enough in the design process

[AlfredTimmer]

@johnsillings

Sure thing, I will do a rough treatment of the multiple states where needed to give the team of sense of how they could look and avoid any interference between expanded panels.

The end results of the other individual work on these panels may deviate drastically from my proposals but there's no issue there from my pov. Just FYI, I do not intend to show these non-default panel states in the community pool I will be preparing in order to avoid generating risky expectations.

[AlfredTimmer]

Macro play areas design here, on the left of the workspace: https://www.figma.com/file/SkflgpJdHl3crvc5Lg488a/Mobile-App---Board-Game-Actions?node-id=201%3A28398&t=ZZPN3LoFrMAPFsmI-0

[demiculus]

Macro play areas design here, on the left of the workspace: https://www.figma.com/file/SkflgpJdHl3crvc5Lg488a/Mobile-App---Board-Game-Actions?node-id=201%3A28398&t=ZZPN3LoFrMAPFsmI-0

I commented on the things that I saw that needs to change. The rest you can put in the decisions and tag people.

We need an update each time someone updates something in the decision collection.