UX Checklist

This info is intended to cover a consolidated list of items to consider in production that are common to modules and outlined in the UX Requirements.

Module Introduction: o3h page

• Module Start: first screen (splash screen) is animated and has a simple action button figma
• Module introduction/tutorial moment for both Host and Audience; quick and visual figma
  • Audio & Camera toggles on introduction/leaderboard screen, not in splash or gameplay (o3h Docs - Camera & Audio Toggles, figma)
  • Camera element of user appears before recording officially starts (See Principle #1) figma

Video elements and gameplay UI o3h page

• Oooh is portrait mode mode only, landscape not currently supported
• Host is on the left, Audience is on the right for a standard audience view figma
• Players make the most interesting content, therefore video elements should be as large as they can be in the UI
  • Consider if it makes sense to put gameplay on top of the video elements to maximize screen real estate
• Consider the platform safe areas when designing gameplay UI and avoid putting key information towards the bottom of the screen figma o3h doc

Creator customization

• long and involved Creator customization flows shouldn't have background music

Creating the video output figma o3h doc recording o3h doc replays

• Consider the entirety of the video output in your design - from the moment fullscreen recorder turns on to where it ends
• Use both video capture types - fullscreen record (captures game UI) and camera record (raw camera, no game UI) to your advantage in your design.
• Reactions and context is important. IE - do NOT turn off the recorder right when the game ends. Continue recording to capture the players reaction & post game commentary.
  • Give the player moments to celebrate or otherwise react - streaks, beating the Host, new high score, etc.
  • This is also true for camera elements. In audience mode - continue playing the Host’s camera element for several seconds after they die, giving the player the satisfaction of seeing the Host’s death reaction.
• The user can always see themselves on camera before recording starts; this can be displaying their camera element on the screen before recording, or represented in a 3-2-1 countdown moment
  • Any preparation moment, such as a countdown should not be captured in the final video output.
• Users on Oooh expect to be recorded while playing a game. Record the entirety of the user’s gameplay session, providing raw video for the platform’s auto-highlight system to scan and auto-trim the video to identify moments when the player is most interesting figma
• All modules require a single video output for posting when finished. Multiple videos may be joined together when a module closes to create a single video output
• If no obvious video output is available for the Host (IE contains spoilers), modules should prompt the Host to create a Call to Action (CTA) video. This recording should be “branded” to the art style of the module so it’s differentiated from camera-only Open Oooh videos on the Oooh feed.
• If the module ever asks a player to record themselves (IE they need to record a CTA video) they will need instruction/context before recording starts on why they are recording themselves. Never record users without context.

Recording UI Standards o3h page

• If showing a record view, adhere to the Oooh record view UX standards (see entire page) figma
• Record views that incorporate branding, and therefore necessitate the use of the full screen recorder, should use the native record button to avoid having a record button in the video output o3h doc

Leaderboard o3h page

• Leaderboard incorporated figma
• End results have some info from the leaderboard incorporated, but in a post-gameplay celebration presentation figma