MindLabs - Forces & Motion
Game UIUX | Prototyping | Augmented Reality
Overview
Summary
Gneral Summary
MindLabs: Forces & Motion is a game that teaches 4th grade physics in Augmented Reality (AR). The player takes on the role of an engineer to manipulate simple machines in order to complete a variety of objectives. The game leads players through the Engineering Design Process by asking them to create, test, and iterate on the prototypes they make.
Platform - iOS and Android tablets
Genres - Augmented Reality Physics game
Assumed Player
- Age appropriate literacy and reading comprehension
- 3rd to 5th grade
- Playing the game as an in-class exercise with educator present
- Basic competency with tablet technology
- No prior knowledge of the subject matter
Roadmap
Timeline
Team
Solution
Prototyping with Tiles in AR
The dynamic nature of AR participation encourages players to take a hands-on approach to learning.
Create mode allows players to solve open-ended challenge and experiment through play.
Testing and Experimenting
The dynamic nature of AR participation encourages players to take a hands-on approach to learning.
Create mode allows players to solve open-ended challenge and experiment through play.
Engineering Design Process
Both Challenge mode and Create mode utilize the Engineering Notebook to guide players through the Engineering Design Process.
Questions are answered, thoughts are captured, and prototypes are planned in the Notebook.
Troubleshooting & Iterating
Players are asked to iterate based on feedback by answering troubleshooting questions.
Players are encouraged to contribute their individual thinking
Providing Collaboration Feedback
Students are encouraged to give feedback on how other team members are working together on the team
Now let's discuss how I got there
Define
Breaking down Statements of work
Background
Current Mindlabs 🔗
Mindlabs : Energy and Circuits is the recent product from Explore! team, which teaches circuits in AR. Their goal is to increase access to high quality STEM learning experiences, through immersive, educational games that are affordably priced.
General Goal
Filament X Explore!
Our team collaborated with the client to build a Collaborative Engineering Design Platform, which serves as a standard, intuitive mechanism for directing students through the engineering design process for a given design challenge.
Content wise, we want to extend STEM materials to force and simple machines
From a research aspect, we want to collect student’s gameplay data and collaboration data, The research group was hoping to build an model to assess students’ problem solving, critical thinking and collaboration skills, and further help teachers to better assess students’ performance and help them to learn and improve.
Secondary Research
White paper research and literature review
Before directly jumping to the UIUX design, I need to know more about the project goal and "current solution", and further evaluate the user stories. I took initiative to understand the whole picture as well as analyze my own scope.
At the beginning of design phase, I went through all the documents and research papers clients handed off, trying to understand why and how our clients want to make a new game to further improve STEM learning.
After going through all the related documents and discussing with peers and clients, I broke it down into three aspects ⬇️
Kick-Off
Statement of work (detailed user stories) & Sketch
Different from other design challenge which starts from research, this case is special because our client has a specific research and teaching goal.Therefore, they have a detailed plan for the game, including sketch and user stories illustrating specific features
Challenges & Opportunities
As I went through the research paper and all the documents, I discovered two gaps between the proposal and the real situation
-
The first one is that, the game proposal is developed to meet a research and educational goal, but the students’ gaming experience is missing in the context.
-
The second , it’s developed during covid for remote learning, but now, after covid, the game is considered more as an in-class experience.
Design
Initial Sketch
Looking back at client’s proposed sketch, I found out
Ambiguous information structure
question/idea/reflection/explanation/emotion ……
A chat window ?
A history panel?
A notebook ?
A portfolio ?
Potential Risks -
usability & feasibility
Players don’t know when I should do what
Players don’t know what I can get from doing what
👇
Players don’t have motivation to use it
Ideation
First,I tried to sort out the information architecture. I tried several options about storing different inputs in different panels. But still, that didn’t solve the problem of motivation.
V0.0
V0.2
V0.1
V0.3
Re-organize user stories
Therefore I took a step back trying to organized the user stories. Currently they can be categorized as prompt and capture critical thinking, iterations of designs and emotional factors.
To think from an user journey aspect, they can be classified as, as a student at any time I can do / I can see, and at the end I can do / I can see.
But, what is at any time. Every use case and scenario should happened at some stage of the game? So instead, I asked myself, what certain things players can do at certain time?
I looked into the detailed engineering design process cycle, and used a simplified version to guide players through the game.
Map out user stories
Then I mapped those stories based on different scenarios in the whole process, and got a better idea of what our education team wanted the players to see and to do at different stages.
User Flow
After I reorganized the structure, I illustrated the basic flow. Yellow ones are onboarding and offboarding steps, and purple ones are engineering design steps. Thumbs up and thumbs down are the steps players need to reach consensus before moving to next step.
At each step, I had some questions which needed input from different roles.
To encourage collaboration
-
I tried to navigate players through the game based on consensus decision, and make sure they are Always on the same page : planning, creating, testing, iterating.
To be less interruptive
-
I tried to let players define constraints and objectives using multiple choice system only at the beginning
-
Do troubleshooting after certain rounds of tests, and only based on group mutual decision
-
provide emotional feedback at the end of the game
Balance different voices
What’s the potential object tiles and interactions (based on force & motion)
How to design a task
Met weekly for clarifications for questions, and progress update
Discussed how to construct student’s operation data point ( tile behaviors and object modification)
Discuss how to construct engineering design and collaboration qualitative data point (questions & interaction)
I met with the team and the clients to discuss user flow.The basic structure got approved, but the two sides have some various opinions on details.
Insights
My contribution at this step
The main takeaway from the sync meeting was, we could utilize synchronization on basic steps, like consensus on testing and troubleshooting. And students should be encouraged to contribute their own critical thinking to the team progress.But, since detailed game (level tasks, object tiles, mechanisms etc) are not designed yet, plenty of things are still vague at this step, and it’s hard to make UIUX decisions So I decided to go into more details about the good to go part.
Good to go
-
Wireframing out the basic structure, which has a clearer information architecture
-
Wireframing AR screen interaction
Flexible place holders
-
Wireframing a visual feedback system which inform student’s current status (for further synchronization)
-
Wireframing the asking / planning / imagining part as multiple choice place holders, but has the flexibility to adapt to free answer questions
-
Wireframing the troubleshooting part with answer sheets which display answers for both individual answers & group answers
My contribution at this step
Actulization
My contribution at this step
V1.0
V1.1
Evaluate
Client Feedback
-
The education team likes the basic structure and interaction. They have some specific comments on how to set up AR themes which match simple machine challenges, which makes strong sense. We also agreed that emotional feedback could be designed as a feature which is available throughout the game.
-
About how to define constraints and objectives, and how to plan before the game, we agreed that the design challenge can be more open-ended, and students can set their own goals and decided when the solution meet their goals
-
We also agreed that troubleshooting part could be less mandatory. And the game designer have to further work with clients to design a "reward burst" or other incentive for students to fill things out well.
Iteration
Improve
Define
Before
Multiple choice : materials & constraints etc
After
Verbally define your goal (by creating an objective list), and plan on hand drawing
Plan
Before
Multiple choice : materials & constraints etc
After
Plan on hand drawing
Create
Before
singular horizontal bar, with rotate option
After
Considering height ,change horizontal bar into vertical bar (since ipad is in landscape view), and adding more bars for multiple modification (angle / height / friction/ etc)
Test
Before
Reggie go through the playground
After
Less 3D animation : another object went through the course, maybe a sports related ball, reggie do basic movements (pull the rope / push a button etc)
Test
Before
Detect a fail state and start troubleshooting mandatory (once per few rounds)
After
Players can decide whether to start trouble shooting or not
Troubleshooting
Before
-
can’t proceed without filling the session
-
anonymous contribute to group answers, answers would pop up synchronously
After
-
skip option
-
awarding animation when filling out
-
contribute your own answer before checking others answers
Reflection
Before
Reflect at the last step
After
Reflect throughout the game, with single touch on the profile
Deliverables
Wireframe
Wireframes answer the question,
“HOW does the player do X?”
A Wireframe is an image or series of images that represent the skeletal, functional layout of an interface. Wireframes typically lack any style on art, and are usually composed of black and white lines or grey boxes. They are primarily concerned with interface and user interaction and not necessarily game mechanics or visual style.
Note
The wireframe mainly focused on the create mode (multiplayer scenario) in Mindlabs - Force & Motion : this scenario is considered to be the most complex one which has certain additional features to encourage collaboration.
However, the overall structure of the engineering notebook is designed to be universal which can be applied to other Mindlabs Games. Technical operation of tile behaviors should be the same across different games.
Key Mockup
Style Guide
To onboard the next UIUX designer for further iteration and implementation, I created the style guide which details the final UI style and contains guidelines for how to maintain consistency across UI elements for Mindlabs.
UI Assets were designed specifically for the iPad Pro 12.9 (2048 x 2732 pixels, 4:3 ratio). Using these assets for other aspect ratios and resolutions may not work as intended.
